分布式.CAP理论

理论

CAP分别代表什么

• 一致性Consistency ：all nodes see the same data at the same time 更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致

• 可用性Availability ：Reads and writes always succeed.读和写操作都能成功

• 分区容错性Partition tolerance ：the system continues to operate despite arbitrary message loss or failure of part of the system  再出现网络故障导致分布式节点间不能通信时，系统能否继续服务

备注：一些翻译者私自造词，更难懂，直接看英文翻译更直观。

---

理解

A ：可用性 (功能可用的完整性，读和写操作都能成功)

C ：强一致性 (时效内的一致，相对应的是最终一致性)

P ：分区容错性 (一部分节点没法通信时，整个否能继续服务，只要不是宕机就是可用)

---

举例

举例1

场景：A给B转100操作，需要给A服务-100，B服务+100，只有当服务调用A和B全部成功返回后才算成功。

架构：

分析：这时如果B不能调用，那么这个转账操作不能完成，说明该系统在B节点无法通信时，没法继续提供服务，此时系统不满足P，显然满足C。

---

举例2

场景：企业跨行转账，阿贵在A银行 需要给广联达的对公账户(B银行)转100块钱，阿贵提交申请后，银行不会立马转账，需要经过A审核后将钱转给广联达在B银行的对公账户。

架构：

分析：

1. 阿贵 只需要在中行提交申请即可。

- 这时阿贵的账号-100，广联达并没有收到100。 数据就不一致了。

2. 中行A 会定期处理对公转账，直到广联达财务确认对公账户多出100块钱才算完事

3. 如果A提交转账申请后，B招商服务挂了，此时也可以对外提供服务，稍晚处理转账的事即可。即满足P

---

举例3

场景：中行为了提高系统可用性，如果网络延迟没法处理转账申请，那么至少提供账户余额查询功能。

分析：这样能保障数据一致(压根不让你转账了，能不一致么，满足C)，系统也是可用的(满足P)。可就没法满足A了。

---

技术手段

1. 降级(CP，牺牲了功能完整可用性)：在系统负载高的时候，为了让系统还能提供服务(至少不是500或者404)，就关闭部分功能。很明显的保证P，牺牲A。

2. 读写分离(AP，牺牲了强一致性)：在读99%，写1%的情况下，比如电商、门户等场景，为了应付读写的高并发，会将数据放在缓存内，或者静态化。如果你修改数据，系统一段时间后才刷新缓存，或者更新静态页面，这段时间数据库和缓存数据是不一致的。很明显为了保证P，牺牲了C。

---

选型

对大多数分布式系统，P是必须保证的。原因是：现在用的分布式系统大多是ToC的，系统不可用是很大的事，所以大家都是保证界面可以出来，哪怕部分功能不可用，数据不是实时数据。

实际使用需要分析，到底需要保障那个特性。

---

牺牲P场景

如果产品认为“只能查看信息不能更新信息有时候从产品层面还不如直接拒绝服务”，那么就是准备牺牲P了。这样的系统100%不会出错。同时这样的系统很脆弱。

咱们做一个军事系统，发射一个导弹。要求是：要么发射不了，如果可以发射，必须保证发射系统的数据和导航雷达数据一致，且点火，放开支架，同步数据 都需要准确完成才可以。

1. 你能想象 你选择了美国，导航给你导航到俄罗斯 的结果吗？导弹命中后，雷达才收到发射设定的参数。

2. 在想象下，成功点火了，导弹支架没放开？ 导弹车能给待天上去。

---

放弃理论

现有组件

 

---

END