需求变更是信息化过程中的家常便饭，而在变更过程中如何尽可能小的影响在线业务是比较头疼的事情。举个车联网监控的例子：原终端设备上传车辆的经纬度数据，新的终端设备支持同时上传速度数据，而旧的车辆状态表数据量超过亿级，此时如果Alter table add column将会造成数据表上锁，导致上传或查询车辆状态数据等待。AppBoxFuture的存储引擎在设计之初也是采用锁表的方案，后来考虑到上述应用场景决定支持online schema change，但带来了另一个难题是如何保证分布式环境下的一致性。

  在权衡了利弊后，作者决定采用如下草图所示的变更方案，主要是考虑工程实现上的便利性。实现的关键点是实体模型内有SchemaVersion标记，在添加删除列、索引、EntityRef引用外键时，SchemaVersion+1, 同时所有表分区的状态机内也有SchemaVersion标记当前的版本，如果变更过程中有旧版本的Insert\Update\Delete命令，则抛出SchemaChanged错误，由上层逻辑加载新的模型后重试。该方案的优点是实现简单，且变更过程对在线业务的影响较小，缺点是变更任务不支持回滚，如遇到网络或磁盘错误则任务会稍候重试（幂等），添加惟一索引例外，遇到主键冲突任务不会重试，改为通知上层删除该索引。
在这里插入图片描述

  作者在虚拟机（I74C8G）内做了个单分区80万行记录添加列变更性能测试，如下动图所示：
在这里插入图片描述
测试结果如下约0.8秒就处理完一个分区80万行记录：

#01/17/2019 11:17:07 [Debug] [StoreService.UpdateModelAsync]: Entity[VehicleState] schema changed, 2 -> 3
MetaAlterTable::TryRunAsTask: 开始提议分区变更任务至68719476742
MetaAlterTable::TryRunAsTask: 分区提议成功68719476742
KVAlterPartion::TryRunAsTask: 分区批次处理完成
MetaAlterTable::TryRunAsTask: all partition done, elapsed time:0.847791s
MetaAlterTableDone::Apply: 移除变更任务, 剩余任务:0
KVAlterPartionDone::Apply: 移除分区变更任务, 剩余任务:0

  如果您有问题或Bug报告，请留言或在Github提交Issue。

版权声明：本文为BaiCai原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/BaiCai/p/10284611.html