海量存储扩展性与多机容灾能力提升

挑战：

1. 单机百亿级别 key 量，10TB 级别数据，如何快速扩容?
2. 如何低成本的提升系统的容灾能力，使之容忍任意双机故障?
3. 磁盘故障，数据清空后如何快速恢复。
4. 作为一款十亿月活的国民 APP，对其进行改造无异于给一架正在飞行的飞机更换发动机，改造过程稍有不慎都可能招致用户投诉，甚至上个热搜。

接下来我会针对这几个难点逐一展开，介绍我们的解决思路与方案。

百亿级别 key 如何实现快速扩容

对于细粒度的的 paxos group，迁移过程中，扫 key，迁移，校验等步骤都是逐 key 粒度的。这会产生大量的磁盘 IO 与 CPU 消耗，导致迁移速度上不去，需要几周才可以完成迁移。

那么我们能否可以采取粗粒度 paxos group 以加快迁移呢?答案是肯定的。对比细粒度的 paxos group，单个粗粒度的 paxos group 可以同时保证多个 key 的内容强一致。因此迁移校验等过程中，可以减少大量的 paxos 交互。然而粗粒度 paxos group 的存储，与细粒度 paxos group 的存储相比，在迁移过程中对目标集群的写入不会减少，总体依然涉及了大量数据的腾挪。而由于 LSMTree 存储引擎存在的写放大问题，数据大量写入目标机这一过程会成为瓶颈。总体来看，扩容时间可以缩短为原来的 1/2 甚至 1/3，达到天级别的水平。

看起来相比细粒度 paxos group 的迁移已经有很大改进，我们能否更进一步?首先我们分析一下在什么场景下需要扩容，一般来说是以下两个场景：

1.由于数据增加，磁盘容量达到瓶颈

2.由于请求增加，CPU 处理能力达到瓶颈

对于情况 1，如果我们使用分布式文件系统替代本地文件系统，当容量达到瓶颈时只需要增加分布式文件系统的机器就可以实现容量的快速扩容，对上层应用而言相当于获得了一块容量可以无限增长的磁盘。对于情况 2，采用计算存储分离结构后。计算节点无状态，不涉及数据腾挪，自然可以实现快速扩容;如果是存储层节点 CPU 瓶颈，也可以通过文件块级别的腾挪来实现快速扩容以及热点打散。

应用计算存储分离的思路，我们基于 WFS(微信分布式文件系统)以及微信 Chubby(分布式锁)，实现了一套计算存储分离的存储架构，代号 I

（编辑：四平站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!