MatrixCube揭秘101——MatrixCube的功能与架构

作为分布式存储系统，除了通过强一致的副本复制机制保证高可用性以外，我们还应该尽可能多地将多台机器的资源利用起来，以达到更高的使用效率。一个合格的分布式存储应该让每个节点之间的存储压力大致相同，同时对每个节点的访问压力大致相同，不至于在某些节点上面临过大的存储或者访问压力，这样整个系统的性能就会因此受到影响。而MatrixCube就具备这样的调度与自动均衡能力，可以在多节点间保持存储与负载的均衡，并且在节点发生变化时进行存储与访问负载的调度，以达到重新平衡。

MatrixCube提供相当灵活的用户自定义能力。MatrixCube不限制单机的数据存储引擎，并且定义了DataStorage接口，任何实现DataStorage的存储引擎都可以接入MatrixCube。而且MatrixCube支持自定义的读写请求，使用者只需要实现这些请求在单机上的逻辑，分布式相关的细节全部交给MatrixCube。因此用户可以非常方便地接入各种不同的单机存储引擎，以及自定义各种不同的读写请求命令。

我们需要先了解一些概念来帮助我们更好地理解MatrixCube：

• Store：MatrixCube是一个分布式存储的框架，所以我们的数据会存放在很多的节点上，我们把集群中的一个节点称为一个Store。

• Shard：数据在MatrixCube集群中是分片存储的，每个数据分片我们称之为一个Shard。一个Store中可以管理多个Shard。

• Replica：为了保证存储服务的高可用，每个Shard的数据是存储多份的，并且分布在不同的Store上，Shard的一个数据副本我们称之为一个Replica。所以一个Shard会包含多个Replica，每个Replica中的数据都是一样的。

• Raft-Group：通过多副本我们保证了数据的高可用，为了保证数据的一致性，我们采用Raft协议来做数据共识，一个Shard的多个Replica会组成一个Raft-Group。

• DataStorage：使用MatrixCube就必须要定义一个DataStorage，用来存储单机数据。我们需要针对存储服务的特点来设计对应的DataStorage。MatrixCube默认提供了一个完整的基于KV的DataStorage，因为基于KV的存储可以满足大部分的场景。

• Prophet：Prophet是一个调度模块，主要职责是负责Auto-Rebalance以及维持每个Shard的Replica个数。每个Store以及Shard的Leader Replica都会定期上报心跳信息给Prophet，Prophet会根据这些信息来做出调度决定。MatrixCube需要在集群中指定哪些节点承担调度的职责。

• Raftstore：Raftstore是MatrixCube最核心的组件, 其中实现了Store，Shard，Raft-Log相关的元数据存储，对Multi-Raft协议的支持，全局路由表的构建以及每个节点上的读写Shard Proxy代理功能。

图-MatrixCube整体架构

a) 系统启动与配置

在系统初始化的时候，MatrixCube会根据集群中每个节点的配置文件来进行初始化。在MatrixCube中，一共有两种类型的节点，一种是调度节点，也就是Prophet节点，另一种是数据节点，只存数据，没有调度功能。两种节点之间目前无法互相转换，都是在系统初始化的时候指定好的。MatrixCube的最初三个节点必须都是Prophet节点，这也是MatrixCube所能组成的最小规模集群。Prophet的三个节点构成一个Raft-Group，其中会选举出一个leader，所有的调度请求与信息上报都会到这个Prophet Leader上。Prophet的节点数可以进行配置，但是以Raft协议为基准，必须是2*N+1个节点（N为不小于0的整数）。

在系统开始启动运行之后，用户开始往系统中导入数据。MatrixCube在初始化时已读入一个数据分片Shard的大小配置，比如1GB一个Shard。用户写入数据还没有达到1GB的时候，会持续写入同一个Shard，而同时每次写入的数据会同步在三个节点中更新Shard，这三个Shard会构成一个Raft-Group，其中也会选举出一个Leader，对这个Shard的读写请求与信息上报全部会由这个Leader来处理。直到一个Shard达到1GB时，此时MatrixCube会启动Shard分裂机制，也就是把一个Shard均匀拆分成两个Shard，也就是1个GB的分片变成了2个500MB的分片，而这个过程是同步在三个节点中发生的，也就是说同时将生成6个Shard，而他们将组成新的2个Raft-Group。

用户以接口的形式与MatrixCube交互，从而来发起对数据的读写请求。由于Raft-Group的存在，只有每个Raft-Group的Leader才能响应读写请求。而用户的请求可能并不一定直接指向Raft Group Leader，因此我们就需要一个路由机制，来让用户的请求能被正确的转到它该去的地方。因此每个节点上都会有一个Shard Proxy，这些Proxy会定期接收Prophet给它的全局路由表。我们前面提到Prophet会接受各个Store与各个Shard的Leader给的心跳信息，因此Prophet是有一张全局的路由信息表的。这个时候Shard Proxy就会知道用户请求读写那份数据应该在哪个Store的哪个Shard中。这样的话用户无论向集群中哪个节点发起读写请求，最终得到的结果都是一样的，用户不需要关心Shard在内部存在什么地方。

图-Shard Proxy对用户请求的转发

在整个集群发生节点变化时，比如集群需要扩缩容，或者出现机器或者网络故障的时候，我们就要进行集群的调度。通常来讲，我们的Prophet会有一个超时机制，在某个节点超过我们规定的时间没有心跳上报的时候，我们这时就认为这个节点已经下线，我们将开始数据搬迁流程。在节点减少的情况下，Prophet会检测到一部分Shard没有足够的Replica组成一个完整的Raft-Group，这时就需要在现有的节点中找到存储空间比较富余的节点，在其中创建这一部分Shard的Replica。而在节点增加的情况下，Prophet会发现多出的节点存储空间比较富余，这时会将集群中的一部分Shard进行重新分配，以达到一个各节点相对均衡的状态。在节点变化的时候，除了Prophet会进行调度意外，每个被破坏的Shard组成的Raft-Group也会视情况进行调度，如果少了Raft-Group的follower，那在完成Shard的新Replica生成后会重新组成完整的Raft-Group；如果少了Raft-Group的Leader，那剩下的两份Replica就会先选举出新的Leader，再去新的节点上完成Replica与Raft-Group的生成。

很多社区的小伙伴在之前都接触过TiDB分布式数据库的架构，以及其中负责提供分布式能力的组件TiKV以及负责调度的模块Placement Driver。实际上MatrixCube的功能基本相当于TiKV与PD的结合，MatrixCube除了还在开发中的分布式事务能力以外，其他的高可用，强一致以及调度的能力与TiKV+PD基本保持一致。