ZooKeeper和CAP理论及一致性原则
企业开发
2018-05-09 20:18:54
阅读次数: 2
<iframe id="iframeu2567428_0" style="word-wrap: break-word; margin: 0px; padding: 0px; border-width: 0px; border-style: initial; vertical-align: bottom;" src="http://pos.baidu.com/ucvm?rdid=2567428&dc=2&exps=110005&di=u2567428&dri=0&dis=0&dai=6&ps=704x1261&dcb=BAIDU_SSP_define&dtm=HTML_POST&dvi=0.0&dci=-1&dpt=none&tsr=0&tpr=1480923179190&ti=ZooKeeper%E5%92%8CCAP%E7%90%86%E8%AE%BA%E5%8F%8A%E4%B8%80%E8%87%B4%E6%80%A7%E5%8E%9F%E5%88%99%20-%20zookeeper%20-%20%E8%BF%90%E7%BB%B4%E7%BD%91%20-%20iyunv.com&ari=2&dbv=2&drs=1&pcs=1372x637&pss=1372x976&cfv=22&cpl=6&chi=1&cce=true&cec=UTF-8&tlm=1480923179&rw=637&ltu=http%3A%2F%2Fwww.iyunv.com%2Fthread-109830-1-1.html&ltr=https%3A%2F%2Fwww.baidu.com%2Flink%3Furl%3D1ZCHmGgDDIsmdyzxCqXdQA5d2nJcJFTooifKTqICU7mJrXpM8cwMivBHQpEjTOUooUsBX2ct37d_nIChtXK_dq%26wd%3D%26eqid%3Dd752508c0000ee330000000458451731&ecd=1&psr=1600x900&par=1600x860&pis=-1x-1&ccd=24&cja=true&cmi=8&col=zh-CN&cdo=-1&tcn=1480923179&qn=8ea89d3aec3ac762&tt=1480923179150.254.296.298" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" align="center,center" width="300" height="250"></iframe>
一、CAP理论概述 分布式领域中存在CAP理论,且该理论已被证明:任何分布式系统只可同时满足两点,无法三者兼顾。 ①C:Consistency,一致性,数据一致更新,所有数据变动都是同步的。 ②A:Availability,可用性,系统具有好的响应性能。 ③P:Partition tolerance,分区容错性。 因此,将精力浪费在思考如何设计能满足三者的完美系统上是愚钝的,应该根据应用场景进行适当取舍。 (1)一致性 一致性是指从系统外部读取系统内部的数据时,在一定约束条件下相同,即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同,可以将一致性级别分为如下几种: ①强一致性(strong consistency)。任何时刻,任何用户都能读取到最近一次成功更新的数据。 ②单调一致性(monotonic consistency)。任何时刻,任何用户一旦读到某个数据在某次更新后的值,那么就不会再读到比这个值更旧的值。也就是说,可 获取的数据顺序必是单调递增的。 ③会话一致性(session consistency)。任何用户在某次会话中,一旦读到某个数据在某次更新后的值,那么在本次会话中就不会再读到比这值更旧的值 会话一致性是在单调一致性的基础上进一步放松约束,只保证单个用户单个会话内的单调性,在不同用户或同一用户不同会话间则没有保障。示例case:php的 session概念。 ④ 最终一致性(eventual consistency)。用户只能读到某次更新后的值,但系统保证数据将最终达到完全一致的状态,只是所需时间不能保障。 ⑥弱一致性(weak consistency)。用户无法在确定时间内读到最新更新的值。 二、ZooKeeper提供的一致性服务 很多文章和博客里提到,zookeeper是一种提供强一致性的服务,在分区容错性和可用性上做了一定折中,这和CAP理论是吻合的。但实际上zookeeper提供的只是单调一致性。 原因: 1. 假设有2n+1个server,在同步流程中,leader向follower同步数据,当同步完成的follower数量大于 n+1时同步流程结束,系统可接受client的连接请求。如果client连接的并非同步完成的follower,那么得到的并非最新数据,但可以保证单调性。 2. follower接收写请求后,转发给leader处理;leader完成两阶段提交的机制。向所有server发起提案,当提案获得超过半数(n+1)的server认同后,将对整个集群进行同步,超过半数(n+1)的server同步完成后,该写请求完成。如果client连接的并非同步完成follower,那么得到的并非最新数据,但可以保证单调性。 用分布式系统的CAP原则来分析Zookeeper: (1)C: Zookeeper保证了最终一致性,在十几秒可以Sync到各个节点. (2)A: Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用Sync() (2)P: 有2点需要分析的. ① 节点多了会导致写数据延时非常大,因为需要多个节点同步. ② 节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入 observer节点缓解这个问题.
http://www.iyunv.com/thread-109830-1-1.html |
转载自m635674608.iteye.com/blog/2342877