云原生数据库 GaiaDB 架构设计解析：高性能、多级高可用( 二 ) _云原生数据库

文章插图
GaiaDB 的高性能 & 多级高可用设计
接下来我来分享一下 GaiaDB 的性能核心设计理念——通过融合和裁剪，将数据库和分布式存储进行深度融合，为全链路的同步转异步化提供条件，从而实现极致的性能与通用性。
我们可以看到，如果数据库简单使用通用分布式协议和单机存储引擎，如左图所示，那么数据库需要处理主从同步，需要有 CrashSafe 所需要的物理日志。同时，一致性协议也要有主从同步，要写自己的 WAL 以及持久化快照。而单机引擎同样需要 CrashSafe 以及一套日志系统和数据存储逻辑。
我们发现，多层日志的嵌套带来了层层延迟与写放大。更复杂的是，数据流中嵌套多层逻辑后，也给系统整体数据安全带来了一定挑战。同时由于多层之间需要串行等待，所以在加入了网络延迟后会给数据库带来很大的性能下降。虽然可以使用定制化硬件与网络来缩短网络和磁盘落盘的延迟以降低链路耗时，但这又引入了新的不确定性并导致了更高的成本。
GaiaDB 的解决思路是将事务和主从同步逻辑、日志逻辑、快照和存储持久化逻辑重新组合和排布。
首先是将分布式协议的主从同步逻辑融合进数据库计算节点中。由于计算层本身就需要处理主从同步、事务和一致性问题，相关的工作量增加并不大。这样一来，最直接的收益就是将两跳网络和 I/O 精简为一跳，直接降低了链路延迟。
其次 GaiaDB 将多层增量日志统一改为使用数据库 Redo 物理日志，由 LogService 日志服务统一负责其可用性与可靠性。
除此之外，GaiaDB 也将持久化、快照和数据库回放功能融合入存储节点。由于存储层支持了数据库回放能力，可以很轻松实现数据页级别的 MVCC 。这样全链路只剩下了数据库语义，数据流简单可靠，逻辑大大简化。

文章插图
下面我们一起来看下共识模型上的改变。
像 Raft 协议是需要两跳网络才能实现一次提交确认的，右上角就是 Raft 的数据流架构：CN 节点将写发送给 Leader 后，需要等待 Leader 发送给 Follower 并至少收到一个返回后才能成功。
这里就带来了两跳网络和 I/O 的同步等待问题。而 GaiaDB 则是计算节点直接发送给多个 Log 服务并等待多数派返回，这样不依赖任何特殊硬件与网络就降低了延迟。这样系统里不管是事务的一致性还是多副本一致性，统一由计算节点统筹维护，所有的增量日志也统一为数据库物理日志，整体数据流简单可控。
对于数据风险最高的 Crash Recovery 场景，由于统一使用了数据库语义，整体流程更加健壮，数据可靠性更高，降低了数据在多种日志逻辑之间转换和同步带来的复杂度风险。而在性能方面，由于存储层自身具备回放能力，可以充分利用 LogService 层的日志缓存能力。对于写操作来说，不需要每次更改都刷盘，可以批次回放刷盘，大大节省了磁盘吞吐与 I/O 。
经过以上改造，线上吞吐性能可以提升 40%。同时由于链路简化，也大大优化了长尾延迟。像之前计算节点与分布式主节点之间发生网络抖动的场景，就会被多数派的返回特性来优化。

文章插图
分享完一致性协议层优化，接下来我们来探讨一下链路层优化。
我们知道，总吞吐与并发度成正比，与延迟成反比。一致性协议层改造并缩短了数据链路，可以通过降低延迟来增加吞吐。那么有没有办法通过提升数据流的并发度来提升吞吐呢？答案是可以。由于数据库的物理日志自带版本号与数据长度，所以不需要像通用存储一样实现块级别串行提交。之所以使用通用存储需要串行提交，是因为存储端只能根据请求到达的先后确定数据版本，如果乱序到达，最后生效的版本是不可知的。
而对于 GaiaDB 来说，由于 LogService 具备数据库语义的识别功能，所以计算节点只需要异步进行写入，日志服务就会自动根据数据版本选取最新数据，然后根据写入情况批量返回成功，这样链路就可以实现延迟与吞吐的解耦。
当然计算层依然会等待日志层批量返回的最新落盘版本后再返回事务提交成功，所以依然可以满足提交成功的事务一致性、持久化的要求。
另外针对高负载下 I/O 请求与数据库业务请求争抢 CPU 的问题，我们使用了 I/O 线程隔离技术，通过资源隔离的方式，将 I/O 线程与数据库业务线程进行隔离。这样即使在复杂负载场景下， I/O 延迟仍可以保持在较低水平。