Zookeeper基础学习（《从Paxos到ZooKeeper：分布式一致性原理与实践》读书笔记）

Zookeeper基础学习（《从Paxos到ZooKeeper：分布式一致性原理与实践》读书笔记）

分布式一致性问题

假设客户端c1将系统中的一个值k由v1更新为v2，但客户端c2无法立即读到k的最新值，需要一段时间才能读到，这个例子就是常见的数据库之间复制的延时问题。

分布式系统对于数据复制需求一半都来自于以下两个原因：

• 为了增强系统的可用性，以防止单点故障引起的系统不可用。
• 提高系统的整体性能，通过负载均衡技术，能够让分布在不同地方的数据副本都能够为用户提供服务。

分布式一致性问题：指在分布式环境中引入数据复制机制后，不同数据节点间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致情况。简单地讲，数据一致性就是指在对一个副本数据进行更新的时候，必须确保也能够更新到其他的副本，否则不同副本之间的数据将不一致。

总的来讲，我们无法找到一种能够满足分布式系统属性（性能与安全性）的分布式一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑与权衡的。于是，一致性级别由此诞生。

• 强制一致性

  用户体验好，对系统性能影响大。

• 弱一致性

  这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不具体承诺多久之后数据到达一致，但会尽可能的保证到某个时间级别（比如秒级别）后，数据能够到达一致状态。弱一致性还可以在进行细分：

  • 绘画一致性：只保证对于写入的值，在同一个客户端绘画中可以读到一致的值，但其他的会话不能保证。
  • 用户一致性：只能保证对于写入的的值，在同一个用户中可以读到一致的值，其他的用户不能保证。

• 最终一致性

  这是弱一致性的一个特例，系统会保证在一定时间内，能够到达一个数据一致的状态。

分布式的特点

分布式系统是一个硬件或者软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

分布性

分布式系统的多台计算机都会在空间上随意分布，同时，机器的分布也会随时变动。

对等性

系统中的计算机没有主从之分，各个计算机节点都是对等的。

在常见的分布式系统中，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。数据副本是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从该副本上读取到该数据。服务副本指的是多个节点提供同样的服务，每个节点都有能力接受来自外部的请求并进行相应的处理。

并发性

多个节点可能并发地操作一些共享的资源。

缺乏全局时钟

一个典型的分布式系统是由一系列在空间上随意分布的多个进程组成的，具有明显的分布性，这些进程之间通过交换消息来进行相互通信。

很难定义两个时间究竟谁先谁后，原因就是分布式系统缺乏一个全局的时钟序列控制。

一致性协议

二阶段提交协议，三阶段提交协议，Paxos算法。

2PC与3PC

在分布式系统中，虽然每一个节点都可以知道自己的事务操作结果，但无法知道其他的节点的操作结果。

因此，当一个事务操作需要跨越多个分布式节点时，为了保证事务处理的ACID特性，就需要引入一个被称为“协调者”的组件来统一调度所有分布式节点的执行逻辑，这些被调度的的节点被称为“参与者”。

二阶段提交

利用该协议可以非常方便的完成所有分布式事务参与者的协调，统一决定事务的提交和回滚，从而能够有效的保证分布式数据的一致性。

阶段一：提交事务请求

1. 事务询问

   协调者向所有参与者发送事务内容，询问是否可以执行事务提交工作，并开始等待响应

2. 执行事务

   各参与者节点执行事务操作，并将undo和redo信息记入事务日志中

3. 个参与者向协调者反馈事务询问的响应

   如果参与者成功执行，则返回yes，表示事务可以执行，反之返回no

这一阶段也被称为投票阶段

阶段二：执行事务提交

协调者根据反馈情况来决定最终是否可以进行事务提交操作。

• 执行事务提交

  如果协调者收到的都是yes，则会执行事务提交

  1. 发送提交请求

     协调者向所有参与者发送commit请求

  2. 事务提交

     参与者正式执行事务提交操作，并在提交之后释放事务资源

  3. 反馈事务提交结果

     参与者完成提交后向协调者发送ack

  4. 完成事务

     协调者在接收到所有参与者反馈的ack后，完成事务

• 中断事务

  假如收到了任何一个no，或者超时之后，协调者就会中断事务。

  1. 发送回滚请求

     协调者向所有参与者发送rollback请求

  2. 事务回滚

     参与者根据阶段一中记录的undo信息执行事务的回滚操作，并在回滚之后释放事务资源

  3. 反馈事务回滚结果

     参与者完成回滚后向协调者发送ack

  4. 中断事务

     协调者在接收到所有参与者反馈的ack后，完成事务中断

简单来讲，2PC就是把将一个事务的处理分为投票和执行两个阶段。

优点：原理简单，实现方便。

缺点：同步阻塞，单点问题，脑裂，太过保守。

三阶段提交

Paxos算法

Zookeeper

初识Zookeeper

Zookeeper介绍

Zookeeper是一个开放源代码的分布式协调服务，由雅虎创建，是google chubby的开源实现。目标是将那些复杂且易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单的接口提供给用户使用。

可以基于它实现数据发布订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁和分布式队列等功能。Zookeeper可以保证如下分布式一致性特性：

• 顺序一致性

  从同一个客户端发起请求，最终将会严格地按照其发起顺序被应用到Zookeeper中去。

• 原子性

  所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的。不会出现有的机器应用了事务执行结果，有的机器没应用。

• 单一视图

  无论客户端连接的是哪个Zookeeper服务器，其看到的服务端数据模型都是一致的。

• 可靠性

  一旦服务端成功地应用了某一个事务，并完成了对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保存下来，除非有另一个事务又对其进行了更改。

• 实时性

  Zookeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

  Zookeeper设计目标

  简单地数据模型

  Zookeeper使得分布式程序能够通过一个共享的、树形结构的名字空间来进行相互协调。名字空间是指Zookeeper服务器内存中的一个数据模型，其由一系列被称为ZNode的数据节点组成。ZNode之间具有层级关系，就像文件系统的目录结构一样，Zookeeper将全量数据存储在内存里。

  可以构建集群

  组成Zookeeper集群的几台机器都会在内存中维护当前的服务器状态，并且机器间相互通信。只要集群中存在超过一半的机器能够正常工作，整个集群就可以正常对外服务。

  Zookeeper客户端会选择和集群中任意一台机器共同创建一个tcp连接，而一旦客户端和某台Zookeeper服务器之间断开之后，客户端会自动连接到及群众的其他机器。

  顺序访问

  对于来自客户端的每个更新请求，Zookeeper都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，应用程序可以使用Zookeeper的这个特性来实现更高层次的同步原语。

  高性能

  由于Zookeeper将全量数据存储在内存中，并直接服务于客户端的所有非事务请求，因此他适合用于以读操作为主的应用场景。

Zookeeper中一些基本概念

集群角色

在分布式系统中，构成一个集群的每一台机器都有自己的角色，最典型的集群模式就是Master/Slave模式（主备模式）。在这种模式中，我们把能够处理所有写操作的机器称为Master机器，把所有通过异步复制方式获取最新数据，并提供读服务的机器称为从机器。

zk中这些概念被替换成了Leader，Follower和Observer三种角色。zk集群中所有机器通过一个Leader选举过程来选定一台被称为leader的机器，leader服务器为客户端提供读写服务。follower和observer都能提供读写服务，但是observer不能参加选举，也不参与写操作的”过半写成功“策略。

会话

zk中client与server中间是一个tcp长连接。

每个session有一个session Timeout值，只要在规定的过期时间内，客户端连接断开（不管是主动还是被动）都会自动重连上集群中的任何一台机器，并且该会话仍然有效。

数据节点（ZNode）

zk把全量数据存储到内存中，数据模型是一颗树结构，由斜杠(/)进行分割的路径，就是一个znode，例如foo/path1.每个znode都会保存自己的数据内容，同时还会保存一系列的属性信息。

分为临时节点与持久节点。

版本

znode上会维护一个stat字段，里面记录了三个字段，version-当前znode版本，cversion-当前子节点版本，aversion-当前znode的acl版本。

watcher

事件监听器。

zk允许用户定义一些watcher到特定的节点上去，当发生了该事件时，zk会通知对此感兴趣的客户端的。

acl

Access Control Lists。一种权限控制策略，类似于unix文件系统的权限控制。有五种权限：

• create：创建子节点的权限
• read：获取节点数据和子节点列表的权限
• write：更新节点数据
• delete：删除子节点
• admin：设置节点acl的权利

为什么选择zk

在解决分布式数据一致性上，只有zk这个成熟稳定且被大规模应用的解决方案。

好多大型分布式项目（hadoop、hbase、solr等）都将zk作为其核心组件，用于分布式协调。

使用zk

Java环境

集群模式

下载&安装

配置zoo.cfg

tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
initLimit=5
syncLimit=2
server.1=IP1:2888:3888
server.2=IP2:2888:3888
server.3=IP3:2888:3888

• 因为在集群模式下，集群中的每台机器都需要感知整个集群是由哪几台机器组成的，在配置文件中，可以按照这样额格式进行配置，每一行都代表一个机器配置：

  server.id=host:port:port

  id被称为server id，用来表示该机器在集群中的机器序号。

  同时，我们需要在每台zk机器上，我们都需要在数据目录下创建一个myid文件，里面只有一个数字，及对应着当前机器的id。

• 集群中所有的zoo.cfg内容都应该是一致的。所以最好使用svn或者git管理起来，确保每个机器都能共享一份相同的配置。

• myid中的server.id范围为1~255

创建myid文件

在dataDir目录下，创建myid文件，内容和zoo.cfg中当前机器编号对应上。

配置其他机器

按照相同的步骤配置其他机器

启动服务器

单机模式

其实单机模式只是一种特殊的集群模式，只有一台机器的集群。

在zoo.cfg中增加

server.1=IP1:2888:3888

伪集群模式

当我们有一台比较好的机器时，我们不甘心只放一台zk，因为这样比较浪费。

通常，我们认为比较好的机器大体是——cpu核数大于10，内存大于等于8g

伪集群模式就是在一台机器上部署多个zk实例，zoo.cfg改成：

server.1=IP1.2888:3888
server.2=IP1.2889:3889
server.3=IP1.2890:3890

客户端脚本

创建

$ create [-s] [-e] path data acl

-s或者-e分别指定节点特性：顺序或者临时节点，默认情况下，表示创建的是持久节点。

create /zk-book 123
Created /zk-book

执行完上面的命令，就会在zk的根节点上创建了一个/zk-book的节点，并且节点的数据内容为“123”。

acl参数是做权控的。

读取

包括ls和get命令

ls

ls path [watch]

例如

ls / #表示查看根节点下的子节点

get

get path [watch]

我们可以该节点下的数据内容，该节点的事务id（cZxid）、最后一次更新该节点的事务id（mZxid）和最后一次更新该节点的时间等属性信息。

更新

set命令。

set path data [version]

data就是更新的内容。

节点的数据是具有版本概念的，这个参数用于指定本次更新操作是基于ZNode的哪一个数据版本进行的。

更改后dataVersion也会增加1。

删除

delete path [version]

version作用同set命令

要想删除一个指定节点，该节点必须没有子节点存在。