什么是分区容忍性(Partition Tolerance)？
P → Partition tolerance 分区容忍(网络分区容忍)
分区就是：这些机器之间的网络突然出问题了，导致一部分机器跟另一部分机器"失联"了。但这是不可避免的，因为现实世界的网络不可能100%可靠。
"分区容忍"，系统被劈成孤岛了，它还得继续工作，不能直接整体崩溃。
P的本质要求是：系统要能"容忍"这种网络分裂的局面，继续提供服务(哪怕服务质量下降)。
如果系统没有分区容忍，一个服务失联，其他服务器就停止运行，等待信号恢复，防止数据出现不一致，但这样做太极端了。
所以 P 几乎总是要满足存在的，只能与 C 和 A 进行再搭配
如何正确理解CP和AP？
CP(强一致性)：宁可让部分用户暂时用不了，也绝不让任何人看到错误的数据 → "数据正确 > 一切"
AP + 最终一致性：宁可让用户暂时看到不那么准的数据，也要保证几乎所有用户随时都能用 → "能用 > 数据立刻完美"(但最终一定会完美)
| 场景 | CP 系统(强一致性)做法 | AP 系统(最终一致性)做法 | 用户实际体验对比 | 典型代价与适用场景 |
|---|---|---|---|---|
| 网络正常时 | 三个人都能立刻看到最新余额，随时花钱 | 三个人也能立刻看到最新余额，随时花钱 | 几乎没区别 | --- |
| 小明断网后，你想花100元 | 系统要求：必须等小明也收到消息、确认后才能让你记账 → 你可能等几秒到几分钟，甚至超时失败 | 系统直接让你记账成功，立刻返回"已扣100元" 小明那边暂时看不到 | CP：你可能卡住/失败("系统繁忙，请稍后") AP：你马上成功，但小明那边看到的是旧余额 | CP 牺牲了"立刻能用" AP 牺牲了"立刻正确" |
| 小明恢复网络后 | 所有人都看到正确余额：你-100，小红-200，小明-300 | 系统后台慢慢同步(可能几秒到几分钟) 最终三个人余额都对 | CP：全程数据永远正确 AP：小明恢复前看到的是"旧世界"，恢复后突然"跳"到正确 | CP：安全但有时卡 AP：丝滑但可能短暂错觉 |
| 最怕什么情况 | 怕"数据错一次就翻车"(比如银行多转钱) | 怕"用户一直用不了系统"(比如电商没人能下单) | --- | --- |
CP："数据永远正确，哪怕暂时用不了 " → 像银行柜员，宁可窗口关一会儿，也不会给你错的余额。
AP："系统永远能用，哪怕数据暂时有点小偏差" → 像朋友圈，大家网络不好也能继续发朋友圈，点赞晚点显示也没事，最终都会对齐。
● CP 适合：钱、票、权限、配置 这些"错了就灾难"的数据 → 优先"正确"，接受偶尔"卡住"。
● AP + 最终一致性 适合：99% 的互联网业务(浏览、点赞、推荐、购物车显示) → 优先"能用"，接受短暂"不太准但最终会准"。
大多数现代互联网公司(尤其是用户量大的)都偏向 AP + 最终一致性，因为"用户用不了"比"用户看到的数据晚更新几秒"更致命。
为什么一致性(C)和可用性(A)很难同时存在？
当网络分区(P)真的发生时，系统被"劈"成了几个互相联系不上的孤岛，这时你想让所有孤岛都"立刻返回最新正确数据"(C) + "每个请求都必须立刻有响应"(A)，在物理上几乎做不到。
网络分区发生时(P不可避免)，要让所有节点都看到相同最新数据(C)，就必须等待通信恢复或拒绝部分操作 → 这会让系统暂时"不好用"(牺牲A)。反过来，要让每个请求都立刻响应(A)，就必须允许孤岛各自干活 → 数据就可能暂时不一样(牺牲C)。
物理限制摆在那里：信息没法在断网的情况下瞬间传到所有地方，所以 C 和 A 就是天生矛盾的。