RocksDB 在 vivo 消息推送系统中的实践

一、背景

在消息推送系统中，业务方服务器通过调用推送接口向 VPUSH 服务发送消息，请求中会包含一个 registerId，用于标识接收该消息的用户设备。当 VPUSH 服务接收到推送请求时，会使用 registerId 找到对应的用户，并将消息推送给其手机。然而，在 VPUSH 内部处理消息推送时，需要使用一个内部标识符 ClientId 来标识每个用户的设备，可以通过 ClientId 查找到对应的设备信息。

因此，系统中引入了一个映射存储服务 MappingTranformServer（后文简称MT），用于处理 registerId 和 ClientId 之间的转换。MT 服务缓存了所有用户的设备标识符，使用 RocksDB 作为底层存储引擎，RocksDB 可以提供高并发读写能力，以磁盘作为存储介质，节省存储成本。当 VPUSH 服务需要将 registerId 转换为 ClientId 时，会向 MT 服务发起查询请求，MT 服务根据请求中的 registerId 查找对应的 ClientId 并返回，这样系统下游节点就能够通过 ClientId 找到对应的设备，并将消息推送到用户手机上了。

系统中除了 registerId 以外，还有许多其他的标识符，所以引入了 ClientId 来降低后期维护和开发的成本。由于regId 比较有代表性，下文中主要会以 regId 进行举例讲解。

二、RocksDB 原理介绍

在介绍业务场景之前，先简单介绍一下RocksDB的基本原理。RocksDB的前身是LevelDB，由于LevelDB不支持高并发写入，Facebook(Meta)针对于LevelDB的一些痛点进行了改造，便有了RocksDB。RocksDB相比于LevelDB，其支持高并发读写，优化了SST文件布局，提供了多种压缩策略，总的来说，RocksDB 在继承了 LevelDB 的全部功能的基础之上，还针对内存和磁盘数据存储进行了优化，使得 RocksDB 具有更高的吞吐量和更低的延迟，更适合分布式、高可靠性的存储场景。行业内也有许多数据库将RocksDB作为底层的存储引擎，比如 TiDB。

2.1 LSM设计思想

在介绍RocksDB的架构和原理之前，先来了解一下其设计思想：LSM。

LSM全称为log-structured merge-tree。LSM并非一种数据结构，而是一种设计思想，最根本的目的就是要规避对磁盘的随机写入问题，提升写的效率。其思路如下：

写入顺序：从内存到磁盘

• 将数据先写入到内存中。
• 随着内存存储数据越来越多，达到内存阈值，则会将内存中的数据转移到磁盘中。
• 磁盘中数据也分为多层，其中L0层的数据最热，而最冷的数据分布在Ln层，且会定期进行合并操作。

LSM 在 RocksDB 设计中的体现：