微信后台基于时间序的海量数据冷热分级架构设计实践
1. 数据量大：PB 级数据，万亿级键值，并且在源源不断的生成中，然而新生成的数据相较于历史存量数据占比小。下图展示了该集群数据在各时间段的一个占比情况
2. 访问量大：峰值可达每分钟数十亿次访问，尤其是在节日期间，用户高涨的热情更可以转化成平日三至五倍的访问量。同时具有冷热分明、读多写少 (读写比例甚至可达 100：1) 的访问特征，比如节日期间倍增的访问通常是对节日期间生成的新增数据的访问。下图展示了该集群访问在各时间段的一个占比情况；
3. 数据安全性要求高：这类数据通常是用户感知敏感数据，一旦丢失，转化成的用户投诉率高。
从客户端的角度看，三层都是并列的，客户端都会直接的与某层中的某台机器发生通信。具体的区别点在于，内存层和机械磁盘层对客户端而言是只读的。所有的写都是由客户端直接写向存储层。我们将去中心化的配置分发到客户端机器上，配置的类型包括内存层路由、存储层路由以及其它元数据，客户端根据配置中的时间分隔点以及流量比例，来决定将当前的读请求分发到内存层还是存储层的具体机器上。配置支持快速分发和动态加载，可以在秒级实现更新。
机械磁盘层的路由对客户端而言是透明的，存储层保存了下沉到机械磁盘层的数据链接，链接包含了文件编号、内部偏移和大小，而客户端对此是不知情的。当已下沉数据的读请求分发到存储层机器上时，存储层会计算出该数据各副本在冷数据存储层对应的机器地址，然后将它和文件链接一起回复给客户端。客户端再按照随机的策略在多副本之间选择一份读取，从这个角度看，冷数据存储层对客户端而言更像个远程文件系统，而 inode 信息和路由表是放在热数据存储层的。
3 内存层
内存层从表现上更像是一个缓存代理，然而普通的缓存在处理数据有效性上是乏力的。常见的策略如写时淘汰，每次写存储层之前，都先清理掉缓存中相应的数据，确保失效。然而数据在缓存中通常也是多副本的，这个方案即无法处理网络分区错误，并且写时淘汰也会产生多次 RPC 请求，过份的消耗系统资源。另外一种常见策略是有限的数据一致性，即过时淘汰的策略。在将数据写入缓存时，会附带一个有效时间，在这个有效期内，该数据一直被认为是正确的，并不关心真实情况是如何的。这种缓存只能应用于对数据实时性要求不高的服务。对微信的敏感业务而言，我们更需要能保证数据强一致的分布式缓存。
我们通过版本号来实现了这一目的。我们为缓存中的每一份数据都维持了一份版本号，存储层中相应的也有一份。只有当缓存中的版本号与存储层的版本号达到一致时，才会认为缓存中的数据是有效的。所以，客户端每次对内存层的读请求，都会由缓存层相应的产生一次读请求发到存储层。在一次 RPC 请求中完成有效性的识别以及过期数据的更新。
直觉上看，采用这种方案的强一致缓存并没有降低存储层的访问压力。因为客户端对缓存层的请求，与缓存层对存储层的请求是 1：1 的。然而这个方案点的关键在于，我们成功的疏解了存储层的内存瓶颈。将存储层缓存数据的功能，转移到缓存层的内存上。我们现在对存储层的要求就是能够尽量的缓存更多的版本号，提供高效的版本号访问能力就可以了。从这种意义上来看，这个强一致性缓存就是存储层内存的延伸。因此，我们将它称为内存层。它的优势在于可动态的调整流量比例，并且可以在访问高峰期快速的扩容。后面的章节我们也描述了如何通过工程手段优化版本号交互带来的资源消耗。
为了系统的健壮性，一些异常情况也是需要考虑的，如果一台内存层机器突然离线，会有数十 G 的缓存数据失效，我们当然不会希望这数十 G 数据的压力，会全部的落到一台存储机器的磁盘上。――这无疑会引起系统的抖动。因此，我们按照组的方式来部署了内存层。每组有多台机器。一份数据可能在这多台机器内有多个副本。客户端通过随机的次序访问这些机器。这样就尽力避免了单结点失效对整个系统的影响。
我们在内存层中设计了简单、轻量的支持变长数据的缓存结构。每台机器包含数十条 LRU 链，每条链都是一个共享内存形式的一维数组。所有的数据都追加写在数组的最新位置，到尾部后就从头开始循环。自然，这样的结构需要一个索引来记录数据的位置。这种方式固然浪费一些内存空间，但避免了内存的动态分配。
由于机械盘容量大、计算能力差，我们采用 NO RAID 的方式组织了盘组。为了更好的实现单盘失效导致数据丢失的故障的灾后恢复，我们实现了同组三台机器在盘级别数据的完全相同。为了达到盘级别的负载均衡，我们通过预计算路由、硬编码的方式，实现了 (数据 ->机器 ->盘 ->文件) 的单调映射，由数据的键值可以直接定位到盘的索引以及文件的编号
