分布式存储随笔三

今天我们聊聊分布式系统的扩容问题。

首先我们需要看到无论分片，分裂，迁移，故障检测和恢复以及系统扩容其背后都有一个无奈叫：不得已。我想对于一个系统具备扩容的能力，如果不是不得已谁愿意没事扩容玩玩呢？估计应该没有人愿意这么干，说明扩容是一个代价很高的能力，不到不得已的地步，一般没有人愿意这样做，但是系统必须具备这样能力，因为很多时候受限于开始阶段对数据容量的评估偏差，成本，以及应对极端情况（比如大促，秒杀等场景），我们的系统必须具备这种能力才能有的放矢，从容不迫，谈笑风生。

分布式存储系统的扩容是一个综合的过程，期间伴随着分片分裂，数据迁移，元数据管理等一系列复杂操作的组合。这里需要补充一点就是当我们认为一个系统应该扩容了，这个条件是什么，什么情况下应该扩容了。一般而言有两种场景（很多时候也会同时出现），一种是系统的容量达到一个警戒值，一种是系统的访问压力达到一个警戒值。但并不是说只要一旦达到警戒值就必须开启扩容，很多时候也许是毛刺，瞬时的高峰压力，因此一般会有一个连续观察窗口来消除毛刺。

系统扩容的时候需要控制节奏，比如新加入一个空闲的节点，如果系统同时把大量的分片迁移到这个节点上那么会造成瞬间的网络IO，磁盘IO压力，进而引发系统波动，我们追求的极致是“随风潜入夜，润物细无声”。关于这一点这里不展开讲。

任何系统都有它的能力极限，如果不断的扩容接近这个极限，那么单纯的扩容已经不能解决问题了，必须重构或者用其他的系统替换，当然这个替换的成本很高。笔者所在公司就遇到过一个系统的存储容量基本达到了极限，地雷被引爆了，后果很严重，海量的数据需要迁移到其他的系统以满足业务的需求，这里涉及到对业务系统的改造，数据转换，数据迁移，流量切换，部门之间的协调（扯皮）。

如果我们资源充足，一个系统扩容了就扩容了，但是很多时候出于成本的考虑，当系统的实际存储数据量减少的时候我们需要对系统缩容，坦白的讲系统缩容比系统扩容更复杂，就像给你涨薪之后没几天又给你降薪一样，你会各种抵触不配合。系统扩容一般可以一个分片一个分片处理，但是缩容需要至少两个分片（有某种关联，比如数据范围相邻）协同配合才能完成，不同的系统根据具体场景有不同的处理办法，不过因为太复杂，很少看到有系统支持这种能力，及时支持也相对比较简单，有很多的约束条件。

终于写完了分布式存储随笔系列，核心就一句话：凡有收益必有代价。我在工作过程中看到太多的开发人员在提出解决方案的时候往往遗忘了代价，很多时候不知道代价和知道代价但是接受这个代价是两码事，最后的结果也完全不同，永远不要指望完美的方案，一劳永逸的方案，永远不要指望撞大运，计算机的世界里，有可能发生的意外就是必然发生的意味，纵观历史，任何问题解决都伴随这新问题的出现，从无例外，做最坏的打算，我们才能游刃有余，从容不迫。

谢谢。