Zookeeper学习笔记

Zookeeper学习笔记

学习Zookeeper做的笔记。

目录

1、概述。

2、特点。

3、数据结构。

4、应用场景。

（1）统一命名服务。

（2）统一配置信息管理，元数据信息管理。

（3）统一集群管理。

（4）服务器节点动态上下线。

（5）软负载均衡。

（6）分布式协调。

（7）HA高可用性。

（8）分布式锁。 

5、zookeeper命令。

6、zookeeper配置文件。

7、集群安装。

8、选举机制，第一次启动时选举。

9、选举机制，非第一次启动选举。

（1）非第一次启动选举的几个概念。

（2）非第一次启动选举产生的原因。

（3）集群中的leader挂掉了，选举leader规则。

（4）集群中的leader挂掉了，选举过程。

10、zookeeper客户端命令行。

（1）zk命令。

（2）查看当前节点详细数据。

11、节点类型。

12、zookeeper监听原理。

（1）zookeeper监听原理。

（2）zookeeper server的监听机制。

（3）常见的监听。

1）监听节点数据的变化。

2）监听子节点增减的变化。

3）节点删除与查看。

13、客户端向服务端写数据流程。

（1）写请求 *** 作直接发送给leader节点。

（2）写请求 *** 作发送给follower节点。

14、zookeeper算法基础。

（1）拜占庭将军问题。

（2）Paxos描述的场景。

（3）zookeeper与Paxos。

（4）Paxos算法流程。

（5）无主模型、有主模型。

（6）ZAB协议。

15、CAP原则（CAP理论，CAP定理）。

16、zookeeper的数据存储方式，存储模型。

17、数据的一致性。

（1）强一致性。

（2）弱一致性。

（2.1）最终一致性。

（2.1.1）因果一致性（Causal consistency）。

（2.1.2）读己之所写一致性（Read your writes）。

（2.1.3）会话session一致性（Session consistency）。

（2.1.4）单调读一致性（Monotonic read consistency）。

（2.1.5）单调写一致性（Monotonic write consistency）。

（3）顺序一致性。

（4）base理论。

18、zookeeper角色分配。

19、zookeeper的部署。

---

1、概述。

Zookeeper是一个开源的、分布式的、为分布式框架提供协调服务的Apache项目。

基于观察者模式设计的分布式服务管理框架，负责存储和管理大家都关心的数据，接受观察者的注册。

一旦数据状态发生变化，zookeeper就负责通知已经在zookeeper上注册的那些观察者做出相应的反应。

2、特点。

半数以上节点存活，zookeeper就能正常服务，奇数部署。

全局数据一致性，每个节点保存相同的数据副本。

更新请求顺序执行，来自同一个客户端的更新请求按其发送顺序依次执行。

每次写 *** 作都有事务id（zxid），数据更新原子性，一次数据更新要么成功，要么失败。

实时性，在一定时间范围内，客户端能读取最新数据。

3、数据结构。

数据模型的结构与Linux文件系统很类似，每一个ZNode节点默认能够存储1MB的数据，有唯一的路径标识。

4、应用场景。 （1）统一命名服务。

 在分布式环境下，经常需要对应用、服务进行统一命名，便于识别。

例如：IP不容易记住，用域名代替IP访问。

（2）统一配置信息管理，元数据信息管理。

 分布式环境下，配置文件同步，一个集群中，所有节点的配置信息一致。将配置信息写入zk上的ZNode节点，客户端监听这个ZNode，对配置信息修改后，节点中的数据被修改，修改信息同步到各个节点，zk通知客户端服务器。

以使用dubbo为例，其他依赖zookeeper才可以使用的程序类似，例如：Kafka、Disconf等。

1）服务A有3个服务器节点，将服务A注册到dubbo注册中心。

2）注册中心把服务A的注册信息（元数据/配置信息）保存到zookeeper上面。zookeeper知道了服务A在这3台服务器上面【192.168.0.1、192.168.0.2、192.168.0.3】。

3）调用者希望使用服务A提供的服务，需要获取服务A的地址。

4）调用者需要获取服务A的地址。

      如果服务A已经注册上来了，zookeeper把已经知道的服务A地址返回给调用者。

      如果服务A还没有注册上来，dubbo注册中心在zookeeper上注册一个服务A的地址的监听器。

5）当服务A可用时，zookeeper通知dubbo注册中心。

6）dubbo注册中心再通知调用者。

7）调用者就可以知道服务A在这3台服务器上面【192.168.0.1、192.168.0.2、192.168.0.3】，同时调用者缓存服务A的地址。

（3）统一集群管理。

 分布式环境中，实时掌握每个节点的状态变化，zk可以实时监控每个节点的状态变化。将

信息写入ZNode节点，监听这个节点实时状态，根据节点状态作出调整。

 

（4）服务器节点动态上下线。

 客户端能实时洞察到服务器的上下线的变化。

1）服务端启动时去注册信息到zookeeper集群，创建的都是临时节点。

2）获取到当前在线服务器列表，并且监听。

3）服务器2节点下线了。

4）服务器节点上下线事件，事件通知。

     客户端1收到服务器2下线通知。

5）客户端1在process()方法中处理逻辑。

process() {

    //重新再去获取服务器列表，并且注册监听。

}

（5）软负载均衡。

在zk中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求。

 

（6）分布式协调。

 对分布式的系统去协调他们的工作，假设要协调多个系统去完成一个请求，某个系统要得到另外一个系统的处理结果或者状态，然后根据返回的结果或状态去做一些处理。实现多个系统之间相互协作的一个过程。

 

1）用户发起一个提交订单的请求。
2）系统A保存一个订单信息，订单编号order=1。
3）系统A写一个消息到MQ。
4）系统A对订单编号order=1，在zookeeper node节点上注册一个监听器。
5）系统B从MQ中消费到消息，然后处理消息。
6）系统B对订单【order=1】的node，更新它的值：finish_update。
7）订单【order=1】的node值发生变化：finish_update，zookeeper通知系统A。
8）此时，系统A知道系统B已经执行成功了。系统A根据结果做后续处理。 

 

（7）HA高可用性。

1）两个同样的服务系统A。worker01在zookeeper上创建一个临时节点active(node):worker01。
2）worker02在zookeeper上注册一个监听器，知道worker01已经在zookeeper上创建了一个临时节点。
3）worker01宕机了，worker01创建的临时节点会被zookeeper删除。
4）zookeeper通知worker02，worker01已经宕机了，临时节点已经被删除了。
5）worker02在zookeeper上创建一个同名的临时节点active(node):worker02。worker02从备用服务变成主服务。
6）当worker01服务恢复时，看到worker02已经在zookeeper上注册了临时节点。
    此时，worker01就会在zookeeper上注册一个监听器，worker01由主服务变成备用服务。

（8）分布式锁。 

 

 1）两个同样的系统A服务，worker01与worker02两个一起去尝试获取zookeeper锁。

  worker01先获取到了zookeeper的锁，准备创建一个临时节点，如果临时节点不存在，

worker01就可以创建成功，现在这个锁属于worker01。

2）worker02尝试去创建一个相同名称的临时节点，如果临时节点已经存在，说明有其它服务已经占用了这把锁，此时会创建失败，worker02在zookeeper上对临时节点注册一个监听器。

3）worker01执行一些业务处理之后，释放zookeeper上的锁，删除临时节点。

4）zookeeper通知worker02，worker01创建的临时节点被删除了，没有占用锁了。

 worker02尝试去zookeeper创建一个相同名称的临时节点，此时节点不存在，worker02可以创建成功，worker02就获得了锁。

5、zookeeper命令。

启动zookeeper服务端命令：bin/zkServer.sh start

停止zookeeper服务端命令：bin/zkServer.sh stop

查看java应用进程命令：jps 或者 jps -l

启动客户端命令：bin/zkCli.sh

启动某个服务器上的客户端：bin/zkCli.sh -server xinxin001:2181

ls  查看有哪些节点。

quit 退出。

bin/zkServer.sh status  查看zookeeper处于什么状态。

6、zookeeper配置文件。

conf目录下的zoo_sample.cfg，安装zookeeper时，修改文件名为zoo.cfg。

配置文件解读：

（1）tickTime = 2000

通信心跳时间，单位毫秒，客户端与zookeeper服务器之间的心跳时间，服务器与服务器之间的心跳时间。

（2）initLimit = 10

Leader和Follower初始连接时能容忍的最多心跳次数。最长时间为次数x通信心跳时间，initLimit x tickTime。超过这个时间就认为是失败的。

（3）syncLimit = 5

 Leader和Follower之间建立连接后的通信次数，最长时间为次数x通信心跳时间，syncLimit x tickTime。超过这个时间Leader认为Follower已挂掉，从服务器列表中删除Follower。

（4）dataDir

 保存zookeeper中的数据，安装时需要修改，不能存放在默认的tmp临时目录中。

（5）clientPort = 2181

 客户端连接端口。客户端与服务器端通信的端口号。

7、集群安装。

重点：在data数据目录下创建一个myid的文件，zookeeper源代码中读取的是名称为myid的文件，在文件中添加server对应的编号数字。

在zoo.cfg文件中添加server配置。

server.A = B:C:D。

A是一个数字，表示这个是第几号服务器。对应myid文件中的数字编号。

B是服务器的地址。

C是Follower与Leader之间交换信息的端口。

D是Leader服务器挂了之后，使用这些端口来选举，选举时相互通信的端口。

例如：

server.1 = 192.168.0.101:2888:3888

server.2 = 192.168.0.102:2888:3888

server.3 = 192.168.0.103:2888:3888

8、选举机制，第一次启动时选举。

选举分为两种，第一次启动服务时选举。Leader挂掉后，非第一次启动选举。

（1）第一次启动时选举。 

 假设有5个zookeeper服务，server1、server2、server3、server4、server5分别代表服务器1、2、3、4、5。当大于半数以上，大于等于3票时，选举成功。

选举过程如下。

1）服务器1启动，发起一次选举。服务器1投自己1票。此时服务器1票数为1票，不够半数以上，票数没有大于等于3票，选举无法完成，服务器1状态保持为LOOKING。

2）服务器2启动，发起一次选举。服务器1投自己1票，服务器2投自己1票。

    然后交换选票信息，服务器1发现服务器2的myid比自己目前投票的大，服务器2的myid大于服务器1的myid，服务器1更改投票，把票投给服务器2。

    此时投票结果，服务器1的票数为0，服务器2的票数为2，不够半数以上，票数没有大于等于3票，选举无法完成，服务器1和服务器2的状态为LOOKING。

3）服务器3启动，发起一次选举。服务器1投自己1票，服务器2投自己1票，服务器3投自己1票。

    然后交换选票信息，服务器3的myid比服务器1和服务器2的大，服务器1和服务器2更改投票，投给服务器3.

    此时投票结果，服务器1和服务器2的票数都为0，服务器3的票数为3，服务器3的票数已经达到半数以上，票数等于3票，服务器3当选为leader。

    服务器1、服务器2更改状态为FOLLOWING，服务器3的状态从LOOKING改为LEADING。

4）服务器4启动，发起一次选举。服务器4投自己1票，交换选票信息，服务器1、服务器2、服务器3的状态不是LOOKING状态，不会更改选票信息。

    此时投票结果，服务器3的票数为3，服务器4的票数为1。

    服务器4遵从少数服从多数原则，服务器4更改投票，投给服务器3。

    服务器3的票数变成了4票，服务器4的状态从LOOKING改为FOLLOWING。

5）服务器5启动，发起一次选举。服务器5投自己1票，交换选票信息，服务器1、服务器2、服务器3和服务器4的状态都不是LOOKING状态，不会更改选票信息。

    此时投票结果，服务器3的票数为4，服务器5的票数为1。

    服务器5遵从少数服从多数原则，服务器5更改投票，投给服务器3。

    服务器3的票数变成了5票，服务器5的状态从LOOKING改为FOLLOWING。

总结：选票投给myid比较大的服务节点，遵从大多数原则（少数服从多数原则）和先到先得原则。某个服务节点票数超过半数，既当选为Leader，后续启动的服务器节点只能服从已经存在的leader，即使myid大也只能服从。

投票过半时服务器ID（myid）大的胜出。

myid文件在zookeeper data目录下创建，在里面配置一个数字编号。

9、选举机制，非第一次启动选举。 （1）非第一次启动选举的几个概念。

 SID（myid）：服务器ID，与myid相等，用来唯一标识一台zookeeper集群中的机器，每台机器不能重复。

 ZXID：事务ID。每次写 *** 作都会有事务id，每一次 *** 作集群，更改集群状态的 *** 作都会产生一个事务ID（zxid）。

EPOCH：每个leader的任期代号，每一个leader存在时会产生一个类似“历史朝代”的代号。没投完一次票，这个数字就会增加。没有leader时同一轮投票过程中的逻辑时钟值是相同的。

（2）非第一次启动选举产生的原因。

 1）某个follower节点挂掉了，或掉线了。

follower服务器5运行期间无法与leader服务器3保持连接。服务器5认为zookeeper集群中已经没有leader了。实际上，集群中已经存在leader。服务器5尝试去选举leader，服务器5投自己1票，当服务器5可以连上集群时，交换信息，会被告知集群中已经存在leader信息，服务器5服从已经存在的leader，进行信息和状态的同步，服务器5的状态从LOOKING改为FOLLOWING。

2）集群中的leader挂掉了。

（3）集群中的leader挂掉了，选举leader规则。

1）任期代号EPOCH大的直接胜出。

2）任期代号EPOCH相同，事务id（zxid）大的胜出。

3）事务ID（zxid）相同，服务器id（myid）大的胜出。

（4）集群中的leader挂掉了，选举过程。

1）leader服务器3挂掉，follower服务器5挂掉。服务器1、服务器2和服务器3参与选举。

2）首先比较任期代号EPOCH，epoch都为1。 

3）任期代号EPOCH相同，比较事务ID（zxid）。服务器1、服务器2的zxid为8，服务器4的zxid为

7，服务器4的zxid小于服务器1和服务器2，服务器4选举被淘汰。

4）服务器1和服务器2的事务ID（zxid）相同，比较服务器ID（myid）。

     服务器2的myid大于服务器1的myid，服务器2胜出，服务器2当选为leader。

总结：EPOCH任期ID大的直接胜出。如果EPOCH任期ID相同，比较事务ID（zxid），事务ID大的胜出。如果事务ID相同，比较服务ID（myid），服务ID大的胜出。

myid是安装时在data目录下创建的，myid会配置成不同的数字编号。

10、zookeeper客户端命令行。 （1）zk命令。

 create 创建一个节点。-s创建带序列节点，-e创建临时节点，临时节点zookeeper重启或超时会消失。

 delete 删除一个节点。

 deleteall path删除一个路径上的多个节点，递归删除节点。

get可监听节点，获得节点的值。 -w监听节点内容变化。-s附加次级信息。注册一次，只能监听一次。

history查看历史信息。

ls查看节点，可以监听节点，-w监听子节点变化，-s附加次级信息。

ls2查看节点信息和值。

quit退出。

set修改节点的值，设置节点的具体值。

stat显示节点信息，查看节点状态。

sync同步数据。

（2）查看当前节点详细数据。

 ls -s /

1）czxid：创建节点的事务zxid。每次修改zookeeper都会产生一个zookeeper事务ID，事务ID是zookeeper中所有修改总的次序，每次修改都有唯一的zxid。

2）ctime：znode被创建的毫秒数，创建节点时的毫秒数。

3）mzxid：znode最后更新的事务zxid。

4）mtime：znode最后修改的毫秒数。

5）pzxid：znode最后更新的子节点zxid。

6）cversion：znode子节点变化号，znode子节点修改次数。

7）dataversion：znode数据变化号。

8）aclversion：znode访问控制列表的变化号。

9）ephemeralowner：如果是临时节点，这个是znode拥有者的sessionid。如果不是临时节点，则是0。

10）datalength：znode的数据长度。

11）numchildren：znode子节点数量。

11、节点类型。

持久是指客户端和服务器断开连接后，创建的节点不删除。

创建永久节点，不带序号。

create  /znodename  znodevalue

ls  /  znodename   查看。

get  -s  /znodename  获取节点中的值。

创建永久带序号节点。

create  -s  /znodename  znodevalue

短暂临时是指客户端和服务器端断开连接后，创建的节点自己删除。

创建临时不带序号节点。

create  -e  /znodename  znodevalue

创建临时带序号节点。

create  -e -s  /znodename  znodevalue

修改节点数据值。

set  /znodename  znodevalue

12、zookeeper监听原理。 （1）zookeeper监听原理。

 1）首先有一个main()线程。

2）在main()线程创建zookeeper客户端，此时就会创建两个线程，一个负责网络连接（connect），一个负责监听（listener）。

3）通过connect线程将注册的监听事件发送给zookeeper。

4）在zookeeper的注册监听器列表中将注册的监听事件添加到内部中。

5）zookeeper监听到有数据或路径的变化，就会将这个消息发送给listener线程。

6）listener线程内部调用process()方法。

（2）zookeeper server的监听机制。

 一个watch事件是一个一次性的触发器，当被设置了watch的数据发生了改变的时候，则服务器将这个改变发送给设置了watch的客户端，以便通知它们。

zookeeper的znode类似文件系统，有通知机制，使用观察者模式通知数据改变。

 数据监视：getdate()、exists()。

 子节点数据监视：getchildren()。

 watch监听类型。

 内容监听get：get /path [watch]。

 目录结构监听ls：ls /path [watch]。

 有监听状态的stat：stat /path [watch]。

 父节点watch事件类型：

1）创建父节点触发：NodeCreated。

2）修改父节点数据触发：NodeDataChanged。

3）删除父节点触发：NodeDeleted。

子节点watcher事件类型：使用ls命令为父节点设置Watch。

1）子节点创建时触发：NodeChildrenChanged。

2）子节点删除：NodeChildrenChanged。

3）子节点修改时，不触发事件。

（3）常见的监听。 1）监听节点数据的变化。

 get path [watch]

 get -w /znodename

 set /znodename znodevalue

2）监听子节点增减的变化。

 ls path [watch]

 ls -w /znodename

 create /znodename/childznodename  value

3）节点删除与查看。

删除节点。

delete /znodename

递归删除节点。

deleteall  /znodename

查看节点状态。

stat  /znodename

13、客户端向服务端写数据流程。 （1）写请求 *** 作直接发送给leader节点。

 

 1）客户端发起写 *** 作请求。

2）leader收到请求之后，自己写一份数据。把写请求通知zk server2 follower，zk server2  follower写一份数据。

3）zk server2 follower写完之后，ack应答通知leader已经写完数据了。

4）集群有3台服务器，1个leader和1个follower写完了，超过了半数zk节点。

   leader通知客户端，ack应答通知客户端，已经写好了，客户端可以继续后续 *** 作。

5）leader继续通知另一台zk server3 follower服务器写数据。

6）zk server3 follower同步更新数据，ack应答通知leader已经写完数据了。

（2）写请求 *** 作发送给follower节点。

 1）客户端发起写 *** 作请求。zk server2 follower接收到客户端的写请求 *** 作。

2）zk server2 follower将写请求转给leader，leader自己先写一份数据。

3）leader写完数据之后，leader发送写命令给zk server2 follower，zk server2 follower也写一份数据。

4）zk server2 follower写完数据之后，ack通知leader数据已经写好。

5）集群中有3台服务器，leader自己写了1次数据，zk server2 follower写了1次数据，超过了半数zk节点。

leader通知接受客户端请求的zk server2 follower，数据已经写好了。

6）接受客户端请求的zk server2 follower通知客户端，已经写好数据了。

7）leader继续通知另一台zk server3 follower写数据。

8）zk server3 follower同步更新数据，zk server3 follower通知leader已经写好数据。

14、zookeeper算法基础。 （1）拜占庭将军问题。

 拜占庭将军问题是一个协议问题，拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。

 对于分布式系统来说，多台服务器来处理某一个问题的一致性问题，达成最终一致。

（2）Paxos描述的场景。

1）有一个叫做Paxos的小岛(Island)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)。

2）议员的总数(SenatorCount)是确定的，不能更改。

3）岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒退。

4）每个提议都需要超过半数((SenatorCount)/2+1)的议员同意才能生效。

5）每个议员只会同意大于当前编号的提议，包括已生效的和未生效的。

6）如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号，他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。

现在议会有一个目标：保证所有的议员对于提议都能达成一致的看法。

总：Paxios小岛开会，议员负责提交议案、投票，议员的数量是固定的。例如：议员数5，计算投票超过半数才有效。提议的编号是一直增长的，每个议员只会同意大于当前编号的提议。

（3）zookeeper与Paxos。

小岛(Island)  ——    ZK Server Cluster

议员(Senator)  ——  ZK Server

提议(Proposal)  —— ZNode Change(Create/Delete/SetData…)

提议编号(PID)  —— Zxid(ZooKeeper Transaction Id)

正式法令  ——  所有ZNode及其数据

（4）Paxos算法流程。

1）Paxos算法。

 一种基于消息传递且具有高度容错特性的一致性算法。

2）Paxos算法解决的问题。

如何快速正确的在一个分布式系统中对某个数据值达成一致，并且保证不发生任何异常，都不会破坏整个系统的一致性。

3）Proposer（提议者）、Acceptor（接受者）、Learner（学习者）。

（5）无主模型、有主模型。

 无主模型。

1）“从”都会发送指令，投票。

 投票人数有可能导致分区，分不同的阵营，6个节点两个阵营，形成3-3对立，类似以前的“党挣”。

2）事务编号混乱，每个节点都有可能有自己的提议。

 提议的编号不能重复和小于。

3）主要集群中节点数目高于1/2 + 1，集群就可以正常运行。

有主模型。

1）只能有一个“主”发送指令，发送提议。由主来决定提议的编号。

2）单主会有单点故障。故障时，重新选举，切换备用节点。

3）如果存在多个主就会出现脑裂。

Paxos算法没有leader，可能出现活锁的情况，所以出现了ZAB协议，ZAB协议中只有一个leader，其他都是follower。

Paxos是无主模型，ZAB是有主模型。

（6）ZAB协议。

 借鉴了Paxos算法，是特别为zookeeper设计的支持崩溃恢复的原子广播协议。

基于该协议，zookeeper设计为只有一台客户端leader负责处理外部的写事务请求，然后leader客户端将数据同步到其他follower节点。

zookeeper只有一个leader可以发起提案。

ZAB协议包括两种基本的模式：消息广播、崩溃恢复。

15、CAP原则（CAP理论，CAP定理）。

一个分布式系统中不能同时满足以下三种：C一致性、A可用性、P分区容错性。

最多只能满足其中两项，分区容错性P是必须的，一般是达到其中两项。例如：CP、AP。

 

（1）一致性（C：Consistency）。

 在多个副本之间能够保持数据的一致性。

（2）可用性（A：Available）。

 分布式系统提供的服务一直处于可用状态，对于用户的请求 *** 作能够在有限的时间内返回结果。

（3）分区容错性（P：Partition Tolerance）。

分布式系统在遇到任何网络分区故障时（部分服务节点故障），仍然能够对外提供满足一致性和可用性的服务。除非整个网络环境发生了故障。

    zookeeper保证的是CP（保证一致性和分区容错性）。zookeeper不能保证每次服务请求都可用，zookeeper在选举时是不可用的。

    zookeeper备份数据是全量备份的，每个节点上有完整的数据，数据是弱一致性的，最终一致性。

16、zookeeper的数据存储方式，存储模型。

 数据存储的方式有全量备份raid1、数据切片raid0、数据冗余raid5等。

zookeeper采用的是全量备份raid1方式存储数据。每个zookeeper server节点保存1份相同的数据副本，zookeeper client客户端无论连到那个server节点获取数据，数据都是一样的。

17、数据的一致性。 （1）强一致性。

 一个节点写入数据，所有节点更新数据，才认为保存数据成功，保持所有数据最终达到一致。

（2）弱一致性。

 只要有一个节点写入数据成功，就认为保存数据成功了。不能保证任何一次请求读取到最近一次写入的数据，但能保证最终可以读取到写入的数据。

（2.1）最终一致性。

  数据经过一段时间后，最终所有节点数据是一样的。半数以上节点保存数据成功就认为是成功的。

（2.1.1）因果一致性（Causal consistency）。

 进程A更新数据后通知进程B，进程B对数据的 *** 作基于A更新后的最新值。

 例如：产生一条朋友圈数据记录，根据这条数据记录才能评论，产生另一条评论数据记录，有因果关系。

（2.1.2）读己之所写一致性（Read your writes）。

当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧的值。

读自己的数据都从主服务器去读取，读其他进程的数据从从服务器去读取。

进程A更新数据后，访问到的值一定不比自己更新的值旧。

例如：数据库先update再select，select到的不比刚才update的值版本更旧。

（2.1.3）会话session一致性（Session consistency）。

 将读己之所写一致性限定在session生命周期内。

（2.1.4）单调读一致性（Monotonic read consistency）。

 读取一个值后，后续读到的值都不能比该值更旧。

（2.1.5）单调写一致性（Monotonic write consistency）。

 系统要保证来自同一进程的写 *** 作被顺序执行。

（3）顺序一致性。

 多个线程的整体执行可能是无序的，但对于单个线程而言，执行是有序的，要保证任何一次读取到最近一次写入的数据。有可能所有进程得到的都是修改前的数据。

（4）base理论。

base是Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性）。

base理论面向的是大型高可用高扩展的分布式系统，是实现分布式事务最终一致性的有效解决方案。

base理论是对CAP中一致性C和可用性A权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。

base理论的核心思想是：无法做到强一致性，牺牲强一致性，来换取高可用性，并允许数据在一段时间内不一致，每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性，最终达到一致状态。

18、zookeeper角色分配。

zookeeper角色分配：leader，zk server learner（follower、observer）。

leader：集群中所有写数据的指令必须由leader总统发出。

learner：查询直接返回结果，有可能数据不一致。

 写入数据：

（1）先将数据写入到当前server。

（2）其他server接受命令后开始修改数据，修改完成后给leader总统返回成功消息。

1. 当总统发现超过半数的节点都修改成功，就认为修改成功了。
2. 并将信息传递给接受请求的zookeeper server，zookeeper server将消息返回给客户端，说明数据更新完成。

 learner分类：

follower：拥有选举权，拥有投票权，可以接受客户端的访问。

observer：为客户端提供数据的查询和访问。如果客户端执行写 *** 作，只是将请求转发给leader。

ZNode：数据量不超过1M。超过半数的节点将数据更新成功，就说明数据已经是正式的了。

19、zookeeper的部署。

zookeeper部署方式有单机模式、集群模式、伪集群模式。

zookeeper集群最少需要3台服务器。

生产环境：

10台服务器：部署3台zookeeper服务器。

20台服务器：部署5台zookeeper服务器。

100台服务器：部署11台zookeeper服务器。

200台服务器：部署11台zookeeper服务器。