分布式系统的cap定理-分布式系统容量极限

咱们先别急着背公式，也没必要把系统拆成三块儿去理解。想象一下你在微信群里发消息，半小时后你突然问：“刚刚那个哪位？”群里立马炸锅，所有人都在回，但没人能看到你发的内容。
这时候，有人能听到，有人能看到，但数据丢了。
这就是最早期的分布式，充满了重复、丢失和延迟，就像那个微信群。
那时候，你点个号，大家都得重发一遍消息，要么大局部人都没收到。
这就是 CAP 里那个核心的矛盾：要么全看到了（一致性），要么全收到了（可用性），中间留着一致性，那系统就得挂；中间留着可用性，那数据就可能丢。 大量人总当作 CAP 是个铁律，绝对不能选。但实际上没那么绝对，要不就你为了追求一致性，愿意把数据停摆。
比如银行转账，要是你为了不出错，务必等所有账户都确认了才扣款，那你的服务可能下个小时才能上线。
这时候，牺牲一致性去换可用性，反而显得不那么有损。 那到底该如何选？实际上就是一个关于“代价”的游戏。一致性是代价，意味着数据可能暂时看不到，但错了就不错了；可用性是代价，意味着客户能随时访问，但数据可能乱了。你是在怕费事，还是怕业务停摆？这彻底取决于你的业务场景。
举个例子，做电商秒杀，你要是为了数据绝对准，用户下单后一分钟都打不全，订单全断了，那客户就得换成隔壁家，这对生意打击忒大。
这时候，你就得选可用性，让数据可能不一致，但服务不停。再比如金融核心交易，你不中啊，一笔账要是错了，客户损失几十万，那务必保证数据绝对一致，哪怕业务间或卡顿。
这就是典型的“为了对性，能够牺牲可用性”。 还有一个角度，就是数据的持久性。有些系统，比如写日志要么备份，你无所谓它们对不对，反正下次恢复能修好就行。
这时候，为了不让数据长工夫丢失，你能够随时切换模式，保证随时可用，哪怕数据间或不一致，也不影响大局。
这就好比仓库，货物丢了有点损失，但只要能找回，订单照常排。 那啥时候该选一致性呢？自然是对数据质量要求极高的场景。
比如医疗诊断系统，你宁愿让医生看都不准，也不愿让患者拿到毛病的建议，哪怕这意味着整个医院系统可能要下线维护。
要么像金融系统的核心账务，绝对不能出现分秒必争的延迟，否则就是犯罪。
这时候，哪怕性能慢一点，数据稳一点，也是首选。 实际上，大量大厂目前都在搞“最终一致”的变通。
比如金融数据库，可能准数据在短暂不一致，但保证在几毫秒内最终达成一致，与此同时保证业务请求都能成功回。
这就相当于银行柜台，你先交钱给你，你说你要理财，系统立即告诉你“已到账”，你立马转头就去理财师那边查了，结局发现理财师那边还没出结局。你心里可能会嘀咕：“数据仿佛没了？”但系统保证的是：只要你交钱，就不会让你错过任何一笔交易，哪怕中间数据还没同步。
这种“交易已提交，数据待更新”的模式，在金融行业挺常见，它用代码层面的最终一致性，换来了业务层面的高可用性。 再看互联网上的秒杀活动，你从点击到下单，中间可能经过二十个环节，每个环节都有人处理、有人缓存、有人写库。
要是为了等数据库彻底落盘，整个响应工夫得等到下午两点，那肯定不中。
这时候，系统会故意把数据留在内存里，要么只写一局部，直到最终时刻再同步到数据库，这样既保证了用户能立马看到结局（可用性），又尽量避免数据冲突（牺牲一致性）。别看最终状态看，数据库里多了一条数据，但用户体验上，订单已经成功了。 故此，CAP 本质上不是哪个系统绝对赢，而是哪个系统在这个特定时刻看起来最像一个赢家。有的业务优先保数据准，那就忍着不一致；有的业务优先保服务不停，那就接纳数据乱点；有的业务既想要准，又想要不停，那就得用技术手段去硬抗那些瞬时的不一致，比如通过消息队列、重试机制、最终一致性协议之类的工具。 最终总结一下，别总想着用一个模型去套所有的系统。分布式世界如此复杂，适合你的那个平衡点，得看你业务痛点在哪。
要么你的业务是金融、医疗这种，数据错了就是大事，那就选 CAP。
要么你的业务是电商、社交这些，客户只要快就行，那就选 AP。
要么你的业务是日志、备份这种，不在乎数据对不对，不在乎会不会乱，那就选 CP。别死磕，看数据，看流程，看业务，找到那个最适合你的平衡点，这才是分布式架构真正的智慧所在。