分类目录:一致性协议

etcd-raft节点变更

说明 从etcd-raft的架构来看,节点变更功能的实现需要应用和底层核心协议处理层互相配合。客户端发起节点增加或移除的命令,应用获得该请求,并将其转换为一个节点变更指令交给底层的raft协议核心处理层。

etcd-raft日志管理

说明 日志是实现一致性协议的最重要手段。客户对应用发起的状态更新请求首先都会被记录在日志中,待主节点将更新日志在集群多数节点之间完成同步以后,便将该日志项内容在状态机中进行应用,进而便完成了一次客户的更新请求。

vector clock 向量时钟算法

说明 先说一下需要用到向量时钟的场景。我们在写数据时候,经常希望数据不要存储在单点。如db1,db2都可以同时提供写服务,并且都存有全量数据。而client不管是写哪一个db都不用担心数据写乱问题。但是现实场景中往往会碰到并行同时修改。导致db1和db2数据不一致。于是乎就有人想出一些解决策略。向量时钟算是其中一种。简单易懂。但是并没有彻底解决冲突问题,现实分布式存储补充了很多额外技巧。 这里反向叙述方式, 介绍向量时钟。先举实际例子让读者有个感性认识,然后再说算法规则。

PacificA:微软设计的分布式存储框架

说明 随着信息量的急剧增长,大规模的分布式存储系统变得越来越重要。这些系统往往采用廉价的商用机器或硬件,失效出错成为了分布式存储系统的常态,因此,容错是这类系统实现可用性和可靠性的关键。众所周知已然被证明是正确的的复制协议“大有人在”,但是理论距离现实还是有一定差距的,理论可以不管不顾消息在网络中传递的次数,系统性能,吞吐量,系统设计的难易问题等等,但是真实的系统设计必须以整体的性能为根本依据,因此如何权衡理论和现实系统,设计一个可用,正确,高效的复制协议变得尤为重要。这个难题同样摆在了微软的面前,相比于单纯为了需求而设计一个具体的,特定的复制协议算法,微软高明地选择设计一个简单,实用,具有普适适用性的复制框架,这样不同的策略都可借助于该框架实现,并且有助于不同的策略优劣的比较。

ZAB协议在Zookeeper中的实现

说明 ZAB 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。基于该协议,ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。 本文从“通信协议”、“核心数据结构以及API”两方面主要描述Zookeeper中ZAB协议的具体实现,重点关注ZAB协议实现中抽象的对象以及对象之间的关联。弱化请求处理流程,因为这些会在我们描述ZAB协议中重点描述。

Raft协议详解

说明 分布式存储系统通常通过维护多个副本来进行容错,提高系统的可用性。要实现此目标,就必须要解决分布式存储系统的最核心问题:维护多个副本的一致性。