(五) MdbCluster分布式内存数据库——数据迁移架构及节点扩缩容状态图

(五) MdbCluster分布式内存数据库——数据迁移架构及节点扩缩容状态图

 

上一篇：(四) MdbCluster分布式内存数据库——业务消息处理

　　

　　本节主要讨论在系统扩容期间的数据迁移架构及节点的状态图。我们将通过介绍这两部分，慢慢展开复杂的扩缩容流程。

　　下图从左到右，我们增加了ClusterManager进程及容器。ClusterManager进程的作用在于接到前台界面发来的扩缩容指令后，根据指令生成新的slotlist分布图，及其对应的迁移计划。所谓迁移计划： { slot: 1003, from: 1, to: 3 } 表示将编号为1003的slot数据，从节点1迁移到节点3。并将迁移计划发给节点3的MdbRedux。MdbRedux根据迁移计划分别控制节点1和节点3的MdbAgent的状态，以控制迁移过程中slot:1003 数据的可读不可写。并且MdbRedux给本节点的DataMigration发送数据迁移命令，执行slot:1003 数据从1迁移到3的步骤。最后，MdbRedux还要负责更新所有节点的slotlist数据。MdbAgent则给所有的client推送更新。

　　

　　问题：1、为什么DataMigration没有通过MdbAgent，而直接通过MdbRWNode操作数据。主要是为了性能考虑。迁移过程中涉及批量的数据操作，直接通过MdbRWNode进行可以更快的完成。并且避免挤占MdbAgent的正常业务消息通道，影响迁移过程中的正常业务消息。另外，我们减弱了迁移过程中批量数据操作的部分校验工作。也是为了更快的完成迁移，避免影响在线业务。

　　2、为什么MdbRedux和DataMigration没有部署在单独容器，而是每个数据节点都有。关于这点主要考虑并行迁移。执行计划可能包括from:1, to:3; from:2 ,to:4;  这时，ClusterManager就可以同时给节点3，4分别发送迁移计划。两部分迁移可以并行进行。

　　

　　在MdbCluster的开发过程中，我们发现数据节点的状态管理是至关重要的。不同状态下，数据节点对于外部请求的响应会有不同。一个完整的状态图可以保证系统节点在不同状态下的正确运行。下面就是一对主备节点的扩缩容情况下的状态图。

 　　如上图所示：

　　1. 一对主备节点以OFFLINE的状态启动，启动完成后为ONLINE的状态，此时并为加入集群。

　　2. 主节点经过MIGRATING状态，进行扩容操作，变为ACTIVE状态，加入集群，正式作为主节点承接业务消息。备节点则为STANDBY状态，加入集群，从主节点实时同步数据。　　　　　　　　       

　　3. 当主节点出现故障后，备节点立刻转为ACTIVE状态，承接业务消息。

　　4. 故障节点转为RECOVERED状态开始恢复过程。恢复过程包括重建数据库，从主节点同步数据。恢复完成后，节点转为STANDBY状态，做为备节点加入集群，从主节点实时同步数据。

　　5. 在进行缩容操作时，主节点转为MIGRATING状态，进行数据迁移。备节点从主节点实时同步数据。

　　6. 迁移完成后，主备节点均转为ONLINE状态。脱离集群。

　　7. 容器退出后，主备节点为OFFLINE状态，以备下次启动。

　　8. 在集群中的业务节点初次启动时，则从中间状态进入。