这篇文章给大家分享的是有关CAP定理的示例分析的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
1.记忆公司
一个天才创意在你头脑中产生：既然人们的记忆通常不好，而我偏偏擅长记忆，那我为什么不利用记忆天赋开创一番事业。
立马行动， 你制作了【记忆公司】的开业广告:
Remembrance Inc! - Never forget, even without remembering!
Ever felt bad that you forget so much? Don’t worry. Help is just a phone away!
When you need to remember something, just call 555—55-REMEM and tell us what you need to remember. For eg., call us and let us know of your boss’s phone number, and forget to remember it. when you need to know it back.. call back the same number[(555)—55-REMEM ] and we’ll tell you what’s your boss’s phone number.
Charges : only $0.1 per request
记忆公司的日常业务通话记录：
客户：喂，你好，你可以存储我邻居的生日吗?
你：可以，您说。
客户：1月2号
你：记录(在笔记本这个客户页上记下信息), 好的，欢迎下次垂询。
客户：谢谢
你：请支付1元
2.业务扩张
凭借创意和人品，【记忆公司】的规模越做越大，而成本只需要笔记本和电话。
当你某天生病不能工作时，你会损失一天的收入;更不用说当天想要信息的客户会因此发狂。
你有了新计划：
1. 你和你老婆分别使用分机
2. (555)—55-REMEM 客服电话不变
3. 客服电话会转到空闲的分机号
3.第一次业务宕机
有一天你收到老客户罗志祥的电话，要求查询"明天的约会安排";
你一脸蒙蔽，我不知道啊，你的记忆页上没这个信息啊; 客户咣当挂断了电话。
当天复盘， 猜想是昨天罗志祥把业务电话打到我老婆那里了，事实确实如此。
你们都意识到分机号带来的新问题。
多么可怕的分布式设计中的缺陷!你的分布式系统是不一致的!总会有一个时机，客户会将业务电话打到你们其中一个;在下一次拨号时，客户就可能收到不一致的信息。
4.修复一致性问题
睡前吹风时间， 你想到一个主意：
当我们其中一个人接到客户新的记忆业务，我们会在挂电话之前告诉另一个人
这样我们都能在笔记本上记下新业务
当客户查询时，我们两个都可以轻松应对
这里有一个问题：当其中一人收到新业务电话，两人就不能并行工作了。
例如：当你收到新业务并告诉我记录信息时， 我不能接其他电话。
但是这个问题也不大，因为大部分都是查询业务(可以再拨电话重试)，我们首要的是确保信息正确。
你老婆进一步提出：如果某天你不在岗，我收到新业务，你的笔记本不能得到最新信息，这就会有可用性问题， 因为我没能通知你，我就不能挂断电话完成这单业务。
5. 更优方案
你慢慢理解了分布式系统中的“一致性”和“可用性”。你提出了更优方案：
1. 收到新业务电话， 挂电话前通知对方，这样两个人都能记下信息
2. 某天其中一人不在岗，另外一人收到新业务电话 ，给缺岗者发一封邮件
3. 第二天缺岗者上岗查收邮件，更新自己的笔记本。
Nice， 现在一致性和可用性都满足了。
6. 老婆难养
使用优化方案，一切都很顺利，你们的笔记本是一致的，当你们其中一人不在岗系统也能很好的运作。
但是， 凡事都有但是， 某天你们都在岗，但是你老婆嫌你碗没洗干净，今儿不想理你，收到新业务不通知你了，你的查询业务就有问题了。
你的方案包含了“一致性”，“可用性”， 但是不满足“分区容错”。
为了满足“分区容错”， 你可以自我下线(直到你们修复关系)，让你老婆一人接手业务，但是你的系统就不可用了。
7.结论
我们回过头看CAP定理：在设计分布式系统时，“一致性Consistency ”“可用性Availability”“分区容错Partition Tolerance” 你只能满足两个。
?Consistency：一旦接受了客户的新业务，在客户后续查询时必须得到最新的信息
?Availability：只要你们一人在岗，记忆公司就一直提供服务
?Partition Tolerance：你们夫妻二人闹矛盾了，记忆公司依旧运作
有了这样的场景，理解CP、AP、CA就不难了
雇佣工具人-->最终一致性
雇佣工具人，更新[未更新的人]的笔记本，相比你老婆实时通知你更新， 这个工具人有个好处是在后台跑腿，你们两个业务都不会阻塞。
这也是很多NoSql的工作方式：一个节点在本地更新，后台进程同步到其他节点， 唯一存在的问题是少数时候丢失一致性。
你老婆收到新业务，工具人还没来得及跑腿，客户就立即回拨并转到你的分机，你给出不一致的答复。这种情况有限，因为客户不会如此迅速忘记事情。
这就是CAP定理和最终一致性的现实解释。
感谢各位的阅读！关于“CAP定理的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
