分布式数据库是如何实现高可用的？

大家在使用数据库的时候，都会提到一个衡量标准——高可用。高可用说起来很容易理解，但是它也是数据库的难点之一。

高可用不仅要求在正常的场景下不间断的提供稳定的服务，而且需要能够在failover的条件下也能快速恢复并迅速提供服务，使用户难以感知到异常。

一、高可用的前提

高可用的大前提：所有事物都不是100%可靠的。

• 从人的层面：人都是有可能犯错的
• 从软件层面：软件都是有可能有BUG的
• 从硬件层面：硬件都是有可能会坏的

正是因为这个大前提，要求在数据库的实现上，必须能够处理这种不可靠的场景。

二、传统数据库＆分布式数据库

高可用是数据库的基本需求之一，传统数据库允许通过日志同步实现主备镜像；

图1：传统关系型数据库

然而，由于主备镜像中主库与备库无法完全同步，因此传统数据库的高可用其实是建立在传统的高可靠服务器（如小型机）和高可靠共享存储（如EMC)之上的。

图2：传统商业数据库高可用原理

如图2，在传统商业数据库中，使用者将事务提交给某个数据库实例(DB), DB将事务日志(Transaction Logs) 以及数据(Shared Data)存储到共享存储中。由于DB不持久化状态，当某个DB出现故障时，其它DB能够很快接管该DB之前的服务，整个过程对使用者是透明的。

业内成熟的商业数据库高可用解决方案包括 Oracle RAC 以及 IBM Purescale。这两种解决方案底层实现机制虽然有所不同，但从根本上讲，都需要依赖高可用共享存储。

传统商业数据库的这种做法比较成熟，广泛应用在传统企业中。然而，在互联网时代，这种方案面临一个最主要的问题是成本：高端服务器和共享存储的成本都极其高昂。

而我最近接触到一个分布式金融关系型数据库 SequoiaDB (巨杉数据库)能够在成本较低的基础上做到高可用和高性能。

随着我一起来看看SequoiaDB是怎么做的吧。

注：高可用 设计的方面比较多，很难一次说清楚，计划分成多篇，由浅入深，循序渐进。

三、SequoiaDB高可用原理

SequoiaDB

图3：SequoiaDB的高可用架构

在SequoiaDB分布式数据库架构中，采用了PC服务器与普通HDD磁盘，取代传统的小型机加外置存储架构。这种PC服务器＋普通HDD磁盘架构虽然大大降低了硬件的整体成本，但是硬件的故障率却大大增加了。

在这种情况下，常用的做法就是通过优秀的软件设计，将数据库中的数据以同步或异步的方式复制到多台物理设备中，保证不会因为偶发的硬件故障导致数据丢失或出错。

图4：复制组

如图4，在SequoiaDB 巨杉数据库中，有个复制组的概念－－是指一份数据的多个拷贝，其中每一份数据拷贝被称为数据副本，保存在数据节点中。可以通过复制组将其数据在多台物理设备中进行复制拷贝。

SequoiaDB 如何通过多副本来保证高可用呢？我认为有以下2点：

1. 复制组内数据节点互为副本，一主多从，支持1~7个节点，具备高可靠和高可用能力。换句话说，同一份数据保存在多台服务器中的半数以上服务器上（例如3台中的2台，5台中的3台等），每一笔写事务也必须到达半数以上服务才生效，因此当少数服务器故障时不会有任何数据丢失。
2. 复制组内节点之间采用最终一致性来同步数据，在主副本发生故障时可以快速选举新的副本作为主副本，确保不丢数据，从而保证高可用。SequoiaDB 采用分布式投票，即Raft算法来解决这个问题。Raft算法至少要求三个副本（要求是奇数个副本），一个为主副本，另外两个为备副本，事务要求在主库执行成功并且至少同步到一个副本才可以构成多数派，从而应答客户端。当某个副本出现故障时，分为两种情况。如果是备副本，对系统没有影响；如果是主副本，Raft协议会自动从两个备副本中选择一个作为新的主副本继续提供服务，并通过协商来确保完全不丢失数据。

经过一段时间的学习，对SequoiaDB高可用方面有了比较浅显的了解，还有很多有意思的设计值得关注。今后会继续更新我的学习过程~大家共同进步