Facebook 迁移 Messenger 底层存储的过程

1. 背景

Facebook Messenger 用户超10亿，可以即时分享文字、图片、视频，产品自身不断的发展，背后的系统也在不断改变，开始是一个单体服务，后来变为有专门的缓存服务支持读、Iris 系统来队列化写、存储服务来保存历史消息。

为了更好的提升 Messenger 的用户体验，Facebook 对底层存储进行了本质性优化，主要包括：

• 重新设计并简化了数据 schema
• 从 HBase 改为 MyRocks（Facebook 开源的一个MySql存储引擎）
• 把存储介质从旋转式磁盘改为最新的闪存

结果带来了更好的用户体验，也提高了系统灵活性，减少了延迟，减少了存储的消耗，升级过程是无缝的，没有停机。

2. 大规模迁移的挑战

MyRocks 可以带来很多优势，例如：

1. 可以应用 Facebook 的开放式计算项目
2. 可以使用闪存
3. 更好的使用 Facebook 成熟的 MySql 运维管理经验
4. 可以减少物理数据节点的数量，并获得更好的可用性

存储系统的迁移是必要的，但 HBase 中数据量巨大，而且迁移过程中不能影响 Messenger 系统的运行。

迁移过程需要对 HBase 集群进行读取，这对产品来讲是个额外的负载，如果迁移动作过猛，会严重影响 HBase 的性能，甚至产生错误，影响用户体验。

迁移涉及的数据量非常大，是 PB 级别的，而且因为修改了数据 schema，必须仔细分析现有数据、处理大量的遗留数据、解决冲突，以保证用户看到和之前一致的数据。

所以，如何不影响10亿用户实现无缝迁移是个有趣的挑战。

3. 迁移方案

Facebook 设计了2个迁移流程，一个是正常流程，用于处理 99.9% 的账户，另一个流程用于处理剩下的特殊账户。

迁移过程会进行严格的数据验证，提前准备好回退方案，并做好检查工作，保证没有漏掉任何一个账户，当一切都没有问题后，老系统下线。

3.1 正常迁移流程

迁移前后的数据必须是强一致的，迁移一个账户时有一个前提假设：迁移过程中，此账户没有数据写入。

为了保证这点，定义了状态机制和监控工具，当迁移开始时，会记录下来此账户在旧系统中数据的最后位置，然后把数据迁移到新系统，完成后，检查旧系统中数据的最后位置是否变化，如果没变，此账户在新系统就可用了，开始新旧系统双写，否则，此账户迁移失败，清除新系统的数据，等待下一次的迁移工作。

在双写阶段，迁移器会执行双重验证：

（1）数据验证

确认 HBase 和 MyRocks 中的数据是匹配。

（2）API验证

在读取数据时同时从两个系统中一起读，然后比较结果数据是否一致。

如果数据验证发现了问题，就进行回退，继续从旧系统读数据，清除新系统中的数据。

3.2 使用缓存迁移流程

有些账户比较特殊，比正常的账户要大很多（例如企业的客服机器人账户），不能使用正常的迁移流程，所以设计了缓存机制。

在某个时间点对账户数据进行快照，保存快照到缓存中，然后把缓存中的数据迁移到 MyRocks。

迁移过程中有新的写操作怎么办？Iris 会对写操作入队（Iris 可以使数据在队列中保存数周，支持海量数据的写入），当缓存中的数据迁移完成后，新系统从 Iris 队列中消费积累下来的写操作，消费完成后，就追赶上了旧系统，两个系统就一样了，之后的流程与正常迁移流程相同。

4. 迁移后的好处

• 存储空间

简化后的数据 schema 使存储空间大大减少，而且因为 MyRocks 和 HBase 架构的不同，使得用于复制的资源减少了一半，所以，总体来看，存储上的消耗减少了90%。

• 延时

MyRocks 在读和写都进行了优化，并且使用了闪存，在数据延迟上比旧系统减少了50倍，用户可以感知到，例如回看旧消息时快了很多。

• 维护成本

相比于 HBase，MyRocks 在 Facebook 更加成熟，有更加智能的机制来处理灾难恢复，不需要人工的操作。

• 对产品的支持

新系统的架构和性能也使得产品更容易添加新特性，例如移动消息内容搜索，之前使用 HBase 时较难实现，在新系统中就比较容易。

以上内容翻译整理自Facebook官方文章

https://code.fb.com/data-infrastructure/migrating-Messenger-storage-to-optimize-performance