分布式架构下如何选择最佳 Store？

一、背景

开务数据库是一款云原生分布式数据库，基于分布式架构特点其存储数据默认有 3 份，分别存储在各节点下的不同 Store 中。在多节点多 Store 的情况下，如何选择存储数据的 Store 就显得尤为重要。

开务数据库中通过特定算法，根据 Store 的存储容量、磁盘介质以及每个 Store 的 QPS 等综合因素，计算出最佳的 Store 以完成数据存储，我们把这个过程称之为 Store 的 Rebalance。但是此过程从集群初始化就持续地进行，因此将会带来 2 大问题：

1）在数据量很大的情况下，如果从初始即进行 Store Rebalance，那么就会严重影响性能；

2）如果存放数据的磁盘出现问题则需及时更换，那就意味着需暂停集群服务，等待更换完毕之后才能重启服务。

为此，开务数据库研发了 Store 的禁用启用功能，接下来为大家详细介绍具体的设计思路。

二、设计思路

针对第 1 个问题，我们需要通过特定手段，在特定时间控制 Store 的行为，使它参与或不参与 Rebalance。这样即可实现在业务繁忙的场景下，禁止 Store 参与正常的 Rebalance，避免性能消耗；等到空闲时段，再启用 Store 进行 Rebalance。

至于第 2 个问题，我们仅需禁用出现问题的 Store，再将该 Store 上的数据全部迁移到其他可用的 Store 上，从而完成不停机磁盘更换操作。

三、总体设计

Store 的禁用启用功能主要作用于 Rebalance，因为 Rebalance 是在 Store 级别上的，所以该需求可以转换为加入节点后，不会将集群中其他 Store 上的数据副本迁移到加入集群节点上挂载的 Store 中。

在启动命令上给挂载 Store 加一个属性 STATE（DISABLE/ENABLE）用来表示该 Store 此时的状态；然后在进行 Rebalance 时将属性 STATE 为 DISABLE 的 Store 全部过滤掉，仅留下 ENABLE 的 Store 进行 Rebalance。这样的做法可以避免 STATE 为 DISABLE 的 Store 参与 Rebalance 。

在用户空闲的时间段，通过 Update 命令将该 Store 的 STATE 变为 ENABLE，使得该 Store 重新加入 Rebalance，这样即可完成控制 Store 的 Rebalance。此外如果想要完成更换磁盘操作，我们需要将该 Store 上的副本全部都转移到其他 Store 上，转移完毕后更换该 Store 则不会对业务造成影响，如此便可实现禁用和启用 Store。

四、逻辑架构

执行命令启动节点时，通过命令解析获取 STATE 值，将解析到的 STATE 值保存在存储层，之后根据存储层记录状态完成 Store 的初始化，使得该 Store 中包含命令中的 STATE 属性。

副本层在进行 Rebalance 时，会从现有的 Store 中根据选择一批 Store 组成一个 List，在这里需增加一个约束：过滤掉 STATE 值为 DISABLE 的 Store，即可获取到由用户控制的 List，如此便可实现手动控制 Rebalance。

在执行 Update 命令时，根据 STATE 值来完成存储层初始化的 STATE 值修改，修改的值为 Update 命令中解析出来的 STATE 值。这样即可改变 Store 的 STATE 状态，之后通过节点之间的通信方式来广播到其他的 Store，使得其他的 Store 获取到该节点最新的 STATE 值。

副本层由于该 Store 的 STATE 值为 ENABLE，所以不会受到新加约束限制，从而使得该 Store 可以重新加入 Rebalance 的 List。至此，即可完成由用户控制在特定时间完成特定 Store 的 Rebalance。将 STATE 值为 DISABLE 的 Store 按照节点退役的逻辑来进行配置，转移走该 Store 上的所有副本，即可完成磁盘更换的操作。

五、功能介绍

Store 的禁用启用功能在启动数据库集群时，需要在启动命令中添加"--STATE"参数来控制该节点 Store 的初始化状态。如果是 DISABLE，那么该 Store 从刚开始就不会参与 Rebalance。

在集群运行过程中，我们也可以使用"Store STATE"的命令来随时修改特定的 Store 状态。修改成功之后，该 Store 即可参与或不参与 Rebalance。

六、总结回顾

开务数据库为了提升数据多备份性能，实现不停机更换磁盘操作，设计开发了 Store 的禁用启用功能。通过修改 Store 的状态来控制该 Store 是否参与 Rebalance，从而解决上述 2 大问题，丰富了分布式数据库的使用场景，大幅提升可用性。