OceanBase 的 CAP 分析

单元化架构中的成千山万的应用就像是计算器，本身无 CAP 限制，其 CAP 限制下沉到了其数据库层，也就是蚂蚁自研的分布式数据库 OceanBase（本节简称 OB）。

在 OB 体系中，每个数据库实例都具备读写能力，具体是读是写可以动态配置。
实际情况下大部分时候，对于某一类数据（固定用户号段的数据）任意时刻只有一个单元会负责写入某个节点，其他节点要么是实时库间同步，要么是异步数据同步。
OB 也采用了 PAXOS 共识协议。实时库间同步的节点（包含自己）个数至少需要 (N/2)+1 个，这样就可以解决分区容忍性问题。
下面我们举个马老师改英文名的例子来说明 OB 设计的精妙之处：假设数据库按照用户 ID 分库分表，马老师的用户 ID 对应的数据段在 [0-9]，开始由单元 A 负责数据写入。

假如马老师（用户 ID 假设为 000）正在用支付宝 App 修改自己的英文名，马老师一开始打错了，打成了 Jason Ma，A 单元收到了这个请求。
这时候发生了分区（比如 A 网络断开了），我们将单元 A 对数据段 [0,9] 的写入权限转交给单元 B（更改映射），马老师这次写对了，为 Jack Ma。
而在网络断开前请求已经进入了 A，写权限转交给单元 B 生效后，A 和 B 同时对 [0,9] 数据段进行写入马老师的英文名。
假如这时候都允许写入的话就会出现不一致，A 单元说我看到马老师设置了 Jason Ma，B 单元说我看到马老师设置了 Jack Ma。
然而这种情况不会发生的，A 提议说我建议把马老师的英文名设置为 Jason Ma 时，发现没人回应它。

因为出现了分区，其他节点对它来说都是不可达的，所以这个提议被自动丢弃，A 心里也明白是自己分区了，会有主分区替自己完成写入任务的。
同样的，B 提出了将马老师的英文名改成 Jack Ma 后，大部分节点都响应了，所以 B 成功将 Jack Ma 写入了马老师的账号记录。
假如在写权限转交给单元 B 后 A 突然恢复了，也没关系，两笔写请求同时要求获得 (N/2)+1 个节点的事务锁，通过 no-wait 设计，在 B 获得了锁之后，其他争抢该锁的事务都会因为失败而回滚。

下面我们分析下 OB 的 CAP：

分区容忍性：OB 节点之间是有互相通信的（需要相互同步数据），所以存在分区问题，OB 通过仅同步到部分节点来保证可用性。这一点就说明 OB 做了分区容错。

可用性分区容忍性：OB 事务只需要同步到 （N/2)+1 个节点，允许其余的一小半节点分区（宕机、断网等），只要 (N/2)+1 个节点活着就是可用的。

极端情况下，比如 5 个节点分成 3 份（2:2:1），那就确实不可用了，只是这种情况概率比较低。

一致性分区容忍性：分区情况下意味着部分节点失联了，一致性显然是不满足的。但通过共识算法可以保证当下只有一个值是合法的，并且终会通过节点间的同步达到终一致性。

所以 OB 仍然没有逃脱 CAP 魔咒，产生分区的时候它变成 AP+终一致性（C）。整体来说，它是 AP 的，即高可用和分区容忍。
————————————————

原文链接：https://blog.csdn.net/a284365/article/details/120890816