Apache IoTDB 分布式架构三部曲（三）副本与共识算法

IoTDB 首创并应用的共识协议统一框架，为用户提供了灵活选择不同共识算法的可能性。

对于一个分布式集群而言，为了使得海量数据场景下集群能够横向扩展，集群需要按照一定的规则将全部数据分成多个子集存储在不同的节点上，从而能够更加充分地利用到集群中各个节点的存算资源。对于集群中的任何一个分片而言，为了满足高可用的需求，需要将数据在多个物理节点上冗余存储多个副本，进而避免单点故障的出现。

由于同一份数据有多个副本，可能会出现不同副本间数据不一致的现象。现有的分布式系统一般通过共识算法来处理多个副本间的数据一致性问题。

然而，不同的业务场景对共识算法的一致性、可用性等要求不同。比如对于应用监控场景，Google 的时序数据库 Monarch 就明确指出对于监控场景的时序数据其会更关注可用性而不是一致性。不过对于数据分区等关键元信息，其依然使用了保证外部一致性的 Spanner 数据库进行管理。

对于专为物联网场景而生的分布式时序数据库 IoTDB 而言，针对时序数据，往往可以根据场景选择可用性更好的共识算法；而针对分区信息和元数据等核心信息，往往可以选择一致性较强的共识算法。

本文将从共识算法讲起，深入解析 IoTDB 对于共识算法一致性、可用性和性能等方面的选择与取舍，并介绍 IoTDB 独有的共识算法框架，帮助您理解并掌握 IoTDB 的多种共识策略，从而根据您的业务需要对共识算法进行灵活的选择与配置。

01

共识算法

（1）为什么需要共识算法

前面一期（分布式架构三部曲（二））提到，分布式系统通过将数据进行分片，并在多个物理节点冗余存储为多个副本的横向扩展方式来提升系统整体的可用性和性能。IoTDB 采取横向扩展的分布式架构，如下图所示。

尽管分布式系统的多副本设计大大增加了系统的可用性和性能，但这种横向扩展的思路也给系统带来了挑战，例如：

• 不同副本如何保证数据是一致的？

• 不同副本同时接收不同的写入，以谁为准？

• 一个节点挂掉后，如何在其他节点恢复上面的副本？

• 查询哪个副本的数据会更好？

共识算法即为解决上述挑战而设计的机制。让对外的用户既能享受到高可用和性能，也感知不到多副本的存在。

（2）共识算法的概念与分类

共识算法是分布式系统中的一种关键机制，用于在多个参与节点之间达成一致决策，即使在存在网络延迟、节点故障或恶意攻击的情况下，也能确保系统的一致性和可靠性。在分布式系统中，各个节点的副本可能存在不一致状态，而共识算法的目标就是确保所有节点最终达成一致，形成一个统一的决策，从而维持系统的整体一致性。

共识算法经过近半个世纪的发展，种类繁多，流程复杂。不同的共识算法的复制模式和一致性级别往往不同。一般来说，我们可以根据共识算法的复制模式和一致性保证对其进行分类。

根据共识算法的复制模式，可以将共识算法分为三个大类别：

• 单主复制：客户端将所有写入操作发送到单个节点（主库），该节点将数据更改事件流发送到其他副本（从库）。读取可以在任何副本上执行，但从库的读取结果可能是陈旧的。

• 多主复制：客户端将每个写入发送到几个主库节点之一，其中任何一个主库都可以接受写入。主库将数据更改事件流发送给彼此以及任何从库节点。