GFS架构分析

Google文件系统（Google File System，GFS）是构建在廉价的服务器之上的大型分布式系统。它将服务器故障视为正常现象，通过软件的方式自动容错，在保证系统可靠性和可用性的同时，大大减少了系统的成本。

GFS是Google云存储的基石，其它存储系统，如Google Bigtable，Google Megastore，Google Percolator均直接或者间接地构建在GFS之上。另外，Google大规模批处理系统MapReduce也需要利用GFS作为海量数据的输入输出。

系统架构

 

GFS将整个系统的节点分为三种角色：GFS Master（总控服务器），GFS Chunkserver（数据块服务器，简称CS）以及GFS Client（客户端）。

GFS文件被划分为固定大小的数据块（Chunk），由Master在创建时分配一个64位全局唯一的Chunk句柄。CS以普通的Linux文件的形式将Chunk存储在磁盘中。为了保证可靠性，Chunk在不同的机器中复制多份，默认为三份。

Master中维护了系统的元数据，包括文件及Chunk名字空间，GFS文件到Chunk之间的映射，Chunk位置信息。它也负责整个系统的全局控制，如Chunk租约管理，垃圾回收无用Chunk，Chunk复制，等等。Master会定期与CS通过心跳的方式交换信息。

Client是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。Client访问GFS时，首先访问Master节点，获取与之进行交互的CS信息，然后直接访问这些CS，完成数据存取工作。

需要注意的是，GFS中的客户端不缓存文件数据，只缓存Master中获取的元数据，这是由GFS的应用特点决定的。GFS最主要的应用有两个：MapReduce与Bigtable。对于MapReduce，GFS客户端使用方式为顺序读写，没有缓存文件数据的必要；而Bigtable作为云表格系统，内部实现了一套缓存机制。另外，如何维护客户端缓存与实际数据之间的一致性是一个极其复杂的问题。

下面讨论GFS架构中的几个关键问题。

 

Lease机制

GFS数据追加以记录为单位，每个记录的大小为几十KB到几MB，如果每次记录追加都需要请求Master，那么Master显然会成为系统的性能瓶颈，因此，GFS系统中通过Lease机制将chunk写操作授权给Chunk Server。获取Lease授权的Chunk Server称为Primary Chunk Server，其它副本所在的Chunk Server称为Secondary Chunk Server。Lease授权针对单个chunk，在Lease有效期内，对该chunk的写操作都有Primary Chunk Server负责，从而减少Master的负担。一般来说，Lease的有效期比较长，比如60秒，只要没有出现异常，Primary Chunk Server可以不断向Master请求延长Lease的有效期直到整个chunk写满。

假设有Chunk A在GFS中保存了三个副本A1，A2，A3，其中，A1是Primary。如果副本A2所在Chunk Server下线后又重新上线，并且在A2下线的过程中，副本A1和A3有新的更新，那么，A2需要被Master当成垃圾回收掉。GFS通过对每个chunk维护一个版本号来解决，每次给Chunk进行Lease授权或者Primary Chunk Server重新延长Lease有效期时，Master会将Chunk的版本号加1。A2下线的过程中，副本A1和A3有新的更新，说明Primary Chunk Server向Master重新申请Lease并增加了A1和A3的版本号，等到A2重新上线后，Master能够发现A2的版本号太低，从而将A2标记为可删除的chunk，Master的垃圾回收任务会定时检查，并通知Chunk Server将A2回收掉。

 

一致性模型

GFS主要是为了追加（Append）而不是改写（Overwrite）而设计的。一方面是因为是改写的需求比较少，或者可以通过追加来实现，比如可以只使用GFS的追加功能构建分布式表格系统Bigtable；另一方面是因为追加的一致性模型相比改写要更加简单有效。考虑Chunk A的三个副本A1，A2，A3，有一个改写操作修改了A1，A2但没有修改A3，这样，落到副本A3的读操作可能读到不正确的数据；相应地，如果有一个追加操作往A1，A2上追加了一个记录但是追加A3失败，那么即使读操作落到副本A3也只是读到过期而不是不正确的数据。

我们只讨论追加的一致性。如果不发生异常，追加成功的记录在GFS的各个副本中是确定并且严格一致的；但是如果出现了异常，可能出现某些副本追加成功而某些副本没有成功的情况，失败的副本可能会出现一些可识别的填充(padding)记录。GFS客户端追加失败将重试，只要返回用户追加成功，说明在所有副本中都至少追加成功了一次。当然，可能出现记录在某些chunk副本中被追加了多次，即重复记录；也可能出现一些可识别的填充记录，应用层需要能够处理这些问题。

另外，由于GFS支持多个客户端并发追加，那么多个客户端之间的顺序是无法保证的，同一个客户端连续追加成功的多个记录也可能被打断，比如客户端先后追加成功记录R1和R2，由于追加R1和R2这两条记录的过程不是原子的，中途可能被其它客户端打断，那么GFS的chunk中记录的R1和R2可能不连续，中间夹杂着其它客户端追加的数据。

GFS的这种一致性模型是追求性能导致的，这也增加了应用程序开发的难度。对于MapReduce应用，由于其批处理特性，可以先将数据追加到一个临时文件，在临时文件中维护索引记录每个追加成功的记录的偏移，等到文件关闭时一次性将临时文件改名为最终文件。对于上层的Bigtable，有两种处理方式，后续将会介绍。

 

追加流程

追加流程是GFS系统中最为复杂的地方，而且，高效支持记录追加对于基于GFS实现Bigtable是至关重要的。追加流程大致如下：

 

1. 客户端向Master请求chunk每个副本所在的Chunk Server，其中Primary Chunk Server持有修改Lease。如果没有Chunk Server持有Lease，说明该chunk最近没有写操作，Master会发起一个任务，按照一定的策略将chunk的Lease授权给其中一台chunk Server。
2. Master返回客户端Primary和其它Chunk Server的位置信息，客户端将缓存这些信息供以后使用。如果不出现故障，客户端以后读写该chunk都不需要再次请求Master。
3. 客户端将要追加的记录发送到每一个副本。每一个Chunk Server会在内部的LRU结构中缓存这些数据。GFS中采用数据流和控制流分离的方法，从而能够基于网络拓扑结构更好地调度数据流的传输。
4. 当所有副本都确认收到了数据，客户端发起一个写请求控制命令给Primary。由于Primary可能收到多个客户端对同一个chunk的并发追加操作，Primary将确定这些操作的顺序并写入本地；
5. Primary把写请求提交给所有的Secondary副本。每一个Secondary会根据Primary确定的顺序执行写操作；
6. Secondary副本成功完成后应答Primary；
7. Primary应答客户端，如果有副本发生错误，将出现Primary写成功但是某些Secondary不成功的情况，客户端将重试。

 

GFS追加流程有两个特色：流水线及分离数据流与控制流。流水线操作用来减少延时。当一个ChunkServer接收到一些数据，它就立即开始转发。由于采用全双工网络，立即发送数据并不会降低接收数据的速率。抛开网络阻塞，传输B个字节到R个副本的理想时间是B/T + RL，其中T是网络吞吐量，L是亮点之间的延时。假设采用千兆网络，L通常小于1ms，传输1MB数据到多个副本的时间小于80ms。分离数据流与控制流主要是为了优化数据传输，每一个机器都是把数据发送给网络拓扑图上”最近”的尚未收到数据的数据。举个例子，假设有三台ChunkServer S1，S2和S3，S1与S3在同一个机架上，S2在另外一个机架，客户端部署在机器S1上。如果数据先从S1转发到S2，再从S2转发到S3，需要经历两次跨机架数据传输；相对地，按照GFS中的策略，数据先发送到S1，接着从S1转发到S3，最后转发到S2，只需要一次跨机架数据传输。

分离数据流与控制流的前提是每次追加的数据都比较大，比如MapReduce批处理系统，而且这种分离增加了追加流程的复杂度。如果采用传统的Primary/backup复制方法，追加流程会在一定程度上得到简化。

 

1. 同GFS追加流程；
2. 同GFS追加流程；
3. Client将待追加数据发送到Primary Chunk Server，Primary Chunk Server可能收到多个客户端的并发追加请求，需要确定操作顺序，并写入本地；
4. Primary将数据通过流水线的方式转发给所有的Secondary；
5. 每个Secondary Chunk Server收到待追加的记录数据后写本地，所有副本都在本地写成功并且收到后一个副本的应答消息时向前一个副本回应，比如上图中A需要等待B应答成功且本地写成功后才可以应答Primary。
6. Primary应答客户端。如果客户端在超时时间之内没有收到Primary的应答，说明发生了错误，需要重试。

当然，实际的追加流程远远没有这么简单。追加的过程中可能出现Primary Lease过期而失去chunk修改操作的授权，Primary或者Secondary机器出现故障，等等。由于篇幅有限，追加流程的异常处理留作读者思考。

 

容错机制

Master的容错与传统的方法类似，通过操作日志加checkpoint的方式进行，并且有一台称为”Shadow Master”的实时热备。

Master上保存了三种元数据信息：

(1) 命名空间（Name Space），也就是整个文件系统的目录结构以及chunk基本信息；

(2) 文件到chunk之间的映射；

(3) Chunk副本的位置信息，每个Chunk通常有三个副本；

GFS Master的修改操作总是先记录操作日志，然后再修改内存，当Master发生故障重启时，可以通过磁盘中的操作日志恢复内存数据结构；另外，为了减少Master宕机恢复时间，Master会定期将内存中的数据以checkpoint文件的形式转储到磁盘中，从而减少回放的日志量。为了进一步提高Master的可靠性和可用性，GFS中还会执行实时热备，所有的元数据修改操作都必须保证发送到实时热备才算成功。远程的实时热备将实时接收Master发送的操作日志并在内存中回放这些元数据操作。如果Master宕机，还可以秒级切换到实时备机继续提供服务。为了保证同一时刻只有一个Master，GFS依赖Google内部的Chubby服务进行选主操作。

Master需要持久化前两种元数据，即命令空间及文件到chunk之间的映射关系；对于第三种元数据，即Chunk副本的位置信息，Master可以选择不进行持久化，这是因为ChunkServer维护了这些信息，即使Master发生故障，也可以在重启时通过ChunkServer汇报来获取。

 

GFS采用复制多个副本的方式实现Chunk Server的容错，每一个Chunk有多个存储副本，分别存储在不同的Chunk Server上。对于每一个Chunk，必须将所有的副本全部写入成功，才视为成功写入。如果相关的副本出现丢失或不可恢复的情况，Master自动将给副本复制到其它Chunk Server，从而确保副本保持一定的个数。

另外，Chunk Server会对存储的数据维持校验和。GFS以64MB为Chunk大小来划分文件，每一个Chunk又以Block为单位进行划分，大小为64KB，每一个Block对应一个32位的校验和。当读取一个Chunk副本时，Chunk Server会将读取的数据和校验和进行比较，如果不匹配，就会返回错误，客户端将选择其它Chunk Server上的副本。

 

 

Master内存占用

Master维护了系统中的元数据，包括文件及chunk名字空间，文件到chunk的映射，chunk副本的位置信息。其中前两种元数据需要持久化到磁盘，chunk副本的位置信息不需要持久化，可以通过Chunk Server汇报获取。

内存是Master的稀有资源，下面估算Master的内存使用量。Chunk的元信息包括全局唯一的ID，版本号，每个副本所在的Chunk Server编号，引用计数等。GFS系统中每个chunk大小为64MB，默认存储3份，每个chunk的元数据小于64字节。那么1PB数据的chunk元信息大小不超过1PB * 3 / 64MB * 64 = 3GB。另外，Master对命名空间进行了压缩存储，例如有两个文件foo1和foo2都存放在目录/home/very_long_directory_name/中，那么目录名在内存中只需要存放一次。压缩存储后，每个文件在文件名字空间的元数据也不超过64字节，由于GFS中的文件一般都是大文件，因此，文件名字空间占用内存不多。这也就说明了Master内存容量不会成为GFS的系统瓶颈。

 

 

负载均衡

GFS中副本的分布策略需要考虑多种因素，如网络的拓扑，机架的分布，磁盘的利用率等等。为了提高系统的可用性，GFS会避免同一个chunk的所有副本都存放在同一个机架的情况。

系统中有三种需要创建chunk副本的情况：chunk创建，chunk重新复制（re-replication）以及重新平衡（rebalancing）。

当Master创建了一个chunk，它会根据如下因素来选择chunk副本的初始位置：(1) 新副本所在的Chunk Server的磁盘利用率低于平均水平；(2) 限制每个Chunk Server”最近”创建的数量。（3）每个chunk的所有副本不能在同一个机架。第二点容易忽略但却很重要，因为创建完chunk以后通常需要马上写入数据，如果不限制”最近”创建的数量，当一台空的Chunk Server上线时，由于磁盘利用率低，可能导致大量的chunk瞬间迁移到这台机器从而将它压垮。

当Chunk的副本数量小于一定的数量后，Master会尝试重新复制一个chunk副本。可能的原因包括Chunk Server宕机或者Chunk Server报告自己的副本损坏，或者它的某个磁盘故障，或者用户动态增加了Chunk的副本数，等等。每一个chunk复制任务都有一个优先级，按照优先级从高到低在Master排队等待执行。例如，只有一个副本的chunk需要优先复制，又如，有效文件的chunk复制优先级比最近删除的文件的chunk高，最后，GFS会提高所有阻塞客户端操作的chunk复制任务的优先级，例如客户端正在往一个只有一个副本的chunk追加数据，如果限制至少需要追加成功两个副本，那么这个chunk复制任务会阻塞客户端写操作，需要提高优先级。

最后，Master会定期扫描当前副本的分布情况，如果发现磁盘使用量或者机器负载不均衡，将执行重新平衡操作。

无论是chunk创建，chunk重新复制，还是重新平衡，它们选择chunk副本位置的策略都是相同的，并且需要限制重新复制和重新平衡任务的拷贝速度，否则可能影响系统正常的读写服务。

 

 

垃圾回收

GFS采用延迟删除的机制，也就是说，当文件被删除后，GFS并不要求立即归还可用的物理存储，而是在元数据中将文件改名为一个隐藏的名字，并且包含一个删除时间戳。Master定时检查，如果发现文件删除超过一段时间（默认为3天，可配置），那么它会把文件从内存元数据中删除，以后Chunk Server和Master的心跳消息中，每一个Chunk Server都将报告自己的chunk集合，Master会回复在Master元数据中已经不存在的chunk信息，这时，Chunk Server会释放这些Chunk副本。为了减轻系统的负载，垃圾回收一般在服务低峰期执行，比如每天晚上凌晨1:00开始。

另外，Chunk副本可能会因为Chunk Server失效期间丢失了对Chunk的修改操作而导致过期。系统对每个Chunk都维护了版本号，过期的Chunk可以通过版本号检测出来。Master仍然通过正常的垃圾回收机制来删除过期的副本。

 

 

快照

快照（Snapshot）操作是对源文件/目录进行一个”快照”操作，生成该时刻源文件/目录的一个瞬间状态存放与目标文件/目录中。GFS中使用标准的copy-on-write机制生成快照，也就是说，”快照”只是增加GFS中chunk的引用计数，表示这个chunk被快照文件引用了，等到客户端修改这个chunk时，才需要在Chunk Server中拷贝chunk的数据生成新的chunk，后续的修改操作落到新生成的chunk上。

为了对某个文件做Snapshot，首先需要停止这个文件的写服务，接着增加这个文件的所有chunk的引用计数，以后修改这些chunk时会拷贝生成新的chunk。对某个文件执行Snapshot的大致步骤如下：

1, 通过Lease机制收回对文件每一个chunk写权限，停止对文件的写服务；

2, Master拷贝文件名等元数据生成一个新的Snapshot文件；

3, 对执行Snapshot的文件的所有chunk增加引用计数；

例如，对文件foo执行快照操作生成foo_backup，foo在GFS中有三个chunk C1，C2和C3。Master首先需要收回C1，C2和C3的写Lease，从而保证文件foo处于一致的状态，接着Master复制foo文件的元数据生成foo_backup，foo_backup同样指向C1，C2和C3。快照前，C1，C2和C3只被一个文件foo引用，因此引用计数为1；执行快照操作后，这些chunk的引用计数增加为2。以后客户端再次往C3追加数据时，Master发现C3的引用计数大于1，通知C3所在的Chunk Server本次拷贝C3生成C3′，客户端的追加操作也相应地转向C3′。

 

ChunkServer

ChunkServer管理大小均为64MB的chunk，存储的时候需要保证chunk尽可能均匀地分布在不同的磁盘之中，可能考虑的因素包括磁盘空间，最近新建chunk数，等。另外，Linux文件系统删除64MB大文件消耗的时间太长，且没有必要，删除Chunk可以只将对应的chunk文件移动到每个磁盘中的回收站，以后新建chunk的时候可以重用。

ChunkServer是一个磁盘和网络IO密集型应用，为了最大限度地发挥机器性能，需要能够做到将磁盘和网络操作异步化，这会增加代码实现的难度。

GFS

http://www.nosqlnotes.net/

 

AWS整体介绍

Amazon平台的产品分为几个部分：

• 计算类：包含弹性计算云（EC2）和弹性MapReduce（Elastic MapReduce）这两个产品。EC2几乎可以认为是迄今为止云计算领域最为成功的产品，通俗地将，就是提供虚拟机。EC2的创新在于允许用户根据需求动态改变虚拟机实例的类型及数量，技术上支持容错并在收费模式上支持按使用量付费，而不是预付费。弹性MapReduce将Hadoop MapReduce搬到云环境中，大量EC2实例动态地成为执行大规模MapReduce计算任务的工作机。
• 存储类：存储类产品较多，包括弹性块存储EBS，简单消息存储SQS，Blob对象存储S3，表格存储系统Simpledb和DynamoDB以及分布式数据库系统RDS。其中，EBS相当于一个分布式块设备，可以直接挂载在EC2实例上，用于替代EC2实例本地存储，从而增强EC2可靠性。另外，S3中的Blob对象能够通过CloudFront缓存到不同地理位置的CDN节点，从而提高访问性能。Simpledb和DynamoDB是分布式表格系统，支持单表的简单操作；RDS是分布式数据库，目前支持Mysql以及Oracle两种数据库。SQS主要用于支持多个任务之间的消息传递，解除任务之间的耦合。
• 工具支持：AWS支持多种开发语言，提供Java、Rupy、Python、PHP、Windows &.NET 以及Android和iOS的工具集。工具集中包含各种语言的SDK，程序自动部署以及各种管理工具。另外，AWS通过CloudWatch系统提供丰富的监控功能。

 

 

AWS平台引入了区域（Zone）的概念。它将区域分为两种：地理区域（Region Zone）和可用区域（Availability Zone），其中地理区域是按照实际的地理位置划分的，而可用区域一般是按照数据中心划分的。

如上图，假设用户的网站MyWebSite.com托管在AWS平台的某个可用区域中。用户将Web应用上传到EC2实例中，EC2一般分成多个自动扩展（Auto Scaling）组，并通过弹性负载均衡（Elastic Load Balancing）组件进行负载均衡。用户的Web应用可以访问AWS平台上的存储类服务，包括EBS，S3，Simpledb，DynamoDB，RDS以及SQS。网站上的Blob数据，如视频，图片将通过DNS定位到Amazon CloudFront。CloudFront首先在本地缓存节点查找Blob对象，如果不存在，将请求源站获取S3中存储的Blob对象，这一步操作称为回源。AWS CloudWatch对AWS平台上运行的所有服务及应用程序进行监控。

 

Amazon EC2

相比传统的虚拟机托管，EC2的最大特点是允许用户根据需求动态调整运行的实例类型和数量，实现按需付费。为了支持这种灵活性，EC2需要在技术上支持容错以及更好的安全性。

架构

 

Amazon EC2平台主要包含如下部分：

• EC2实例

AMI（Amazon Machine Image）是Amazon虚拟机镜像文件，它是一个可以将用户的应用程序、配置等一起打包的加密机器镜像。用户创建好AMI后，部署在EC2平台上运行，称为一个EC2实例。每个实例自身包含一个本地存储模块（Instance Local Store），临时存放用户数据。如果EC2实例运行过程中出现故障或者实例被终止，存储在其中的数据将会丢失。因此，Amazon建议将重要的数据保存在EBS中以增强可靠性。

• 弹性块存储

弹性块存储（EBS）映射为EC2实例上的块设备，与EC2配合使用。EBS允许用户创建卷（Volume），每个卷可以作为一个设备挂载到EC2实例上。数据在EBS中存储多份，从而保证高可靠性。另外，EBS提供了增量快照功能，可以将当前卷的状态快照增量备份到S3中。假设EBS卷有100G数据，其中只有5GB的数据从上次快照操作以后产生了变化，那么，仅仅需要将这5GB变化的数据备份到S3。

• 弹性负载均衡

弹性负载均衡自动地将流量分发给多个EC2实例，并且在一定程度上支持容错。弹性负载均衡功能可以识别出应用实例的状态，当某个实例出现故障时，它会自动将流量路由到健康的实例上。

 

EC2存储

EC2本地存储是实例自带的磁盘空间，但它并不是持久的，也就是说这个实例所在的节点出现故障时，相应的磁盘空间也会随之清空，本地存储上的数据随时有丢失的风险。

为了解决本地存储不可靠问题，EC2推出了EBS，数据在EBS中自动在同一个可用区域内复制多份。EBS通过卷来组织数据，每个EBS卷只能挂载到一个EC2实例。EBS卷并不与实例绑定，而是与用户帐号绑定。当EC2实例发生故障时，用户可以在新启动的EC2实例上重新挂载EBS卷。另外，EBS能够以快照的形式将数据增量备份到S3，而S3的数据分布在多个可用区域，进一步增强了可靠性。EBS的设计原理如下：

 

 

如上图，EBS包含两个部分：EBS控制层（EBS control plane）及EBS存储节点。EBS客户端通过EBS control plane创建逻辑卷，获取逻辑卷每个副本所在的EBS存储节点位置，然后请求EBS存储节点读写逻辑卷数据。每个逻辑卷存储在多个EBS节点上，多个副本之间数据强同步，其中有一个副本为Primary，其它的为Secondary。当Primary往Secondary传输数据失败时，将请求EBS control plane选取新的EBS节点增加副本，这个过程称为重新镜像（re-mirroring）。EBS control plane负责每个逻辑卷的Primary副本选取，如果Primary出现故障，将选择某个Secondary副本为新的Primary。EC2实例通过EBS客户端访问EBS系统，它们之间遵守一定的协议，比如网络块设备（Network Block Device，NBD）协议，从而EC2实例访问远程EBS节点上的逻辑卷与访问本地的块设备没有差别。

 

自动缩放

自动缩放（Auto Scaling）可以根据用户自定义的条件，自动调整EC2的计算能力。多个EC2实例组成一个自动缩放组（Auto Scaling Group），当组内的实例负载过高，比如CPU平均使用率超过70%时，可以定义缩放规则自动增加EC2实例；同样地，当组内的实例负载过低时，可以自动缩小EC2实例规模以降低成本。

EC2根据计算能力将实例分为多种类型，如下表：

资源	Small	Large	Extra Large	High-CPU Medium	High-CPU Extra Large
平台	32位	64位	64位	64位	64位
CPU	1ECU	4ECU	8ECU	5ECU	20ECU
内存	1.7GB	7.5GB	15GB	1.7GB	7GB
存储容量	160GB	850GB	1690GB	350GB	1690GB

 

EC2的一个计算单元称为一个ECU（EC2 Compute Unit），其计算能力相当于1个1.0GHz 2007 Xeon处理器。EC2平台不支持虚拟机实例在线迁移，如果用户需要调整实例类型，EC2内部实现时逻辑上分为两步：a) 终止原有的EC2实例；b) 根据一定的策略（比如负载）动态选择新的服务器节点启动新的EC2实例。自动缩放功能一般会配合弹性负载均衡功能一起使用，弹性负载均衡组件能够自动将流量转发给新实例。

 

网络路由

通过自动缩放技术，当EC2平台检测到某个实例出现故障时，将动态选择新的节点启动新实例，每个实例重新启动后它的公共IP地址都会发生变化。Internet用户通过域名访问EC2实例，然而，需要一段比较长的时间才能更新公共IP地址与DNS之间的映射关系。为了解决这个问题，EC2提供了两种方式：

1. 弹性负载均衡：EC2新实例重启后通知弹性负载均衡组件，弹性负载均衡组件能够自动将流量切换到新实例。
2. 弹性IP地址：弹性IP地址和用户账号而不是和某个特定的实例绑定，EC2用户可以将DNS域名设置为指向弹性IP地址。新实例启动时，EC2用户只需要使用管理工具将弹性IP地址与新的实例关联起来，Internet用户感觉不到任何差异。

3. 2011年度总结

   一 3rd

   由chuanhui发表在个人随笔

   8个评论

   技术杂谈

   10年定下近几年的技术方向：

   1, 精通架构：深入理解线上，线下分布式存储&计算并能够形成完整的知识体系；

   2,理解系统：理解系统，网络，IDC，虚拟化等相关知识；

   3,掌握应用：通过应用证明和修正分布式知识体系；

   11年做了一些事情：

   1, 思考并讨论Google，Amazon，Microsoft，Yahoo，Facebook内部云存储系统的架构及实现，在云存储方向形成了初步的知识体系；

   2, 读了一些系统和网络方面的博客和书籍，如褚霸同学的博客，<<Unix网络编程>>，等等；

   3, 通过推广OB学习了很多应用的入门知识，主要包括数据库应用，OLAP应用，搜索广告应用；

   12年准备做一些事情：

   1, 整理一本云存储技术资料；

   2, 深入学习并实践系统优化相关知识，重点是CPU&内存优化；

   3, 理解淘宝数据库OLTP应用访问模式，深入理解OLAP应用业务知识；

   云存储观点

   1, 根据应用模式及实现难度，可以大致将云存储系统分为四类：Blob存储系统（淘宝TFS，Facebook Haystack），分布式KV系统（淘宝Tair，Dynamo），分布式表格系统（Bigtable，Megastore，Azure Table Storage）以及分布式数据库（SQL Azure，Amazon RDS）。

   2, 云存储直接提供对外服务时机还不成熟，创业者期望的只是一个服务稳定的，花费低的虚拟主机而已。云存储服务需要与业务打包捆绑销售，比如Dropbox，腾讯开放平台。

   3, 线上线下融合还比较难，几年之内的方式还是线下计算好的数据Push到线上系统，而不是线上线下完全共用。线下系统大局已定，Hadoop一统江湖，机会与挑战主要在线上系统，实时化。

   4, 云存储的主要优势在于节省成本，来源于几个方面：a, 系统优化，普遍有2~3倍性能提升，对于某些特殊应用或一些特殊压缩算法，单节点优化可以有数量级的性能提升；b, 机器Buffer。为了防止异常，线上系统一般需要一半以上的机器Buffer，大量线上系统利用率<20%，通过提高存储服务能力，能够节省2~3倍成本；c, 硬件量产带来的低采购成本。总而言之，云存储带来的成本节省在5倍以上。

   5, 云存储系统有两个目标：一个是高可扩展性，终极目标是线性扩展，完全自动化，宕机恢复时间极短；一个是强功能，终极目标是强一致性，关系型数据库SQL功能集。可扩展性与功能需要取舍，但支持绝大部分SQL功能集的线性可扩展云存储系统将出现并成为主流。

   感悟

   1, 权利与责任对等。有什么样的权利，就应该有什么样的责任。主管有带人的权利，就有考虑其他人如何成长的责任；业务方说话声音大，是因为要背业务KPI。技术驱动业务是不现实的，除非技术背负业务KPI。

   2, 保持乐观。这个世界有太多的不公平，尤其是在天朝。然而，社会总是不断朝着公平这个方向发展的，在互联网这个小圈子里面还是相对公平的。做好自己能够控制的，忽略自己不能控制的，多想想你有什么，你想要什么，最重要的是，你还需要并且能够做什么？

   3, 技术与业务。技术只有与业务相结合才能产生价值，从无到有做好一件事情，最重要的一点就是是否精通业务；然而对于技术产品，比如存储产品，这件事情能够做到多大，技术的深度会起重要甚至决定性作用。业务是从0做到10的能力，技术是从10做到1000的能力。

   4, 坚持与执行力。一个人最重要的能力是把规划好的事情用最有效的方式执行下去，拿到结果。规划是从多条路里面选一条路，既然是选择，而且这个选择过程可能很痛苦，那么这些让人纠结的选择之间投入产出比一定是相当的。选择了就坚持下去，只要执行得好，往往都能拿到好的结果，即使选择不是最优的。

   生活

   1, 英孚没有达到8级的目标，只到6级就没有坚持下来了，没有明确目的的学习往往很容易被其它事情打断；

   2, 2011年没有学车，2012年必须学完；

   3, 上下班时间太长，健身计划有些中断，2012年目标比较现实，每周去健身房跑步一次就可以了。

   年度总结，云存储观点