分布式CAP原则
- C(Consistency)一致性:分布式系统中所有主机在同一时刻是否可以保证数据一致,即写入一台主机后其他主机均写成功则存在一致性;
- A(Availability)可用性:在集群中部分节点发生故障是否会影响到对客户端读写请求的详情,保证集群中部分故障不会影响到整个集群称为可用性;
- P(Partition tolerance)分区容错性:分布式系统中一台主机称为一个分区,分布式系统各个主机可能会存在数据不一致性或可用性问题。该分布式系统对于上述两种问题的兼容性称为分区容错性。
分布式系统中分区容错性是必然的要考虑的,但是一致性和可用性则是两个相互对立的方向。要保证可用性可以通过横向增加主机来实现,但是通过分布式中主机数量的增加各个主机之间数据一致性维护成本会大大提高。所以CAP三原则中分布式系统一般只会满足两项原则后尽可能向第三项原则靠拢。
CAP常见组合
CA
严格意义上来说只保证一致性以及可用性不能被称之为分布式系统。关系型数据库的设计参考该项组合,保证数据强一致性以及系统的可用性
CP
分布式系统中保证数据一致性以及分区容错性,放弃可用性。例如Zookeeper,银行实时转账
Zookeeper分布式原则
Zookeeper在Leader节点宕机后,集群会停止提供服务知道重新选举完成并恢复数据,整个过程大概在30S-120S左右。为了保证一致性在崩溃恢复期间Zookeeper集群停止提供服务不会再有数据交互的产生,其次通过选举快速选举出Leader进入数据恢复阶段,各个Follower会同步Leader(Leader节点中的数据不一定是最新的,这里还有一个选举完后查找最新数据的过程)中最新的数据信息,Zookeeper集群恢复使用,Leader节点进行数据修改再广播到各个子节点进行数据同步保证数据一致性。但是在奔溃恢复阶段则是牺牲了可用性
AP
分布式系统中保证数据的可用性以及分区容错性,放弃一致性。例如Eureka,微信提现到账
Eureka分布式原则
Eureka注册中心专注于服务的注册和发现,相比于Zookeeper不会出现数据的竞争。Eureka在实际使用中会和各个应用进行连接,当有新应用进行注册或者应用宕机的时候注册信息新信息就会被添加或者被删除所以Eureka只保证了数据最终一致性。相比于Zookeeper的选举阶段Eureka保证了服务可用性,至于一致性也可以通过时间来保证最终数据一致性。