Zookeeper的数据同步协议

Zookeeper采用称为Quorum Based Protocol的数据同步协议。假如Zookeeper集群有N台Zookeeper服务器(N通常取奇数，3台能够满足数据可靠性同时有很高读写性能，5台在数据可靠性和读写性能方面平衡最好)，那么用户的一个写操作，首先同步到N/2 + 1台服务器上，然后返回给用户，提示用户写成功。基于Quorum Based Protocol的数据同步协议决定了Zookeeper能够支持什么强度的一致性

强一致性(Strong Consistency)

在分布式环境下，满足强一致性的数据储存基本不存在，它要求在更新一个节点的数据，需要同步更新所有的节点。这种同步策略出现在主从同步复制的数据库中。但是这种同步策略，对写性能的影响太大而很少见于实践。因为Zookeeper是同步写N/2+1个节点，还有N/2个节点没有同步更新，所以Zookeeper不是强一致性的。

弱一致性

用户的数据更新操作，不保证后续的读操作能够读到更新后的值，但是最终会呈现一致性。牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可

CopyOnWriteArrayList是一个读写分离的并发ArrayList，它的遍历是弱一致性的，因为可以容忍并发修改，不会抛出ConcurrentModificationException，不像普通的集合，允许即时失败。

最终一致性

最终一致性本质上和弱一致性是一回事，因为一个数据存储系统满足弱一致性但是不满足最终一致性，那么这个系统的数据就是不正确，一个数据不正确的系统是一个无法交付使用的系统。Zookeeper满足最终一致性，只要数据同步到Quorum之外的节点就会达到最终一致性。

因果一致性

Zookeeper是否满足因果一致性，需要看客户端的编程方式。

不满足因果一致性的做法

1. A进程向Zookeeper的/z写入一个数据，成功返回

2. A进程通知B进程，A已经修改了/z的数据

3. B读取Zookeeper的/z的数据

4. 由于B连接的Zookeeper的服务器有可能还没有得到A写入数据的更新，那么B将读不到A写入的数据

满足因果一致性的做法

1. B进程监听Zookeeper上/z的数据变化

2. A进程向Zookeeper的/z写入一个数据，成功返回前，Zookeeper需要调用注册在/z上的监听器，Leader将数据变化的通知告诉B

3. B进程的事件响应方法得到响应后，去取变化的数据，那么B一定能够得到变化的值

4. 这里的因果一致性提现在Leader和B之间的因果一致性，也就是是Leader通知了数据有变化

第二种事件监听机制也是对Zookeeper进行正确编程应该使用的方法，所以，Zookeeper应该是满足因果一致性的

读你所写(写后读)一致性

严格来说，Zookeeper不满足读你所写一致性。因为在一个进程中，如下的操作序列是Zookeeper不能保证的，会话建立->写数据->会话关闭->会话建立->读数据，最后的读数据不一定读到之前写的数据。

MongoDB是否满足读你所写一致性?MongoDB是满足的，因为它是连接信息跟线程绑定的，意思是说，读写线程跟MongoDB的连接信息是绑定的，读写线程获取连接优先连接到之前连接到的服务器。

会话一致性

在一个会话过程中，Zookeeper满足读你所写一致性。因为Zookeeper不同于MongoDB或者其它分布式系统，是读写数据结束立即释放连接。而Zookeeper是长连接的(用于监听Zookeeper的事件)。

Zookeeper提供了会话的自动重连机制，当客户端连接的Zookeeper服务器出现故障而不可达时，客户端会自动尝试重连到另外一台机器，客户端选择的那台服务器的数据状态不比之前连接的那台机器旧，因此会话重连也会保证会话一致性。

单调读一致性

严格来说，Zookeeper不满足单调读一致性。因为在一个进程中，如下的操作序列是Zookeeper不能保证的，会话建立->写数据->读数据->会话关闭->会话建立->读数据，最后的读数据不一定是之前写到的数据

单调写一致性

Zookeeper满足。只要Zookeeper写成功了一个操作，那么后面的写肯定是在Zookeeper提交了前一个写之前，而不管是否在同一个会话中，因为Zookeeper的写操作是全局顺序性。

读后写一致性

Zookeeper满足读后写一致性。当Zookeeper读到一个数据后，那么Zookeeper在写数据时，一致性在读到的之后的值进行更新。

上一篇：技术文章备忘

下一篇：【分布式数据一致性三】MongoDB读写一致性

请勿发布不友善或者负能量的内容。与人为善，比聪明更重要！

<div > 很多文档说Zookeeper是强一致性保证，事实不然。关于一致性模型请参考http://bit1129.iteye.com/blog/2155336 &nbsp; <h1>&nbsp;Zookeeper的数据同步协议</h1> Zookeeper采用称为Quorum Based Protocol的数据同步协议。假如Zookeeper集群有N台Zookeeper服务器(N通常取奇数，3台能够满足数据可靠性同时有很高读写性能，5台在数据可靠性和读写性能方面平衡最好)，那么用户的一个写操作，首先同步到N/2 + 1台服务器上，然后返回给用户，提示用户写成功。基于Quorum Based Protocol的数据同步协议决定了Zookeeper能够支持什么强度的一致性 &nbsp; <h2>强一致性(Strong Consistency)</h2> 在分布式环境下，满足强一致性的数据储存基本不存在，它要求在更新一个节点的数据，需要同步更新所有的节点。这种同步策略出现在主从同步复制的数据库中。但是这种同步策略，对写性能的影响太大而很少见于实践。因为Zookeeper是同步写N/2+1个节点，还有N/2个节点没有同步更新，所以Zookeeper不是强一致性的。 &nbsp; <h2>弱一致性</h2> 用户的数据更新操作，不保证后续的读操作能够读到更新后的值，但是最终会呈现一致性。牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可 &nbsp; CopyOnWriteArrayList是一个读写分离的并发ArrayList，它的遍历是弱一致性的，因为可以容忍并发修改，不会抛出ConcurrentModificationException，不像普通的集合，允许即时失败。 <h2>&nbsp;</h2> <h2>最终一致性</h2> 最终一致性本质上和弱一致性是一回事，因为一个数据存储系统满足弱一致性但是不满足最终一致性，那么这个系统的数据就是不正确，一个数据不正确的系统是一个无法交付使用的系统。Zookeeper满足最终一致性，只要数据同步到Quorum之外的节点就会达到最终一致性。 &nbsp; <h2>因果一致性</h2> Zookeeper是否满足因果一致性，需要看客户端的编程方式。 <ul> <li>不满足因果一致性的做法</li> </ul> 1. A进程向Zookeeper的/z写入一个数据，成功返回 2. A进程通知B进程，A已经修改了/z的数据 3. B读取Zookeeper的/z的数据 4. 由于B连接的Zookeeper的服务器有可能还没有得到A写入数据的更新，那么B将读不到A写入的数据 &nbsp; <ul> <li>满足因果一致性的做法</li> </ul> 1. B进程监听Zookeeper上/z的数据变化 2. A进程向Zookeeper的/z写入一个数据，成功返回前，Zookeeper需要调用注册在/z上的监听器，Leader将数据变化的通知告诉B 3. B进程的事件响应方法得到响应后，去取变化的数据，那么B一定能够得到变化的值 4. 这里的因果一致性提现在Leader和B之间的因果一致性，也就是是Leader通知了数据有变化 &nbsp; 第二种事件监听机制也是对Zookeeper进行正确编程应该使用的方法，所以，Zookeeper应该是满足因果一致性的 &nbsp; &nbsp; <h2>读你所写(写后读)一致性</h2> 严格来说，Zookeeper不满足读你所写一致性。因为在一个进程中，如下的操作序列是Zookeeper不能保证的， 会话建立-&gt;写数据-&gt;会话关闭-&gt;会话建立-&gt;读数据，最后的读数据不一定读到之前写的数据。 &nbsp; MongoDB是否满足读你所写一致性?MongoDB是满足的，因为它是连接信息跟线程绑定的，意思是说，读写线程跟MongoDB的连接信息是绑定的，读写线程获取连接优先连接到之前连接到的服务器。 &nbsp; <h2>会话一致性</h2> 在一个会话过程中，Zookeeper满足读你所写一致性。因为Zookeeper不同于MongoDB或者其它分布式系统，是读写数据结束立即释放连接。而Zookeeper是长连接的(用于监听Zookeeper的事件)。 Zookeeper提供了会话的自动重连机制，当客户端连接的Zookeeper服务器出现故障而不可达时，客户端会自动尝试重连到另外一台机器，客户端选择的那台服务器的数据状态不比之前连接的那台机器旧，因此会话重连也会保证会话一致性。 &nbsp; &nbsp; <h2>单调读一致性</h2> 严格来说，Zookeeper不满足单调读一致性。因为在一个进程中，如下的操作序列是Zookeeper不能保证的， 会话建立-&gt;写数据-&gt;读数据-&gt;会话关闭-&gt;会话建立-&gt;读数据，最后的读数据不一定是之前写到的数据 &nbsp; <h2>单调写一致性</h2> Zookeeper满足。只要Zookeeper写成功了一个操作，那么后面的写肯定是在Zookeeper提交了前一个写之前，而不管是否在同一个会话中，因为Zookeeper的写操作是全局顺序性。 &nbsp; <h2>读后写一致性</h2> Zookeeper满足读后写一致性。当Zookeeper读到一个数据后，那么Zookeeper在写数据时，一致性在读到的之后的值进行更新。 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <h2>&nbsp;</h2> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </div>

留言需要登陆哦

技术博客集 - 网站简介：
前后端技术：
后端基于Hyperf2.1框架开发,前端使用Bootstrap可视化布局系统生成
网站主要作用：
1.编程技术分享及讨论交流，内置聊天系统;
2.测试交流框架问题，比如：Hyperf、Laravel、TP、beego;
3.本站数据是基于大数据采集等爬虫技术为基础助力分享知识，如有侵权请发邮件到站长邮箱，站长会尽快处理;
4.站长邮箱：[email protected];

文章归档

文章标签

友情链接

首页
关于我们

Auther ·HouTiZong: 侯体宗的博客