分布式系统RWN协议.docxVIP

PAGE 1 PAGE 1 分布式系统RWN协议  数据分区(Partition)  分布式系统中数据分区是个重要话题，Dynamo使用了ConsistentHash的变种，增加了虚节点的概念。这样一个实际的物理节点会分布到环上的成百上千个虚节点上。这样的好处在于： 假如一个节点不可用（故障或者维护），该节点的负载可以匀称的分散到其他可用节点上； 假如一个节点重新可用，或者新加入一个节点，新增节点可以接受到和原来节点大致相同的恳求量；  虚节点的数目可以依据物理机器的容量调整，以保证不容量的机型达到相应的负载。  数据复制(Replication)  为了高可用性，Dynamo同样使用副本，默认副本数为3。Dynamo里复制副本很简洁，当Key通过ConsistentHash散列到节点A上后，节点A的协调器(coordinator)会把该份数据自动复制到顺时针方向紧邻它的N-1个节点上，其中N是副本数。  数据版本(DataVersioning)  由于存在多副本，在没有达到最终全都性之前，对每个副本的写操作Dynamo是接受的，它的做法是标记一个版本号，这会导致系统中同一时间出现同一数据对象的多个版本。当然，这种做法比较适合Amazon自己的购物车应用，以便保证每次用户对购物车的更改都是可以保留下来。  在多数状况下，新版本会包含老版本，且系统自己就能协调(syntacticreconciliation)打算最终版本。但用过版本管理系统的人都知道，版本冲突是不可避免的，Dynamo也会遇到这种状况，此时需要交由应用层来协调，将多个分支的数据强行合并(collapse)一个版本。这种版本协调的结果，对于购物车应用来说，添加的商品不会丢失，但是删除的商品有可能出现，对于购物车场景来说是可以接受的。  Dynamo使用向量时钟(VectorClock)来做版本掌握，以合并冲突。  读写操作  Dynamo是一个高可用性系统，任何节点可以在任何时刻(failure-free)接受应用层的读写操作。但由于有多副本，读写操作就涉及数据全都性问题。为了解决该问题，Dynamo使用了类似法定仲裁Quorum)的全都性协议。  Quroum协议有两个个配置项： R一次成功读操作中最少参与的节点数目 W一次成功写操作中最少参与的节点数目  Quorum是说要保证：W+RN，相当于写成功需要的副本数+读成功需要的副本数副本总数，则能保证最终全都性。官方建议(N，R，W)=(3，2，2)以兼顾AP。  故障处理(Hintedhandoff)  在一个节点出现临时性故障时，数据会自动进入列表中的下一个节点进行写操作，并标记为handoff数据，在收到通知需要原节点恢复时重新把数据推回去。这能使系统的写入成功大大提升。  处理永久故障(Replicasynchronization)  为了更快的检测副本之间是否不全都，Dynamo使用MerkleTree。MerkleTree是一个hash值构成的树，每个叶子节点是Key的hash值，然后中间节点是全部儿子节点的hash值，这样每个子节点的变动都会反应到上层父节点。使用MerkleTree为数据建立索引，只要任意数据有变动，都将快速反馈出来，可以提速数据变动时的查找。这一技术在torrentp2p传输中早有普及。  成员和故障检测  Gossip是一种去中心化的通讯协议，通常被用在分布式的非强全都性系统中，用来同步各节点状态。详细做法是，在一个有界网络中，每个节点会周期性的随机的发起Gossip会话，经过多轮通信后，最终全部节点状态会达成全都。它可以用来发觉成员，也可以用来故障检测。Gossip有多种详细实现，Daynamo中使用的是Anti-entropy实现。据说早期Dynamo的做法类似corosync，是在每台节点上维护一个全部节点状态的全局视图。