CAP定理及应用

  • 更新时间: 2018-02-02
  • 来源: 原创或网络
  • 浏览数: 38次
  • 字数: 8779
  • 发表评论

1 CAP理论介绍

2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后,麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后,CAP理论正式成为分布式计算领域的公认定理。

CAP理论

一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。

2 CAP理论解释

C:Consistency一致性

一致性指“all nodes see the same data at the same time”,即更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致。

A: Availability可用性

可用性指“Reads and writes always succeed”,即服务一直可用,而且是正常响应时间。

P: Partition tolerance分区容错性

分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”,即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。

单机RDBMS是CA系统

单机的OracleMySQL之类的传统RDBMS数据库没有分区容错,是CA系统,可以达到强一致性和可用性。

CAP在MySQL主从复制中的应用

MySQL主从复制实现了分区容错性(P),主从复制分为异步复制和半同步复制。

异步复制

异步复制在master写binlog成功之后立即提交,不等待slave的同步结果。这种方式有很高的性能,但是牺牲了数据一致性。如果slave同步不成功就会造成master和slave数据不一致。异步复制虽然性能高(A),但是数据有可能不一致(C),所以异步复制是AP系统。

半同步复制

半同步复制在master写binlog成功之后不立即提交,而是等待其中一个slave同步成功,只要有一个slave同步成功,立即提交。这种方式比异步复制性能稍差(需要等待至少一个slave同步成功才提交),但是在一定程度上保证了数据一致性(依然不是CP系统:如果同步slave2失败,master和slave1在commit之后挂了,slave2对外提供服务,从slave2中无法查询到刚才提交的数据)。

MySQL两种主从复制实现来看,在保证分区容错(P)的情况下,必须在性能(A)和数据一致性上(C)做出取舍。

CAP在MySQL组复制中的应用

组复制操作时序图: 组复制使用paxos协议广播执行状态,由于paxos协议的限制,必须多数master达成一致,写入操作才算成功,可以实现在多个master之间保持数据一致。如果在两个或多个master上并发更新同一条数据,在certify阶段进行操作校验,只有第一个更新操作能成功,其他更新操作返回失败。 此系统在一致性方面(C)做了妥协(强一致->弱一致,有短暂数据不一致窗口),在性能方面(A)也做了妥协(比单机多了消息广播和certify阶段,性能略低),从而达到分区容错(P)。

zookeeper集群

zookeeper集群在对外提供服务和写入数据时,必须半数以上主机可用并且数据写入成功,才返回成功。虽然有短暂的数据不一致窗口,但是因为有超过半数成功的限制条件,即使leader挂掉,选举出来的新leader也肯定会有所有完整的数据(有最新数据日志的节点才有可能被选为leader),所以最终数据会在集群中的所有机器上保持一致(单调弱一致性:两次读取操作,后发起的不会读取到比前一次读取到的数据更老的数据)。因此zookeeper集群是CP系统。

zookeeper集群设计为CP系统的原因:zookeeper作为分布式协调系统,可以在性能上做出妥协,但是必须要求数据是一致的,否则无法作为协调工具存在。

redis集群

redis集群在写入数据时,master写入成功即返回成功,数据异步复制到slave上。如果在master写入成功,但是在同步数据到slave时master挂掉,slave被选为新的master,此时刚才写入成功但没有同步到slave的数据会丢失。所以redis集群是AP系统。 redis集群设计为AP系统的原因:redis作为内存数据库,目的是为了提高数据存取的性能,缓存是其最常见的使用场景,性能高是redis的最大特点,所以只能在数据一致性上做出妥协。

分布式锁的选择

zookeeperredis都可以实现分布式锁MySQL和其他RDBMS也可以,但是性能较低),也都有现成的第三方库。选择zookeeper还是redis实现分布式锁,一般参照以下标准:

对安全性要求高,不允许出现锁失效的场景,比如和用户金钱道具相关的操作,选择zookeeper实现分布式锁

对安全性要求不高,可以允许偶尔出现锁失效的场景,比如分布式系统执行定时任务做一些类似于归档数据的操作,如果多个实例并发执行会影响性能,但是不会造成其他负面影响。

我来评分 :6
0

转载注明:转自5lulu技术库

本站遵循:署名-非商业性使用-禁止演绎 3.0 共享协议