《从Paxos到ZooKeeper 分布式一致性原理与实践》读书笔记

一、分布式架构

1、分布式特点

  • 分布性
  • 对等性。分布式系统中的所有计算机节点都是对等的
  • 并发性。多个节点并发的操作一些共享的资源
  • 缺乏全局时钟。节点之间通过消息传递进行通信和协调,因为缺乏全局时钟,很难定义两个事件谁先谁后
  • 故障总是会发生。系统设计时,需要考虑到任何异常情况

2、分布式环境的各种问题

  • 通信异常。分布式系统中的某些节点之间无法正常通信
  • 网络分区。这有部分节点可以正常通信,有些无法正常通信。这种现象称为网络分区,也称为“脑裂”
  • 三态。节点之间的一次通信存在三种状态:成功、失败、超时
  • 节点故障。节点机器宕机、失去回应

3、传统事务的ACID理论。

  • 原子性(Atomicity)。事务内的所有操作要么全部成功,要么全部失败
  • 一致性(Consistency)。事务的执行不能破坏数据库的一致性。如果事务执行一半停了,一部分的修改写入的数据库。这时候,数据库就处于一种不正确的状态,或者说不一致的状态
  • 隔离性(Isolation)。多个事务并发执行,彼此不会受影响。事务的隔离级别:读未提交(可能发生脏读、重复读、幻象读)、读已提交(肯能发生重复读、幻象读)、可重复读(可能发生幻象读)、串行化。隔离级别越高,对并发的性能影响越大,越能保证数据库的一致性。
  • 持久性(Durablility)。一旦事务成功提交,它对于数据的修改就被永久保存下来

4、分布式事务的CAP理论和BASE理论

  • CAP理论。一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance),在分布式系统中,最多只能满足其中的两项。
  • BASE理论。基本可用(Basically Available)、软状态(Soft state)、最终一致性(Eventually consistent)。基本可用指系统出现故障时,允许损失部分可用性,包括响应时间的损失和功能上的系统降级;软状态指允许节点间的通讯出现中间状态;最终一致指系统的所有的数据副本,在一定时间的同步后,最终能够达到一致的状态

二、一致性协议

1、2PC。二阶段提交协议

阶段一,执行事务

  • 事务询问。协调者向所有参与者发送事务内容,等待参与者回应
  • 执行事务。参与者执行事务,记录Undo和Redo日志
  • 反馈事务询问响应,参与者返回给协调者Yes或No响应。全部返回Yes,进入提交事务阶段;存在No返回或者超时,进入中断事务阶段

阶段二,提交事务

  • 发送事务提交请求
  • 各个参与者提交事务
  • 参与者反馈事务提交结果
  • 如果参与者全部返回Yes,完成事务;存在返回No,进入中断事务阶段

中断事务阶段

  • 发送回滚请求
  • 事务回滚
  • 反馈事务回滚结果
  • 完成中断事务

2PC的缺点

  • 同步阻塞。各个参与者在等待其他参与者响应的同时,无法进行任何操作,处于阻塞状态
  • 单点问题。过度依赖协调者,一旦协调者出现问题,系统将无法正常运转
  • 数据不一致。同上一条,一旦协调者出现问题,就可能出现各个参与者数据不一致的问题
  • 太过保守。一旦参与者出现故障,协调者只能通过自己的超时机制发现。

2、3PC。三阶段提交协议

阶段一,CanCommit,事务询问

  • 事务询问,询问各个参与者能否完成事务
  • 各个参与者返回响应,全部返回Yes,进入PreCommit阶段

阶段二,PreCommit,事务预提交

  • 发送预提交请求
  • 事务预提交。参与者执行事务操作,记录Undo和Redo日志
  • 参与者返回响应。全部返回Yes,继续三阶段;返回No,进入中断事务阶段

阶段三,DoCommit,真正的事务提交

  • 发送提交请求
  • 参与者正式执行事务提交操作
  • 返回协调者事务执行结果
  • 协调者完成事务。如果存在返回No或者返回超时,进入中断事务阶段

中断事务阶段

  • 发送回滚请求
  • 事务回滚
  • 反馈事务回滚结果
  • 完成中断事务

3PC优缺点

  • 相较于2PC,3PC最大优点就是降低了参与者的阻塞范围
  • 缺点是,还是避免不了出现数据不一致的情况

3、Paxos算法

拜占庭将军问题,拜占庭帝国的不同军队处于不同的地理问题,他们之间只能通过通讯员进行通讯,但是通讯员是不可靠的,可能篡改消息

由于加密算法和校验算法的出现,所有实际的分布式系统之间的通讯,不存在数据被篡改的可能。

四、ZooKeeper和ZAB协议介绍

1、初识ZeeKeeper

ZooKeeper可以做什么

可以基于它实现负载均衡、集群管理、Master选举、分布式队列、分布式锁、命名服务、数据发布/订阅等功能

Zookeeper能保证的分布式一致性特性

  • 顺序一致性。同一个客户端发起的请求,会严格按照发起顺序执行
  • 原子性。对于一个事务请求,集群中的所有机器的执行情况是一致的
  • 可靠性。一旦服务端成功的应用了一个事务,并完成了对客户端的响应。服务端的状态会一直保存下来
  • 实时性。保证在一段时间内的实时性
  • 单一视图。无论客户端连接的是哪一个服务器,看到的服务端的数据模型都是一致的

Zookeeper的设计目标

  • 简单的数据模型。Zookeeper将去数据存储在内存中,采用树形结构存储,树由ZNode节点构成
  • 可以构建集群。只有集群中超过一半机器能够正常运作,整个集群就可以正常对外提供服务。
  • 顺序访问。每个来自客户端的请求,都会分配一个全局唯一的递增编号
  • 高性能。全量数据存储在内存中,3台3.4.3的Zookeeper集群,100%读请求场景的压测结果是12-13W的QPS

Zookeeper的基本概念

  • 集群角色。存在Leader、Follower、Observer三种角色。Leader服务器提供读和写服务,Follower和Observer提供读服务,但是Observer不参与选举过程,也不参与写操作的“过半写”策略,因此,Observer可以在不影响写性能的情况下提高读性能
  • 客户端会话。客户端通过TCP长连接和服务端相连,第一次建立连接就代表客户单会话开始了。客户端能够通过心跳检测与服务器保持有效的会话。Session的SessionTimeout值用来设置会话的超时时间,连接断开后,只要在超时时间之内重新连接上了集群中的任何一台服务器,那么之前创建的会话仍然有效
  • 节点。一方面只集群中的每一台机器,称为机器节点;另一方面指数据模型中的数据单元,称为数据节点Znode。Znode又分为持久节点和临时节点,临时节点的生命周期和会话绑定,一旦客户端会话失效,那么这个客户端创建的所有临时节点都会被移除。
  • 版本。每个Znode,会维护一个叫做Stat的数据结构,记录了Znode的三个版本:version(当期版本)、cversion(当前Znode子节点的版本)、aversion(当前Znode的ACL版本)。
  • Watcher。事件监听器,允许用户在一些节点上注册一些watcher。特性事件触发的时候,服务器会将事件通知到感兴趣的客户端上去。
  • ACL。权限控制策略(Access Control Lists)。定义了五种权限:Create(创建子节点)、Delete(删除子节点)、read(读取节点数据和子节点列表)、write(更新节点数据)、admin(设置节点ACL的权限)

2、ZAB协议(Zookeeper Atomic Broadcast,原子消息广播协议)

所有事务请求都由Leader服务器来处理分发,如果集群中的其他服务器收到了来自客户端的请求,这些非Leader服务器会首先将这个事务请求转发给Leader服务器,Leader负责将请求封装成Proposal(提议)分发给集群中所有Follower,一旦收到超过半数的正确反馈,Leader就会再次向所有的Follower分发Commit消息,要求他们将前一个Prosocal提交

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

  • 消息广播模式。类似于二阶段提交,去掉了中断逻辑,当Leader服务器收到了超过半数的Follower的ACK响应后,就会广播一个Commit消息给所有的Follower进行事务提交。
  • 崩溃恢复。一旦Leader服务器出现崩溃,或者由于网络原因失去了一半Follower服务器的联系,就会进入崩溃恢复模式。
  • 崩溃恢复需要确保已经被Leader提交的Proposal也能被所有Follower提交
  • 确保丢弃只在Leader服务器上提出的事务。(此处的提出指的是二阶段第一阶段)。重新选举出来的Leader拥有集群中所有服务器最高编号的事务Proposal
  • 正常情况的数据同步:Leader服务器为每一个Follower服务器准备一个队列,将那些没有被Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower,等待所有事务都同步到了Follower并成功应用到了Follower的本地数据库中后,Leader服务器就将该Follower服务器加入到真正的可用列表中
  • 事务编号ZXID,是一个64位的数字。前32位存储Leader届数,后32位记录本届Leader处理的消息数。

3、深入ZAB协议

运行分析,每一个进程都有可能处于以下三种状态之一

  • LOOKING:leader选举阶段
  • FOLLOWING:Follower服务器和Leader服务器保持同步状态
  • LEADING:Leader服务器作为主进程领导状态

五、使用Zookeeper

1、服务端部署与运行

  • 初次使用,需要把/conf目录下的zoo_sample.cfg文件重命名为zoo.cfg。配置如下:
  • 《从Paxos到ZooKeeper 分布式一致性原理与实践》读书笔记
  • server.1=IP1:2888:3888,每一行这样的配置代表一个集群中的一个机器,server.1中的1代表ServerID,同时在每台机器上需要在数据目录(dataDir指定的目录)下创建一个myid文件,文件内容就是ServerID,id范围是1~255
  • 集群中每个机器的zoo.cfg文件都应该是相同的,最好使用git或者svn把配置管理起来
  • 启动服务。/bin/zhServer.sh start
  • 停止服务。/bin/zkServer.sh stop

2、客户端脚本

  • 启动。/bin/zkCli.sh -server ip:port(不加server参数,默认连接本机)
  • 创建节点。create 【-s】【-e】path data acl。acl用来进行权限控制
  • 读取节点下子节点。ls path。例如:ls / 查看根节点下的所有子节点
  • 读取节点数据。get path
  • 更新节点数据。set path data 【version】
  • 删除节点。delete path 【version】。无法删除一个包含子节点的节点

相关推荐