多类型副本混搭：降低集群成本的利器
1.背景
在数据库系统中，为了容灾考虑，一般会采用一主一备的部署方式，在灾难发生的时候，可以灵活的进行主备切换，从而不影响对外提供服务。在要求更高的可靠性和读写分离的场景下，会增加备机的数目；实现一主多备，将不同的副本部署在不同的数据中心，提高宕机容灾能力。
为了更高的可靠性和可用性，OceanBase 1.4版本开始支持5副本的部署方案，每个数据表的分区都包括5个副本，分布在集群之中，能够容许单机故障、数据中心故障以及城市级别的故障，具体的部署方案可以参看之前发表的《城市级故障自动无损容灾的“新常态”方案》。
1.4版本之前，Oceanbase支持的3副本，只有主副本对外提供服务，另外两个备副本作为热备，不提供读写服务，通过分布式paxos协议来进行数据同步，具备随时切换成主的能力，为了提高整个集群的利用率，实际部署会将主副本分散到集群的每个ObServer上面，所有的OBServer共同承担读写服务。1.4版本中为了实现城市级别容灾，将副本数升级了成了5，相当于我们要付出5倍于单副本的资源，这个与我们OceanBase高可用低成本的宗旨是不相符的。OceanBase作为一个金融级的分布式数据库，高可用、低成本、高性能是它的关键字，我们的五副本策略使得OceanBase能够容忍跨机房、跨地域的故障，提供了高可用的服务，为了成本和性能考虑，我们设计出多种类型的副本，来降低成本、提高性能。
2.多类型副本
2.1 数据模型
一个完整的OceanBase数据副本包含三部分：MemTable、SSTable，日志。其中：
MemTable是数据库的增量修改，存储在内存中，也称为增量数据；
SSTable是数据库中未做更改的基线数据，也称为静态数据，存储在磁盘中；增量数据和静态数据会定期的合并到一起，作为新的静态数据；
日志是每个事务的操作日志，多副本之间通过paxos协议来进行数据同步，paxos协议要求至少有三个副本参与，其中一个主副本，两个备副本，每个事务必须要在主副本上执行成功，并且需要将日志同步到至少一个副本，形成多数派以后才能应答客户端。
我们对每个数据副本的组成和实现进行了调整，形成了多种类型的副本；
2.2 多类型副本
正常一个OceanBase集群里面，每个partition只有主在提供读写服务，但是为了容灾和数据同步一致性，我们需要同时配备多个热备，相当于我们会多花费几倍的资源来做这件事情。有了多类型副本以后，我们就可以在达到高可用的同时降低成本提高效率；下面我们逐个介绍每个类型副本；
全能型副本
也就是目前支持的普通副本，拥有日志，MemTable和SSTable等全部完整的数据和功能。它可以随时快速切换为leader对外提供服务。需要消耗内存、磁盘、网络等资源。日志型副本
只包含日志的复本，没有MemTable和SSTable。它参与日志投票并对外提供日志服务，可以参与其他复本的恢复，但自己不能变为主提供数据库服务。在三地三中心五副本的配置中，我们可以将其中两个副本设置成日志型副本，既能达到地域级容灾的效果，又降低了内存成本和磁盘成本；主要消耗网络资源；只读型副本
包含完整的日志，MemTable和SSTable等，但是它的日志比较特殊。它不作为paxos成员参与日志的投票，而是作为一个观察者实时追赶paxos成员的日志，并在本地回放。这种副本可以在业务对读取数据的一致性要求不高的时候提供只读服务，因此可以通过添加只读型副本来增加系统读请求的性能，同时，也不会因为副本数变多，导致写操作需要的同步时间变长，只读型副本不参与投票。主要消耗内存和磁盘资源。
可以通过下面这个表格来对比几个副本的特性：
| 类型 | 日志 | MemTable | SSTable | 数据安全 | 恢复为leader时间 | 资源成本 | 服务 |
| 全能型 | 有，参与投票 | 有 | 有 | 高 | 快 | 高，耗网络、内存、磁盘 | leader提供读写，follower可非一致性读 |
| 日志型 | 有，参与投票 | 无 | 无 | 低 | 不支持 | 低，耗网络 | 不可读写 |
| 只读型 | 有，不参与投票 | 有 | 有 | 中 | 不支持 | 高，耗网络内存磁盘，对网络延时敏感度不高 | 可非一致性读 |
在实际部署的时候，我们可以让多个租户混布在同一个集群中，OceanBase内部负载均衡策略会充分利用每台机器的所有资源，让耗内存多的副本和耗内存少的副本位于同一台机器上，让占磁盘空间多的副本和占磁盘空间少的副本位于同一台机器上。不同类型的副本需求的资源各不相同，经过OceanBase的负载计算，最终会使得所有机器的各类型资源占用都处于一种比较均衡的状态。
一种简单的多租户混布的场景如下图所示：