墙裂推荐：这可能是CAP理论的最好现实解释

这篇文章蓝本：http://ksat.me/a-plain-english-introduction-to-cap-theorem
经过小码甲意译、原创配图, 干到让你怀孕。

---

你可能经常听到CAP定理， 这个定理描述了在设计分布式系统时的天然约束。 就像其他文章一样， 本文以现实场景对比理解CAP定理。

1.记忆公司： 单机提供服务

既然大多数人的记忆通常不好，而我擅长记忆，那我就办一家记忆公司（人肉生活助理）。

记忆公司的日常业务通话记录：

• 客户：喂，你好，你可以存储我邻居的生日吗?
• 你： 可以，您说。
• 客户：1月2号
• 你：记录(在笔记本这个客户页上记下信息), 好的，欢迎下次垂询。
• 客户：谢谢
• 你： 请支持1元

2.业务扩张： 分布式服务

创意加人品让公司越做越大，而成本只有笔记本和电话。

你想要扩张业务，同时你也需要一个兜底。

你有了新计划：

1. 你和你老婆分别使用分机
2. (555)—55-REMEM 客服电话不变
3. 客服电话会转到空闲的分机号
   

3.第一次业务出错： 分布式的数据同步问题

某天你收到老客户罗**的电话，要求查询"明天的约会安排"；
你一脸蒙蔽，我不知道啊，你的记忆页上没这个信息啊;
客户咣当挂断了电话。

当天复盘， 猜想是罗志祥昨天把业务电话打到我老婆那里了，事实确实如此。

你们都意识到分机号带来的新问题。

多么可怕的分布式设计中的缺陷！分布式系统是不一致！ 总是会有一个时机，客户会将业务电话打到你们其中一个；在下一次拨号时，客户就可能收到不一致的信息。

4.收到数据即时发送： 同步复制

睡前吹风时间， 你想到一个主意：

• 当我们其中一个人接到客户新的记忆业务，我们会在挂电话之前告诉另一个人
• 这样我们都能在笔记本上记下新业务
• 当客户查询时，我们两个都可以轻松应对

同步复制带来2个新问题：
（1）当其中一人收到新业务电话，两人就不能并行工作了。
例如：当你收到新业务并告诉我记录信息时， 我不能接其他电话。

但是这个问题也不大，因为大部分都是查询业务(可以再拨电话重试)，我们首要的是确保信息正确。

（2）我收到新业务，而你不在岗，我就不能挂断电话完成这单业务, 这就带来可用性问题。**

5. 异步复制

你慢慢理解了分布式系统中的“一致性”和“可用性”。

1. 收到新业务电话， 挂电话前通知对方，这样两个人都能记下信息
2. 某天其中一人不在岗，另外一人收到新业务 ，给欠岗者发一封邮件
3. 第二天缺岗者上岗查收邮件，更新自己的笔记本。

Nice， 现在一致性和可用性都满足了。

6. 老婆难养 ： 发生网络分区

但是， 凡是都有但是， 某天你们都在岗，但是你老婆嫌你碗没洗干净，今儿不想理你，收到新业务不通知你了（你们之间的联系断开了**）*。

你的方案包含了“一致性”，“可用性”， 但是不满足“分区容错”。

为了满足“分区容错”，你可以自我下线(直到你们修复关系)，让你老婆一人接手业务，但是你的系统就不可用了。

7.结论

我们回过头看CAP定理： 在设计分布式系统时，“一致性Consistency
”“可用性Availability”“分区容错Partition Tolerance” 你只能满足两个。

• Consistency：一旦接受了客户的新业务，在客户后续查询时必须得到最新的信息
• Availability：只要你们一人在岗，记忆公司就一直提供服务 （内部节点下线的角度）
• Partition Tolerance：你们夫妻二人闹矛盾了，记忆公司依旧服务 （节点连通性角度）

雇佣工具人-->最终一致性

雇佣工具人，更新[未更新的人]的笔记本，相比你老婆实时通知你更新， 这个工具人有个好处是在后台跑腿，你们两个业务都不会阻塞。

这也是很多NoSql的工作方式：一个节点在本地更新，后台进程同步到其他节点， 唯一存在的问题是少数时候丢失一致性。

你老婆收到新业务，工具人还没来得及跑腿，客户就理解回拨并转到你的分机，你给出不一致的答复。这种情况有限，因为客户不会如此迅速忘记事情。

这就是CAP定理和最终一致性的 现实解释。****