分布式事务Seata【二】CAP定理和Base定理

CAP定理

CAP原则又叫CAP定理，同时又被称作布鲁尔定理（Brewer's theorem），指的是在一个分布式系统中，不可能同时满足以下三点。

• 一致性（Consistency 副本最新）：指强一致性，在写操作完成后开始的任何读操作都必须返回该值，或者后续写操作的结果。

  也就是说，在一致性系统中，一旦客户端将值写入任何一台服务器并获得响应，那么之后client从其他任何服务器读取的都是刚写入的数据

  一致性保证了不管向哪台服务器写入数据，其他的服务器能实时同步数据

• 可用性（Availability 高可用）：可用性是指，每次向未崩溃的节点发送请求，总能保证收到响应数据（允许不是最新数据）

什么是分区？
在分布式系统中，不同的节点分布在不同的子网络中，由于一些特殊的原因，这些子节点之间出现了网络不通的状态，但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域。这就是分区。

• 分区容忍性（Partition tolerance 能容忍网络分区）：分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，也就是说，服务器A和B发送给对方的任何消息都是可以放弃的，也就是说A和B可能因为各种意外情况，导致无法成功进行同步，分布式系统要能容忍这种情况。除非整个网络环境都发生了故障。

  

  容许节点 G1/G2 间传递消息的差错（延迟或丢失），而不影响系统继续运行。

  以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

为什么只能在A和C之间做出取舍？

分布式系统中，必须满足 CAP 中的 P，此时只能在 C/A 之间作出取舍。

整个系统由两个节点配合组成，之间通过网络通信，当节点 A 进行更新数据库操作的时候，需要同时更新节点 B 的数据库（这是一个原子的操作）。

下面这个系统怎么满足 CAP 呢？我们用反证法 假设可以同时满足一致性、可用性、分区容错这三个特性，由于满足分区容错，可以切断 A/B 的连线，如下图：

可见，根本完成不了，只要出现了网络分区，A 就无法满足，因为节点 A 根本连接不上节点 B。如果强行满足 C 原子性，就必须停止服务运行，从而放弃可用性 C。

• 若要保证一致性：则必须进行节点间数据同步，同步期间数据锁定，导致期间的读取失败或超时，破坏了可用性；
• 若要保证可用性：则不允许节点间同步期间锁定，这又破坏了一致性。

所以，最多满足两个条件：

如何权衡（保C还是保A？）

取舍

• 舍弃P(选择C/A)：单点的传统关系型数据库 DBMS(MySQL/Oracle)，但如果采用集群就必须考虑P了；
• 舍弃A(选择C/P)：是分布式系统要保证P，而且保证一致性，如 MongoDB / HBase；
• 舍弃C(选择A/P)：是分布式系统要保证P，而且保证可用性，如 CoachDB / Cassandra / DynamoDB。

• 注：redis-cluster是AP，zookeeper写入强一致，读取是顺序一致性(即弱一致)。

对于一个分布式系统来说，CAP三者中，

• P是基本要求，只能通过基础设施提升，无法通过降低 C/A 来提升；
• 然后在 C/A 两者之间权衡。

一个还不错的策略是：保证可用性和分区容错，舍弃强一致性，但保证最终一致性，比如一些高并发的站点（秒杀、淘宝、12306）。最终近似于兼顾了三个特性。

数据一致性

一致性可以分为强一致性与弱一致性。所谓强一致性，即复制是同步的，弱一致性，即复制是异步的。

CAP回顾
CAP理论告诉我们一个悲惨但不得不接受的事实——我们只能在C、A、P中选择两个条件。而对于业务系统而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里要指出的是，所谓的“牺牲一致性”并不是完全放弃数据一致性，而是牺牲强一致性换取弱一致性。

强一致性

系统中的某个数据被成功更新后，后续任何对该数据的读取操作都将得到更新后的值；

也称为：原子一致性（Atomic Consistency）线性一致性（Linearizable Consistency）

两个要求：

• 任何一次读都能读到某个数据的最近一次写的数据。
• 系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。

简言之，在任意时刻，所有节点中的数据是一样的。例如，对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。

总结：

• 一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后，才能正常的对外提供服务。
• 保证了强一致性，务必会损耗可用性。

弱一致性

系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。

但即使过了不一致时间窗口这段时间后，后续对该数据的读取也不一定是最新值

所以说，可以理解为数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。

最终一致性

是弱一致性的特殊形式，存储系统保证在没有新的更新的条件下，最终所有的访问都是最后更新的值。

不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。

简单说，就是在一段时间后，节点间的数据会最终达到一致状态。

一致性总结

弱一致性即使过了不一致时间窗口，后续的读取也不一定能保证一致，而最终一致过了不一致窗口后，后续的读取一定一致

Base理论

• BA：Basic Available（基本可用）

  • 整个系统在某些不可抗力的情况下，仍然能够保证“可用性”，即一定时间内仍然能够返回一个明确的结果。只不过“基本可用”和“高可用”的区别是：

    • “一定时间”可以适当延长
      当举行大促时，响应时间可以适当延长
    • 给部分用户返回一个降级页面
      给部分用户直接返回一个降级页面，从而缓解服务器压力。但要注意，返回降级页面仍然是返回明确结果。
• S：Soft State（柔性状态）
  是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统不同节点的数据副本之间进行数据同步的过程存在延时。
• E：Eventual Consisstency（最终一致性）：
  同一数据的不同副本的状态，可以不需要实时一致，但一定要保证经过一定时间后仍然是一致的。

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。