分布式事务为何让我如此反感，原因究竟何在？

CAP，基础理论 CAP理论是分布式系统中最核心的理论基础 Partition tolerance，分区容错性 the system continues to operate despite arbitrary message loss or failure of part of the system 系统能够在网络分区(网络故障或通信故障)的情况下还能继续提供服务 Consistency，一致性 all nodes see the same data at the same time 所有节点在同一时间的数据是相同的，也就是更新操作完成后，所有节点保存的数据相同 Availability，可用性 Reads and writes always succeed 系统服务一直处于可用状态， 为什么CAP只能满足两个目标 C,A,P只能同时满足两个目标，而P是分布式的基本盘，所以需要在C与A之间进行取舍。 如果要保证服务可用性，就选择AP模型 选择AP意味着舍弃强一致性，以保证可用性与分区容错性。在AP架构下，系统能够快速响应客户端的请求，即时在网络分区情况下，也尽量保证服部分节点可用，从而为客户端提供不间断的服务，允许临时数据不一致（如异步复制） 如果要保证数据一致性，就选择CP模型 选择CP意味着舍弃可用性，以保证一致性与分区容错性。在CP架构下，系统会优先保证数据的一致性，当发生网络分区时，牺牲可用性（如暂停写操作直到分区修复）。 单机部署，就选择CA模型 场景： 你有一个缓存服务(类redis)，集群化部署了3个实例。 此时你写入缓存，正好其中一个实例写入无法响应(网络分区)，但读取正常。 此时你的缓存服务需要做出决定， A vs C ? 选Availability，保证可用性，无视损坏的节点，更新正常节点数据。一致性被破坏，可能会读取到脏数据。 选Consistency，保证一致性，等待节点恢复或者移除，可用性被破坏，在此期间所有写入都无法成功。 CAP的理论，只有网络分区发生了，才需要在CAP中进行权衡，但大部分时间，网络分区是不会发生的。因此CAP理论可以作为系统设计时需要衡量的因素，而非绝对的选择。 PACELC，拓展理论 CAP+Everything is Local and Connected = PACELC ，是CAP理论的拓展，上面说到CAP理论是在网络分区发生的情况下才需要考虑的。大多数情况下，系统都是平稳运行。在这种情况下，因为不需要考虑网络分区，所以要考虑就是数据一致与读写延迟的平衡 P 分布式系统在面对网络分区时(网络故障或通信故障)，仍然能够继续运行。 A 分布式系统在面对故障时，依然能够提供服务并保证数据的可访问性。 C 分布式系统在面对网络分区时，能够保持数据一致性。 E Eventual consistency，最终一致性，分布式系统在面对网络分区时，由于网络延迟或者异步复制等原因，可能会导致节点之间数据的不一致，但最终会达到一致状态 L Latency ，延迟，分布式系统的响应时间，在一些情况下，为提高系统响应速度，可能会牺牲一致性或者可用性 场景 承接上面的场景，你的缓存服务很聪明，当heathly check检查到问题后，马上启用一个新的实例来替代异常实例。 但你此时面临一个问题，旧实例上的缓存数据需要迁移到新实例中，迁移的过程需要一定时间。 此时进入ELC矛盾阶段，在延迟(Latency)和一致性(Consistency)之间需要权衡。 选Latency，允许数据暂短不一致，在迁移的过程中可能读取到旧数据 选Consistency，保证强一致性，暂停分区节点的写入，直到所有节点全部写入。 比如数据库的OLTP与OLAP， OLTP保证一致性，所有数据库操作都是主从节点均写入成功后才返回，而OLAP往往会有几秒的数据延迟。 因此，PACELC也可以理解是对CAP的替代，因为它不仅讲述了网络分区的极端情况下如何取舍，还覆盖了系统正常时应该考虑的事项。 BASE，具体落地理论 Base 理论是 AP 系统(牺牲强一致性)的实践指导，通过牺牲强一致性换取高可用性和分区容错性，是 CAP 定理在工程中的具体落地方式。 Basically Available，基本可用 不追求CAP中的，任何时候读写都可以成功，而是系统能够基本运行，一直提供服务。 允许损失部分可用，可能是响应时间延长，或者服务降级。 举个例子，如果并发太多超过了系统QPS峰值，可能会提示排队。亦或是通过限流，熔断等措施，这就是通过合理手段保护系统的稳定性。