一、分布式系统的需求与困境
是不是会有人（产品？老板？）对你所负责的分布式系统提出以下三点要求：
- 既要：系统高可用
- 又要：数据一致且实时可见
- 还要：系统具有集群容错能力
这些要求看似简单，当你仔细思考时就会发现很让人头疼了、无法全部实现；如果你还不理解，我们举个例子，如防疫时期的静态化管理：
- 人停工企业停产（失去可用性）
- 全城全面核酸，统一采用核酸码平台，实时统筹管理数据（保证数据的一致性）
- 人被限制在小区内活动、交换物资，小区间封闭（分区容错）
经历过的人应该了解，当我们要满足2、3时，就必须牺牲1；或许你也尝试思考过如何破局但又困惑无解；不过无需自责，不仅仅是你会觉得困难，其他人也一样，因为它违背了CAP定理。
二、CAP 理论引导脱离实现困境
在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），定理讨论了在两个互相矛盾的请求，到达彼此连接不通的两个不同的分布式节点 的时候的处理方案。
CAP定理 指出对于一个分布式计算系统来说，不可能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
有这么一种说法：以实际效果而言，系统若不能在时限内完成同步，达到数据一致性；就意味着发生了分区的情况，必须就当前操作在一致性和可用性之间做出选择。
三、一致性（Consistency）
一致性是说，所有节点访问同一份最新的数据副本；即一致性保证了无论将数据写入哪一个节点，其它的节点都能实时同步到这个新数据，随后无论从哪个节点读到的都是最新的数据。如下图所示：
如果节点之间数据同步有异常，那就必须先解决掉同步的问题，挂起所有的请求，等待数据同步完成后才响应，那么会出现以下几种情况：
- 在等待很久后才得到了正确结果
- 写入数据异常
- 读取数据异常
四、可用性（Availability）
可用性是说，如果有节点异常了，只要向其它无异常的节点发送请求，总能正常的收到响应数据，但数据可以不是最新的，如下图所示：
五、分区容错性（Partition tolerance）
先说分区是什么，在分布式系统中，不同的节点分布在不同的子网络中，若因一些网络故障，出现了子网络之间不通的情况，但每个子网络内是正常的；这样一个完整的系统就被切分成了若干个相对孤立的区域。这就是分区。
对于分布式系统来说，在遇到任何网络故障而导致分区时，仍然能够对外提供具有一致性或可用性的服务。也就是说会分区之间即使无法同步数据，也能对外提供服务。
六、反推CAP定理
借用一个示例以反证法的方式来梳理CAP定理，如整个系统由服务节点A、B组成，节点之间通过网络通信，当节点 A 进行更新数据操作的时候，需要同时更新节点 B 的数据。
假设同时满足CAP这三个特性，由于具有分区容错，则可以切断 A、B两个节点间的通信
- 当A、B通信断开后，因无法通信，一致性就无法满足，但A、B都还能对外提供服务，满足可用性
- 若要强行满足一致性，就必须让A、B不再提供服务，等A、B的网络通信故障修复后才继续提供服务，这就放弃了可用性。
所以总结来看：
- 若要一致性：则必须保障节点间数据同步，同步执行期间数据锁定、请求挂起，会导致期间的请求失败或超时，破坏了可用性
- 若要可用性：则不允许节点间数据同步时被数据锁定、请求挂起，这又破坏了一致性。
七、一致性的取舍
总结来说，在分布式系统中，首先必须要满足P，因为是多节点，一定要会遇到并要容忍分区错误，而C或A需要根据具体场景进行取舍。
| 组合 | 结果 |
| CP | 满足一致性和分区容错性，也就是说，要放弃可用性。当系统被分区，为了保证原子性，必须放弃可用性，让请求挂起。 |
| AP | 满足可用性和分区容错性，当出现分区，同时为了保证可用性，即使数据尚未完成同步，也必须让节点继续对外服务，这样导致数据不一致 |
当系统既要提供可用性，而又不能放弃一致性的情况下，通常会因场景差异而调整对一致性的要求，而差异点体现在时效性上如：
- 强一致性
任意时刻，任意节点都读取到最新的数据 - 弱一致性
可能无法在明确限定的时间内读到最新的数据 - 最终一致性
是一种特殊的弱一致性，系统保证在过了某个时间窗口后，数据将达到完全一致的状态，而之后的读取一定是新数据。
分布式业务系统实现中，多数场景中会选择牺牲一致性来换取可用性。而所谓的牺牲其实是不追求强一致，而选择弱一致或最终一致。
最后说一句(请关注，莫错过)
如果这篇文章对您有帮助，或者有所启发的话，欢迎关注公众号【 架构染色 】进行交流和学习。您的支持是我坚持写作最大的动力。
