阅读 784

分布式-CAP理论和实现

前言

看了很多文件,都只讲理论。到了实现这一块,比如zookeeper、redis是怎么实现CAP理论的,就开始模棱两可。这些文章的目的就是做一些整理和记录。

CAP

深入理解 有A、B、C三个分布式数据库。

当A、B、C的数据是完全相同,那么就符合定理中的Consistency(一致性)。

假如A的数据与B的数据不相同,但是整体的服务(包含A、B、C的整体)没有宕机,依然可以对外系统服务,那么就符合定理中的Availability(可用性)。

分布式数据库是没有办法百分百时刻保持各个节点数据一致的。假设一个用户再A库上更新了一条记录,在更新完这一刻,A与B、C库的数据是不一致的。这种情况在分布式数据库上是必然存在的。这就是Partition tolerance(分区容错性)

当数据不一致的时候,必定是满足分区容错性,如果不满足,那么这个就不是一个可靠的分布式系统。

然而在数据不一致的情况下,系统要么选择优先保持数据一致性,这样的话。系统首先要做的是数据的同步操作,此时需要暂停系统的响应。这就是满足CP。

若系统优先选择可用性,那么在数据不一致的情况下,会在第一时间放弃一致性,让整体系统依然能运转工作。这就是AP。

所以,分布式系统在通常情况下,要不就满足CP,要不就满足AP。

那么有没有满足CA的呢?有,当分布式节点为1的时候,不存在P,自然就会满足CA了。 zackku.com/cap/


CA

传统数据库oracle //一般没有集群

AP

大型网站架构,服务集群。//可用性必须达到几个9,但是数据只要最终一致就ok。

CP

分布式数据库、缓存redis、注册中心zookeeper,只要是分布式存储数据的软件,都必须首先满足数据强一致性。

其次分布式,肯定满足集群。

可用性可以暂时失去。

zookeeper

1.zookeeper本身是集群,作用和目的就是为了高可用——即leader挂了,自动选举新的leader。//集群

2.但是leader节点只有一个,并且对外提供服务的也只有这一个Leader节点,所以很明显不是高可用,因为leader挂了之后,选举有时间差几十秒,这段时间差之内就是不可用! //单个leader,所以是数据一致性

3.所以,zookeeper不是高可用,而是数据一致性和集群,即CP。

总结
zookeeper是中心化leader。


CP without A 如果一个分布式系统不要求强的可用性,即容许系统停机或者长时间无响应的话,就可以在CAP三者中保障CP而舍弃A。

一个保证了CP而一个舍弃了A的分布式系统,一旦发生网络故障或者消息丢失等情况,就要牺牲用户的体验,等待所有数据全部一致了之后再让用户访问系统。

设计成CP的系统其实也不少,其中最典型的就是很多分布式数据库,他们都是设计成CP的。在发生极端情况时,优先保证数据的强一致性,代价就是舍弃系统的可用性。如Redis、HBase等,还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。

无论是像Redis、HBase这种分布式存储系统,还是像Zookeeper这种分布式协调组件。数据的一致性是他们最最基本的要求。一个连数据一致性都保证不了的分布式存储要他有何用?

在我的Zookeeper介绍(二)——Zookeeper概述一文中其实介绍过zk关于CAP的思考,这里再简单回顾一下:

ZooKeeper是个CP(一致性+分区容错性)的,即任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性。但是它不能保证每次服务请求的可用性,也就是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果。ZooKeeper是分布式协调服务,它的职责是保证数据在其管辖下的所有服务之间保持同步、一致。所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了。 www.hollischuang.com/archives/66…


四、用CAP理论来分析ZooKeeper CAP理论告诉我们,一个分布式系统不可能同时满足以下三种

一致性(C:Consistency) 可用性(A:Available) 分区容错性(P:Partition Tolerance) 这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中。

在此ZooKeeper保证的是CP

分析:可用性(A:Available)

不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。所以说,ZooKeeper不能保证服务可用性。

进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说,ZooKeeper不能保证服务可用性。

参考:www.cnblogs.com/xrq730/p/49…
参考:blog.csdn.net/xiangxizhis…

segmentfault.com/a/119000001…


最佳实践
1.适合当协调 //两阶段提交是协调
2.不适合服务发现 //dubbo是服务发现 //阿里自己都没有使用zookeeper。netflix自己实现了注册中心,非中心化。目前,zookeeper是CP,但是注册中心更应该实现AP——因为注册中心数据不一致,顶多只是负载均衡一时的不均匀,但是最终一致性马上又会恢复服务器节点的负载均衡。但是,中心化不能做到高可用,大型互联网公司的任何一块的服务都必须做到高可用,不能有任何故障。所以注册中心更应该要实现AP。

redis

和zookeeper一样,也是CP。


和zookeeper的区别
1.redis哨兵机制,哨兵节点是非中心化。
2.而且,像这种提供分布式数据存储的中间件,都是必须数据一致性,所也是CP。


my.oschina.net/wugong/blog…
stackoverflow.com/questions/6…

Gossip-去中心化协议

一部分节点的状态/数据传递给另外一部分节点,然后再传给/通信给再另外的一部分节点,直到所有节点数据一致。

高可用

三种架构模式 1.主备 //比如,数据库mysql,缓存redis 2.多主/备 //跨/多机房 3.集群 //同一个服务部署多个,每个服务只存储一部分数据——但是每个节点都有主备,比如redis。

主备 //复制数据一般都是基于binary log

多主/备 //跨机房

集群 //注册中心,阿里没有使用中心化zookeeper而是自己实现去中心化注册中心

参考

jm.taobao.org/2018/06/13/… //阿里的文章写得非常好,有深度,且深度实践过的。所以讲起理论起来,也是非常的清楚,没有模棱两可的地方。

dockone.io/article/78

文章分类
阅读
文章标签