从Paxos到Zookeeper分布式一致性原理与实践

2017-01-18
第1章 分布式架构
  • 1-从集中式到分布式
  • 分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
  • 分布式系统特性：分布性、对等性、并发性、缺乏全局时钟、故障总是会发生。
  • 分布式环境中的问题：通信异常、网络分区、三态(成功、失败、超时)、节点故障

  • 从ACID到CAP/BASE; Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性；

  • 标准SQL规范中定义了4个事务隔离级别：
    1. 未授权读取即读未提交允许出现脏读
    2. 授权读取即只允许读取已经被提交的数据
    3. 可重复读取即多次读取同一个数据时，其值和事务开始时刻是一致的，禁止了不可重复读和脏读，可能出现幻影数据
    4. 串行化即最严格事务隔离级别，事务串行执行。
  • CAP和BASE理论：
    1. Consistency一致性、Availability可用性、Partition tolerance分区容错性。
    2. BASE：Basically Avaliable基本可用、Soft state软状态和Eventually consistent最终一致性的简写
  • 最终一致性存在以下5种变种
    1. 因果一致性
    2. 读已之所写
    3. 会话一致性
    4. 单调读一致性
    5. 单调写一致性
第2章 一致性协议
  • 2PC与3PC
    • 2PC:
1. 提交事务请求(投票阶段)
 1. 事务询问
 2. 执行事务,各参与者节点执行事务操作并将Undo和Redo信息记入事务日志中
 3. 各参与者向协调者反馈事务询问的响应
  
2. 执行事提交(根据阶段一的反馈情况决定最终是否可以进行事务提交操作)
    	1. 执行事务(阶段一都返回Yes响应)
        1. 发送提交请求，协调者向所有参与者发出Commit请求
        2. 事务提交，参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
        3. 反馈事务结果,参与者在事务完成后向协调者发送Ack消息
        4. 完成事务，协调者接收到所有参与者反馈的Ack消息后，完成事务。
    	2. 中断事务，任何一个参与者向协调者反馈了No响应或者等待超时后，协调者无法接收到所有参与者的反馈响应，就中断事务
      	1. 发送回滚请求，协调者向所有参与者发出Rollback请求
      	2.事务回滚，参与者接收到Rollback请求后，会利用阶段一中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放整个事务执行期间的资源
      	3. 反馈事务回滚结果，参与者完成事务回滚后向协调者发送Ack消息
      	4. 中断事务，协调者接收到所有参与者反馈的Ack消息，完成事务中断。

  • 优缺点:优点，原理简单、实现方便。缺点:同步阻塞、单点问题、数据不一致比如commit阶段一部分成功一部分网络问题无法提交产生数据不一致、太过保守容错机制差。

  • 3PC: 将2PC协议的第二个阶段过程一分为二，形成由CanCommit、PreCommit和do Commit三个阶段组成的事务处理协议。

1. CanCommit
	1. 事务询问
      	2. 各参与者向协调者反馈事务询问的响应
    
2. PreCommit
      	1. 执行事务预提交(所有参与者反馈Yes)
		1. 发送预提交请求
		2. 事务预提交
		3. 各参与者向协调者反馈事务执行的响应
      	2. 中断事务(所有参与者有任意一个反馈No，或者等待超时无法接收到参与者的反馈)
		1. 发送中断请求
		2. 中断事务，无论是来自协调者的abort请求还是出现等待超时参与者都中断事务

3. doCommit
	1. 执行事务
	  	1. 发送提交请求，参与者从预提交状态转到提交状态，并向所有参与者发送doCommit请求
	  	2. 事务提交，提交事务并在之后释放事务执行期间占用的事务资源
	  	3. 反馈事务提交结果，参与者向协调者发送Ack消息
	  	4. 完成事务，协调者接收到所有参与者反馈的Ack消息后完成事务
	
	2. 中断事务
	  	1. 发送中断请求
	  	2. 事务回滚
	  	3. 反馈事务回滚结果
	  	4. 中断事务
  • 一旦进入阶段三，可能存在以下问题
    1. 协调者出现问题
    2. 协调者和参与者之间的网络故障

  • 无论出现那种情况，都导致参与者无法及时接收到来自协调者的doCommit或者abort请求，针对这种异常，参与者都会在等待超时后，继续进行事务提交。

  • 三阶段优缺点：
    • 优点：相比二阶段降低参与者的阻塞范围，并能在出现单点故障后达成一致
    • 缺点：三阶段去除阻塞的同时引入了新的问题，就是在参与者接收到preCommit消息后如果网络出现分区，此时协调者所在的节点和参与者都无法正常网络通信，这种情况下，参与者依然会进行事务提交，必然导致数据的不一致性
  • Paxos算法 莱斯利-兰伯特 LeslieLamport
    • “拜占庭将军问题”, 为解决这个问题提出了 Paxos理论。核心算法是一致性算法。
    • TODO Paxos
第3章 Paxos的工程实践
  • Google Chubby P52 TODO
第4章 ZooKeeper与Paxos
  • Zookeeper并未采用Paxos算法,而是采用了一种ZAB(Zookeeper Atomic Broadcast)的一致性协议
  • Zookeeper保证如下分布式一致性特征,顺序一致性,原子性,单一视图，可靠性,实时性
  • Zookeeper四个设计目标: 简单的数据模型，可以构建集群，顺序访问，高性能
  • Zookeeper集群角色，没有沿用传统的Master/Slave概念，采用Leader,Follower,Observer三种角色。Leader提供读写服务,Follower、Observer都提供读服务，区别在于，Observer不参与Leader的选举过程,也不参与写操作的，"写过半成功"策略,因此Observer在不影响写性能的情况提升了集群的读性能。
  • 会话Session,客户端和服务器创建TCP的长连接开始即会话开始，只要网络断开时间小于sessionTimeout时间值能重新连接上集群中的任意一台服务器，则之前的会话仍然有效。
  • 数据节点Znode,分为持久节点和临时节点。Watcher，ACL(Access Control Lists)
ZAB协议
  • ZAB核心是定义了对于那些会改变Zookeeper服务器数据状态的事务请求的处理方式,即:

所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则称为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal提议，并将该Proposal分发给集群中所有的Follower服务器，之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数Follower服务器进行正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交

  • ZAB两种基本模式:崩溃恢复和消息广播

恢复模式: 当整个服务框架在启动过程中，或是当Leader服务器出现网络中断，崩溃退出或重启等异常情况，ZAB协议就进入恢复模式并选举产生新的Leader服务器，然后同步数据状态给所有Follower，当集群中有过半的机器与Leader完成状态同步则ZAB退出恢复模式，从而进入消息广播模式。

  • 超过半数投票机制,指自己也算一票。比如3台，一台挂了，是可以产生Leader的。
  • 消息广播,可以类比2PC阶段
  • ZAB协议规定:任何时候都需要保证只有一个主进程负责进行消息广播，而如果主进程崩溃了，就需要选举出一个新的主进程，主进程的选举机制和消息广播机制是紧密相关的。
  • ZAB协议主要包括消息广播和崩溃恢复两个过程。进一步可以细分为三个阶段，发现Discovery,同步Synchronization和广播Broadcast阶段，组成ZAB协议的每一个分布式进程会循环地执行这三个阶段，我们将这样一个循环称为一个主进程周期。
  • ZAB协议的设计中，每一个进程都有可能处于以下三种状态之一。
LOOKING: Leader选举阶段，启动的初始状态
FOLLOWING: Follower服务器和Leader保持同步状态
LEADING: Leader服务器作为主进程领导状态
  • ZAB与Paxos算法的联系与区别
两者的联系: 
1. 都存在一个类似Leader进程的角色，由其负责协调多个Follower进程的运行
2. Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交
3. 在ZAB协议中，每个Proposal中都包含了一个epoch值，用来代表当前的Leader周期，在Paxos算法中，同样存在这样一个标识，名字Ballot
  • 两者的区别:
  1. 在Paxos算法中，一个新选举产生的主进程会进行两个阶段的工作。第一阶段被称为读阶段，这个阶段中新的主进程会通过和所有其他进程进行通信的方式收集上一个主进程提出的提案并将它们提交。第二阶段被称为写阶段，这个阶段，当前主进程开始提出它自己的提案。在Paxos算法设计的基础上，ZAB协议额外添加了一个同步阶段，有效保证Leader在新的周期中提出事务Proposal之前，所有进程都已经完成了对之前所有事务Proposal的提交，一旦完成同步阶段后，那么ZAB就会执行和Paxos算法类似的写阶段。
  1. ZAB协议主要用来构建一个高可用的分布式数据主备系统，比如Zookeeper。而Paxos算法则用于构建一个分布式的一致性状态系统。
第5章 使用Zookeeper
zoo.cfg
集群配置:
server.id=host:port:port //id标识集群机器序号,范围1~255
  • ZK节点ACL权限，CREATE,READ,WRITE,DELETE,ADMIN。注意删除，指对子节点的删除权限，其他4中指对自身节点的操作权限
  • 身份认证,world,auth,digest(用户名:密码),ip
  • 其他需要多练习,开源客户端，ZkClient, Curator
第6章 Zookeeper的典型应用场景
  • 数据发布/订阅，即配置中心
特点:
1. 数据量通常比较小
2. 数据内容在运行时会发生变化
3. 集群各机器共享，配置一致
  • 负载均衡(Load Balance)
  • 命名服务(Name Service)
  • 分布式协调/通知
  • 心跳监测
  • 工作进度汇报
  • 系统调度
  • 利用客户端Zookeeper的Watcher监听与Zookeeper上创建临时节点可以监测机器存活性监控的系统
  • 分布式日志收集系统
  • Master选举
  • 分布式锁
  • 分布式队列
  • 分布式屏障

TODO 198

第7章 Zookeeper技术内幕
第8章 Zookeeper运维

最新文章