一、分布式系统的需求与困境会不会有大老板（产品？老板？）对你负责的分布式系统提出以下三个需求：既：系统高可用又需要：各系统数据一致，实时可见。另外：系统具有集群容错能力。这些要求看似简单，但仔细想想，你会发现很头疼，无法完全实现；如果你还不明白，让我们举个例子。举例，防疫期间静态管理：人员停工、企业停产（失去可用性）、全市综合核酸、统一使用核酸码平台、数据实时统筹管理（确保数据consistency）人被限制在社区活动，交换资料，有过cell间禁止互通（partitionfaulttolerance）经历的人应该明白，当我们要满足2和3时，就必须牺牲1；也许你也曾想过如何破局却一头雾水；但是没有必要责备自己，不仅是你会觉得困难，其他人也会，因为它违反了CAP定理。二、CAP定理的混淆在理论计算机科学中，CAP定理（CAPtheorem），也称为布鲁尔定理（Brewer'stheorem），定理讨论的是两个相互矛盾的请求到达两个不同的、互不相连的连接。分布式节点的处理方案。CAP定理指出，对于分布式计算系统，不可能同时满足一致性、可用性和分区容错性。CAP定理（来自网络）.png有这样一种说法：从实际效果来看，如果系统不能在限定时间内完成同步，实现数据一致性；意味着发生了分区，当前操作必须是一致的和可用性的。3.一致性（Consistency）一致性是指所有节点都访问同一份最新的数据副本；即一致性保证无论数据写入到哪个节点，其他节点都可以实时同步到新的数据，然后无论从哪个节点读取都是最新的数据。如下图所示：CAP定理-一致性（来自网络）。会出现以下情况：请求等待很长时间后得到正确的结果。写数据异常，读数据异常。如果出现异常，只要向其他非异常节点发送请求，总能正常收到响应数据，但数据不一定是最新的，如下图：CAP定理-可用性（来自网络).png5.分区容错（Partitiontolerance）首先说一下分区是什么。在分布式系统中，不同的节点分布在不同的子网络中。如果出现某些网络故障，子网之间无法互通，但各个子网是正常的。;这样一个完整的系统被分成几个相对孤立的区域，这些区域就是分区。对于分布式系统来说，在网络出现故障导致分区的情况下，仍然可以对外提供一致性或可用性的服务。也就是说，即使分区之间不能同步数据，仍然可以对外提供服务。CAP定理-分区容错（来自网络）6.ReverseCAPTheorem借用例子通过证明的方式梳理CAP定理，比如整个系统由服务节点A和B组成，节点间通过网络。当A节点更新数据运行时，需要同时更新B节点的数据。集群同步例子（来自网络）假设同时满足CAP的三个特性。由于分区容错，可以切断两个节点A和B之间的通信。当节点A和B之间的通信断开时，一致性无法满足，但A和B仍然可以对外提供服务。如果满足可用性，如果要强制满足一致性，则A和B节点必须不再提供服务，修复A和B节点之间的网络通信后再继续。提供服务，但这会放弃可用性。所以总结一下：想要一致性：必须保证节点间的数据同步。同步执行过程中，数据被锁定，请求被挂起，会导致请求失败或超时，破坏可用性。如果你想要可用性：节点之间的数据是同步的当数据不允许被锁定并且请求被挂起时，这会破坏一致性。7.一致性权衡综上所述，在分布式系统中，首先要满足P。因为是多节点，分区错误是必须遇到和容忍的，而C或A需要根据具体场景来选择。组合结果CP满足一致性和分区容错性，即必须放弃可用性。当系统被分区时，为了保证原子性，必须放弃可用性，暂停请求。AP满足可用性和分区容错。当发生分区时，为了保证可用性，即使数据没有同步，节点也必须继续对外服务，这就导致了数据不一致。当系统需要提供可用性时，它不能放弃一致性。在这种情况下，一致性的要求通常会因场景的不同而有所调整，差异体现在时效性上。比如：强一致性，任何节点都可以随时读取到最新的数据。读取一定时间内的最新数据。最终一致性是弱一致性的一种特殊形式。系统保证在一定的时间窗口后，数据会达到完全一致的状态，后续读取的一定是新数据。.在分布式业务系统的实现中，大多数场景下，你会选择牺牲一致性来换取可用性。所谓牺牲，其实不是追求强一致性，而是选择弱一致性或最终一致性。本文转载自微信公众号“建筑染”，可通过以下二维码关注。转载本文请联系【结构染】公众号作者。
