OpenBase关于一致性,可用性,分区容错性(CAP)分析

2022-04-06 00:00:00 节点 分区 写入 单元 老师

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

相关文章