IM 架构设计06

微信后台基于时间序的海量数据冷热分级架构设计实践

1. 数据量大：PB 级数据，万亿级键值，并且在源源不断的生成中，然而新生成的数据相较于历史存量数据占比小。下图展示了该集群数据在各时间段的一个占比情况

2. 访问量大：峰值可达每分钟数十亿次访问，尤其是在节日期间，用户高涨的热情更可以转化成平日三至五倍的访问量。同时具有冷热分明、读多写少 (读写比例甚至可达 100：1) 的访问特征，比如节日期间倍增的访问通常是对节日期间生成的新增数据的访问。下图展示了该集群访问在各时间段的一个占比情况；
3. 数据安全性要求高：这类数据通常是用户感知敏感数据，一旦丢失，转化成的用户投诉率高。

从客户端的角度看，三层都是并列的，客户端都会直接的与某层中的某台机器发生通信。具体的区别点在于，内存层和机械磁盘层对客户端而言是只读的。所有的写都是由客户端直接写向存储层。我们将去中心化的配置分发到客户端机器上，配置的类型包括内存层路由、存储层路由以及其它元数据，客户端根据配置中的时间分隔点以及流量比例，来决定将当前的读请求分发到内存层还是存储层的具体机器上。配置支持快速分发和动态加载，可以在秒级实现更新。

机械磁盘层的路由对客户端而言是透明的，存储层保存了下沉到机械磁盘层的数据链接，链接包含了文件编号、内部偏移和大小，而客户端对此是不知情的。当已下沉数据的读请求分发到存储层机器上时，存储层会计算出该数据各副本在冷数据存储层对应的机器地址，然后将它和文件链接一起回复给客户端。客户端再按照随机的策略在多副本之间选择一份读取，从这个角度看，冷数据存储层对客户端而言更像个远程文件系统，而 inode 信息和路由表是放在热数据存储层的。

3 内存层

内存层从表现上更像是一个缓存代理，然而普通的缓存在处理数据有效性上是乏力的。常见的策略如写时淘汰，每次写存储层之前，都先清理掉缓存中相应的数据，确保失效。然而数据在缓存中通常也是多副本的，这个方案即无法处理网络分区错误，并且写时淘汰也会产生多次 RPC 请求，过份的消耗系统资源。另外一种常见策略是有限的数据一致性，即过时淘汰的策略。在将数据写入缓存时，会附带一个有效时间，在这个有效期内，该数据一直被认为是正确的，并不关心真实情况是如何的。这种缓存只能应用于对数据实时性要求不高的服务。对微信的敏感业务而言，我们更需要能保证数据强一致的分布式缓存。

我们通过版本号来实现了这一目的。我们为缓存中的每一份数据都维持了一份版本号，存储层中相应的也有一份。只有当缓存中的版本号与存储层的版本号达到一致时，才会认为缓存中的数据是有效的。所以，客户端每次对内存层的读请求，都会由缓存层相应的产生一次读请求发到存储层。在一次 RPC 请求中完成有效性的识别以及过期数据的更新。

直觉上看，采用这种方案的强一致缓存并没有降低存储层的访问压力。因为客户端对缓存层的请求，与缓存层对存储层的请求是 1&#