微信基于时间序的海量存储扩展性与多机容灾能力提升

作者：jeryyzhang，腾讯 WXG 后台开发工程师

背景介绍

业务场景

作为以手机为主要平台的移动社交应用，微信内大部分业务生成的数据是有共性可言的:数据键值带有时间戳信息，并且单用户数据随着时间在不断的生成,我们将这类数据称为基于时间序的数据。例如朋友圈的发表，支付账单流水，公众号文章阅读记录等。这类基于时间序的数据通常不会删除，而是会随着时间流逝不断积累，相应需要的存储空间也与日俱增：key 量在万亿级别，数据量达到 PB 级别，每天新增 key 十亿级别。同时在十亿用户的加持下，每天的访问量也高达万亿级别。

访问模型

经过数据分析，我们发现基于时间序的存储一般有如下三个特点：

1. 读多写少，这类基于时间序的存储，如果需要访问一段时间内的数据就需要对对应时间段内的所有键值对都进行一次访问。与全部写入到一个键值对的场景相比可以视为读扩散的场景。部分业务场景下的读写比甚至高达 100:1。

2. 冷热分明，这类基于时间序的存储，数据的时效性往往也决定了访问频率。比如对用户进行公众号文章的推荐，用户近期的阅读记录会更加具有参考意义。这就导致数据的访问不是均匀的，而会更集中在最近一段时间所产生的数据。以某业务场景为例，70%以上的访问来自最近一天内的新增数据，90%来自 3 个月内的新增数据。一年外的数据访问占比只有 5%。

3. 数据安全性要求高，这类数据通常是由用户主动产生，一旦丢失，非常容易被用户感知，导致投诉。

现有架构

此前，我们使用一致性缓存层+SSD 热数据层+机械盘冷数据层的分层架构方案来解决此类基于时间序的存储。细节可以参考《微信后台基于时间序的海量数据冷热分级架构设计实践》。

对于冷数据集群，我们使用微信自研的 WFS(Wechat File System 微信分布式文件系统)对其进行了一次升级，极大的简化了运维成本。不过这部分不是本文重点，在此不再详述。

面临挑战

旧架构在过去几年微信后台的发展过程中始终表现平稳，但是也依然面临着一些挑战。

首先是扩展能力方面的挑战。旧架构中，考虑到读多写少的访问模型，为了加快宕机后的数据 catchup 速度，我们使用了细粒度的 paxos group，即每个 key 有一个独立的 paxos group。这样在进程重启等宕机场景下，只有少量写入的 key 需要进行 catchup。理想很丰满，现实很骨感。在 PaxosStore 架构中，数据的扩缩容是以 paxos group 为粒度的。也就是说，对于使用细粒度 paxos group 的存储，进行扩缩容是逐 key 的，耗时可以看成与 key 量成正比；单机百亿级别的 key 量放大了这一问题，即使我们采取一系列的工程优化缩短耗时，整体的迁移周期依然比较长，需要几周时间。

另外一个方面则是来自容灾能力的挑战。PaxosStore 使用 KV64+三园区的部署方式。同一个 key 的三个副本分属三个园区，同一个园区的两台机器服务分片没有重叠，因此可以容忍园区级别的故障。然而对于同组两台不同园区机器故障的情况，则有占比 1/6 的数据只剩余单个副本，无法提供读写服务。

可能有同学会认为，同组两台不同园区机器故障，概率无异于中彩票。然而根据墨菲定律,"凡是可能出错的事情，最终一定会出错"。在过去几年也曾出现过同 Set 两台不同园区机器先后发生故障的情况。

我们都知道，分布式系统的一个核心观点就是基于海量的，不可靠的硬件，构造可靠的系统。那么硬件究竟有多不可靠呢？Jeff Dean 在 2009 年的一次 Talk 中曾经提到过：

PaxosStore 使用 no raid 的磁