我们继续跟随上期，
复杂的结构增加了出现故障的概率，作为云服务的数据库的第三个要接受的挑战就是系统服务的稳定性，在以往的经验中，我们针对单节点的故障进行了经验的总结，来保证我们的系统不会出现单点故障的情况。基于我们的内存和存储是分离的设计，我们这让我们的读写节点恢复相比较传统的架构要快至少5倍以上。
我们总结POALRDB 以下的一些特点
1 我们遵循了无服务架构设计的原则，设计了POALRDB，并且将其实现，针对无服务架构数据库的设计有这一定的贡献。
2 我们提供了相关的设计细节，并且让这个系统跨越了分离结构设计的一些弊病，并让这个系统很有效率的运行。
3 对于单节点和集群方面的我们提出了相关的容错的策略。
本文的其余部分组织如下。在第二节中，我们介绍了PolarDB和DDC的背景。第3节解释了PolarDB Serverless的设计。第4节介绍我们的性能优化。第5节讨论我们的容错和恢复策略。第6节给出了实验结果。第7节回顾了相关工作，第8节总结了本文。
第二部分，背景
Polardb 是一个云原生的数据库产品，使用了共享存储的架构，他主要基于MYSQL的源代码并使用了 POLARFS 文件存储系统作为底层的存储池。他在计算层基于一个主节点和多个从节点。换句话，他具有一个传统数据库的内核，在每一个 RW RO 节点都具有 SQL 的执行器，和 INNODB 一样的引擎以及 X-Engine 引擎，通过buffer pool 处理 要查询的数据和事务的数据。
除此以外，还通过代理的方式来处理均衡负载。
PolarFS 是一个具有原子性，可扩展性和持久性的存储服务。他提供了虚拟存储将存储分为10G 一个分布式存储块。一个卷包含最多10000个块，并可以提供一个最大值100 tb的能力。块是按需供应的，卷空间也是动态增长。每个区块都有三个副本通过一致性协议RAFT的变种Parallel Raft保证线性序列化。
我们看下图，RW 节点和RO 节点通过REDO LOG 同步内存的状态，这里的通过INNODB 中的redo log 的文件指定的偏移量，让事务的一致性通过日志的LSN号来满足。从下图中事务通过代理与RW 节点进行交互，redo log 的记录刷到PolarFS的，通过这样的方式让事务进行commited。RW 节点广播REDO LOG 中已经UPDATE 或最后的LSN 号信息到RO 节点异步复制。
在RO 节点接受到了来自RW的信息后，将REDO LOG 从 POLARFS 中拉出来更新到自己的buffer pool中，同时更新REDO LOG 的偏移量进行日志的重放，在将自己的状态发还给RW 节点，此时系统就可以确认当前最小的LSN 号，在拿到了最小的LSN号后，RW节点就凭借这个信息开始将LSN之前脏页的信息刷写到POLARFS 系统中。刷写不会影响影响，这里通过的后备进程的方式进行信息的刷写。
从库对于事务的隔离性的问题，也是通过LSN号来完成的，部分RO节点可能会因为高CPU的占用率或者网络等问题导致LSN 回馈远远低于预设值，则系统会直接将这些RO 节点抛弃掉，保证RW能顺利的将脏页刷新。
代理节点提供了通过透明的均衡负载的工作引导读写操作的请求，并将读请求导向从节点，将写请求导向主节点。
计算节点，内存节点，存储节点通过高速网络来进行互联，通过RDMA 网络技术将这样的想法得以实现。阿里云的数据库中心的网络采用的基于以太网多层clos网络，使用rdma 中的RoCEV2 技术。
如上图展示这是一个典型的阿里云的数据中心的三层结构，分为 spine layer, leaf layer , ToR layer 三层，一个ToR switch 将连接48个节点，ToR 交换连接到 leaf 交换， leaf 交换连接到spine 交换。每台机器都配备了一个双端口RDMA网卡，它连接到两个不同的ToR交换机，以支持在单个网络链路故障的情况下持续服务。
叶子交换机组由多个叶子交换机组成，它们同时提供服务，并互为备份。由叶子交换机组管理的机架和服务器的集合称为PoD(交付点)。一个PoD最多包含32组ToR，即超过1500台服务器，PoD中的服务器通过RDMA网络互联完成工作。
在这样的结构下，计算，内存，和存储节点同一个Pod下，计算和内存的节点分配是在同一个TOR下，这样做是为了降低延迟和抖动。
