在设计分布式系统时会经常听到CAP理论，这个理论为分布式系统的设计提供了上限。
和我的大多数入门教程一样，让我们通过将CAP理论与真实世界进行比较来更好的理解它。
chapter 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
所以，客户和你的交谈内容就会像下面这样
- 顾客：你可以记住我邻居的生日吗？
- 你：当然了，你邻居生日什么时候？
- 顾客：2月1日
- 你：（记住这个生日并且存在笔记本上）。请随时致电我，以便您再次了解您邻居的生日。
- 顾客：谢谢
- 你：不客气。我们收你0.1美元
Chapter 2：业务规模扩大
你的这个创业想法是如此简单，只需要一个笔记本和一个电话，但是它非常有效，所以你的公司业务规模飞速扩大。你每天都会接到几百个电话
这个时候问题出现了，越来越多的客户需要排队才能和你通话。因此你的客户也开始流失。除此之外，当你生病的时候无法工作的时候，你会失去一整天的生意，而在那天想要获取自己之前存储信息的客户也会相当不满意。
这时候你决定让你的妻子来帮你的忙。
你开始了这样一个计划
- 你和你的妻子都会得到一个电话
- 客户只需要记得一个电话号码
- 一个路由器，将客户的电话路由给空闲的人
Chapter 3： 很糟糕的服务
在您实施新系统两天后，你收到了客户Jhon的电话。
- Jhon：你好
- 你：欢迎致电“记忆公司”，我有什么可以帮助你吗？
- Jhon：你能告诉我去新德里的航班信息吗？
- 你：当然可以，请您稍等。(你查看你的笔记本，并没有找到Jhon之前存的航班信息)
- 你：先生，我想这里有一个错误。您之前并没有告诉我您去新德里的航班信息。
- Jhon：什么？我昨天刚打电话告诉你我的航班的（挂断电话）
这种情况怎么出现的？Jhon撒谎了吗？你想了一会就明白了问题所在。可能是昨天Jhon的电话打到了你的妻子那。你到你妻子的桌子查找她的笔记本。当然，你找到Jhon的航班信息。你把这个事情告诉了你的妻子，她也意识道问题的严重性。
你的分布式设计有着可怕的缺陷。你的分布式系统设计的并没有实现一致性(consistent)。总有客户会打电话更新自己的信息，并且被你或者你的妻子处理。但是当客户打电话询问自己信息的时候，另一个人可能并没有这个客户的信息。
Chapter 4：修复一致性问题
晚上在你老婆睡觉的时候，你想了一个晚上。在早上你成功的找到了解决的办法，并和你的妻子分享
- 当我们中的任何一个人接收到用户的电话时（用户希望我们记住某些事情），在电话结束之前，我们要通知对方
- 这样我们都可以记录任何客户的信息
- 当用户想再次获取信息时，我们不需要在向另外一个人询问。因为我们保存最新的用户信息。
但是还有一个问题，当“更新”请求必须涉及到我们两个，那么我们就不能同时工作。例如，当你收到一个更新请求并且要求我一起更新，这是我不能处理另一个客户的请求。但这没关系，因为大多时候我们收到的电话都是查询信息（读多写少）。除此之外，我们任何情况下都不能给出错误的信息。
妻子说，但是系统还有一个你没有想到的缺陷。如果我们一个人一整天都不能工作怎么办？如果这样，这一天我们不能做任何更新操作，因为不能工作的那个人也不能执行更新操作。这是一个可用性问题，例如一个更新请求到我这，但是我不能完成这个请求，因为即使我在我的笔记本中记录了这条更新，我也没有通知你做同样的更新，所以我没法完成这样的请求
Chapter 5：你提出了最好的解决方案
你应该了解了为什么分布式系统不想你开始想的那么容易。想出一个满足一致性和可用性的方案很难吗？然而第二天早上，你想出一个竞争对手不可能想到的方案。你很着急的和自己的妻子分享。
- 当任何人收到更新信息的电话时，在完成电话之前，如果另一个人是空闲的，那我们就告诉另一个人这个请求。这样我们两个都会得到更新
- 但是如果另一个人不是空闲的。我们向他发送一个email告知他客户发生了更新操作。
- 当另一个人回来工作时，要做的第一件事情就是查看email中的更新操作。
Chapter 6：你的妻子很生气
开始的一段时间一切都很顺利。你的系统维持了一致性和可用性。在有一个人不能工作时你的系统也能正常运行。但是当你们两个人都向对方报告客户的更新操作，而其中一个没有完成另一个人的更新时要怎么办呢？如果有一天你惹你的妻子生气，你的妻子没有向你报告她做的更新怎么办呢？你完全没有注意了。你的想法已经足够解决一致性和可用性，但是没有考虑到分区容错性(Partition Tolerant)。
你可以在你和妻子和好之前不接受任何电话，这样就保证了分区容错，但是你的系统在那段时间是不可用的。
Chapter 7：总结
现在看一下CAP理论。它表明在你设计分布式系统时无法同时满足一致性Consistency、可用性Availability和分区容错行Partition Tolerance
- Consistency：你的客户在更新信息后，你的系统要保证客户随时都可以查到更新的信息。
- Availability：记忆公司一直可以接收客户请求，除非你和你的妻子同时在向对方报告更新信息。
- Partition Tolerance：记忆公司在你和妻子之间的报告丢失的情况下仍然可以工作。
Bonus : Eventual Consistency with a run around clerk :
你可以雇一个文员，由他负责来更新你的或者你妻子的笔记本。这样做的最大好处是，他可以在后台工作，这样你或者你的妻子在更新中不需要停下来等另一个人更新完毕。这就是NoSql的工作方式，一个节点更新自己的数据，有一个后代进程将数据同步到起它节点。这样做会使我们丢掉一部分一致性。例如当顾客像你妻子更新了它的信息，但是文员还没有来得及更新的笔记本，客户查询的请求被发送到你这里，这时你不能给出最新的信息。
网友评论