我们在 仿微博消息中心的系统设计与实现 一文中，介绍了一个类似于微博、网易云的消息中心模块的设计和实现思路。今天跟大家介绍一下我们的实现后升级数据时踩的一些坑。
本次考虑到消息中心的数据量会比较大，所以持久层使用了阿里的 TableStore（简称：ots）。在实现上，则使用了阿里提供的 TimeLine 封装。
如果你是从 0 到 1 搭建消息中心的话，该封装基本上够用。但如果你同我们一样，不是从 0 到 1，需要考虑旧数据迁移的话，那我建议你还是要慎重。如果数据量不是大到迫不得已，我还是建议你优先使用关系型数据库结合 nosql 的产品去实现。
接下来我们一起来看看升级过程可能碰到的一些坑，如果你也有一样的场景，欢迎一起讨论。
坑一：升级效率较低，迁移方案的开发较繁杂。由于使用了 TimeLine，迁移时，只能使用 TimeLine 的 sdk 去同步写（异步写，可能会乱序）。这就导致了升级时间会被拖长。如果数据量大的时候，这个迁移过程，就是个很大的问题。
坑二：如果之前的消息存在不同表结构中，然后现在希望表 A 和表 B 的点赞消息合并到一个时间线中，我们只能自己先将表 A 和表 B 的数据合并，然后再做升级。由于数据量都较大，这个合并的难度较大，耗时较长。
坑三：由于 TimeLine 中的 sequenceId 是自增列。也就是说 sequenceId 是插入 ots 后，由 ots 自动产生。那么就导致，我们一旦升级失败，我们无法重复升级。我们能做的有三种。1.记住失败的地方，然后从该处接着升。 2.遍历查询已升级的数据，然后批量删除（ots 的限量删除限制 200 笔），这种删除方式可以想象写起来有多蛋疼。 3.直接删库重建，但如果已经升级了 90% 的数据了，这个时候去删库，显然不是一个很好的选择。不管是哪种方式，其实风险都是比较高的。
坑四：如果是 2B 的企业往下看，不是的话可以跳过本段。其实这个是对坑三的补充，由于在 ots 没有库的概念，所以我们只能在一张表里去存所有租户的数据。如果某个租户升级时异常了，部分用户升级一半数据，我们会比较难处理。如果删数据重升的话，删除某个租户的数据又不好删（只能遍历删除，做法低效）。如果不删数据，使用 TimeLine 又无法重复升级。这个问题暂时无解。
关于 TimeLine 升级过程的这些坑，我们自己也无解，后续考虑不再使用 TimeLine 封装。大家如果有碰到一样的场景或类似的问题，欢迎留言讨论！！
关于 TableStore 和 TimeLine 封装，推荐几篇文章，感兴趣的可以去了解一下。
