分布式文件系统 从设计到实现 - Replication（二）
<< Previous 分布式文件系统 从设计到实现 - Replication（一）
Next >> 分布式文件系统 从设计到实现 - Replication（三）
Partition与Replication是分布式系统设计中解决问题的主要方法。
Replication系列文章会聚焦：
系统为何复制，几种基本的复制方式- gfs、hdfs在复制上的设计及异同比较
- hdfs复制流程的代码实现细节
前情简介
前面的理论部分介绍了何为复制、为何复制，几种基本复制方式。理论完了，这篇具体看看gfs、hdfs如何进行副本复制（主要关注数据写入过程）。
GFS的数据复制
先看gfs原文[1]
In Figure 2, we illustrate this process by following the control flow of a write through these numbered steps.
- The client asks the master which chunkserver holds the current lease for the chunk and the locations of the other replicas. ...
- The master replies with the identity of the primary and the locations of the other (secondary) replicas. ...
- The client pushes the data to all the replicas. ...
- Once all the replicas have acknowledged receiving the data, the client sends a write request to the primary. ... It applies the mutation to its own local state in serial number order.
- The primary forwards the write request to all secondary replicas. Each secondary replica applies mutations in the same serial number order assigned by the primary.
- The secondaries all reply to the primary indicating that they have completed the operation.
- The primary replies to the client. Any errors encountered at any of the replicas are reported to the client. ... The client request is considered to have failed, ...
可以看出，gfs使用同步方式进行数据复制。
主要体现在：
- The client pushes the data to all the replicas. ...
- The secondaries all reply to the primary indicating that they have completed the operation.
整个数据写入的大概步骤：
-
首先，client从master上获取到需要保存replica的chunkserver列表，并且指定其中某个chunkserver为primary，其余chunkserver为secondaries（控制流中primary和secondaries具有不同的功能，见第三步）。
-
然后，client将数据以线性（linearly）、管道（pipelined）的方式推送到这些chunkserver上。chunkserver收到数据后暂存在LRU缓存中，等待控制流指令说明以何顺序落盘。所谓管道方式，即client只向一个chunkserver推送数据，chunkserver收到数据后，再将其推送到下一个chunkserver。
-
最后，所有数据在chunkserver上就位，client向primary发出写入指令，primary以自己的数据落盘顺序指导secondaries以一致的方式落盘。
值得注意的是，gfs清晰地将数据流（步骤3）与控制流（其余步骤）分离。
数据流与控制流分离，可以充分利用网络拓扑，最大化网络带宽，不必强行保持数据流与控制流的流向一致。
在控制流中，primay是关键节点，client与所有chunkserver的控制消息全部经由primary。因为控制消息长度短，primary的关键节点问题不大。
如果数据流也像控制流一样全部通过primary，则为了性能考虑，primary必须是到其他chunkserver距离总和最小的一个，这样要求master必须具备选择合适primary的能力。
从论文中描述的设计推断，master似乎不具备节点距离感知能力（比如，类似hdfs的机架感知能力）。因为，chunkserver的pipeline结构是由各个chunkserver自行计算得出，并没有由master统一计算得出。
这种分布到各个节点上的算法也许能更好的计算出最优的pipeline距离，因为每个节点最了解自己与其他节点的距离。
相关论文原文：
Suppose the client is pushing data to chunkservers S1 through S4. It sends the data to the closest chunkserver, say S1. S1 forwards it to the closest chunkserver S2 through S4 closest to S1, say S2. Similarly, S2 forwards it to S3 or S4, whichever is closer to S2, and so on. Our network topology is simple enough that “distances” can be accurately estimated from IP addresses.
因为无法看到gfs的具体实现，所以实现细节是否如此不得而知。
HDFS的数据复制
hdfs与gfs采用相同的复制方式：同步复制。
原文[2]：
When there is a need for a new block, the NameNode allocates a block with a unique block ID and determines a list of DataNodes to host replicas of the block. The DataNodes form a pipeline, the order of which minimizes the total network distance from the client to the last DataNode. Bytes are pushed to the pipeline as a sequence of packets. The bytes that an application writes first buffer at the client side. After a packet buffer is filled (typically 64 KB), the data are pushed to the pipeline.
具体细节略有不同，hdfs不再将控制流与数据流分离，而是将数据传输以及变更顺序（mutation order）完全由client确定的pipeline决定[3]。
hdfs pipeline细节：
- client通过与namenode通信，完全确定数据在datanode中的传输顺序
- client发起pipeline的创建消息（t0～t1）
- pipeline建立成功后，开始线性传输数据（t1～t2），同时数据也按照传输顺序（packet的序号）落盘
- 传输结束，关闭pipeline（t2～t3）
gfs与hdfs pipeline区别的思考
可以看出，hdfs的pipeline比gfs简化很多。gfs需要一个数据流和2*n+2个控制消息才能完成一个chunk的写入。而hdfs的pipeline，只需要一个数据流和少数几个控制消息就可以完成block的写入。
个人认为，hdfs的pipeline能够如此简化，主要归功于namenode能够通过机架感知信息在单个节点上计算出全局最佳的pipeline顺序。这使得client传输数据前，pipeline中的datanode顺序就已经确定，client可以很轻松的确定primary，即pipeline的第一个datanode。如此一来，控制流和数据流全部经由primary，就可以达到控制流与数据流的完美结合。整个流程中只有第一条和最后一条是纯粹的pipeline创建/关闭控制消息，中间消息全是数据消息，但同时又隐含控制功能：接收之后立即落盘。
虽然，hdfs的pipeline实现简单，但某些场景下表现不一定有gfs出色。比如，在机架信息不够准确、全面的情况下，namenode给出的pipeline顺序是否足够高效？
另外，gfs的pipeline可以支持多client同时append，顺序依然由primary决定。但hdfs的append操作如何实现，现有的pipeline机制知否支持，暂时还未知，待后续了解。
下集预告
gfs和hdfs的设计已经通过字面意思理解完了，但如何与实现对应会在下篇文章中体现。
[1] The Google File System
[2] The Hadoop Distributed File System
[3] Gfs vs hdfs - SlideShare
Next >> 分布式文件系统 从设计到实现 - Replication（三）
<< Previous 分布式文件系统 从设计到实现 - Replication（一）
