为了介绍 Aurora,我们先来简单看一下通常 Distributed Consensus 是如何做到 Strong Consistency 的。
我们假设当前计算端的状态是 S0,此时我们收到了一个请求,要把状态变更为 S1。为了完成这个变更,存储端会发起了一次 Distributed Consensus。如果成功,则计算端把状态变更为 S1;如果失败,则状态维持在 S0 不变。可以看到存储端向计算端返回的状态只有成功和失败两个状态,而实际上存储端内部会有更多的状态,例如 5 个节点里面 3 个成功了,1 个失败了,1 个超时了。而这些状态都被存储端屏蔽了,计算端不感知。这就导致计算端必须等待存储端完成 Distributed Consensus 以后,才能继续向前推进。在正常情况下不会有问题,但一旦存储端发生异常,计算端必须要等待存储端完成 Leader Election 或 Membership Change,导致整个计算端被阻塞住。
而 Aurora 则打破了这个屏障。Aurora 的计算端可以直接向存储端发送写请求,并不要求存储端节点之间达成任何的 Consensus。
典型的 Aurora 实例包含 6 个存储节点,分散在 3 个 AZ 中。每个存储节点都维护了 Log 的列表,以及 Segment Complete LSN(SCL),也就是已经持久化的 LSN。存储节点会将 SCL 汇报给计算节点。计算节点会在 6 个节点中,找出 4 个最大的 SCL,并将其中最小的值作为 Protection Group Complete LSN(PGCL)。而 PGCL 就是 Aurora 实例已经达成 Consistency Point。
看上去好像和 Multi-Paxos 也有些相似?是的,但 Aurora 并不要求存储节点之间达成任何的 Consensus,发生故障的时候,存储节点不需要参与 Leader Election,也不需要等待所有的日志复制完成。这意味着计算节点基本上永远不会被阻塞。
Aurora 的精妙之处在于把 Distributed Consensus 从存储节点中抽离出来了,存储节点只是单纯的负责存储工作就好了,而 Consensus 由计算节点来完成。那这样看上去好像又和 PacificA 很相似?是的,我认为在整体思路上,Aurora 和 PacificA 是非常相似的。我个人认为 Consensus 和存储节点的解耦会是未来的一个趋势。