前言
在分布式存储系统中，我们经常会遇到节点坏了挂掉的情况。这个时候我们通常的做法是将其进行送修处理。节点出现问题挂了这个现象本身不严重，这里的重点是我们如何依然保证其上数据对于用户的高可用性。这就是我们常说的存储节点的Decommission过程。本文笔者来聊聊Decommission过程以及它的扩展模式Maintenance模式。
Decommission模式
Decommission过程并不是指简单的存储节点停服务下线的操作，而是在节点允许停止服务前的一系列过程，以此保证系统的数据服务免受节点下线所带来的影响。这里的“一系列过程”包括有以下两个方面：
- 让中心控制节点获知当前节点为即将下线节点，使其从服务节点列表中剔除出去，不让数据读写请求转发到此节点来。
- 复制当前下线节点中的所有副本数据到其它节点中，保持数据的冗余度。
在上述2个步骤过程中，第二步是主要的过程，也将会耗费最多的时间。等这2个步骤都完成了，我们就可以放心地把节点进行停服务，然后送修处理了。
用一句话来概括Decommission过程的一个核心点：当前节点数据将不可用了，我们需要将此节点数据的副本数重新达到期望的数据副本数。
在Decommission过程中，我们需要将节点上所有的数据进行replication出去的操作，如果节点存储数据的量比较多，这个过程的开销还是比较高的。但有些时候，我们送修的机器可能只需要花少量时间进行修复，然后随后又可以恢复服务状态了，此时这个Decommission的操作显然代价有点高了。如果我们能够在保证数据又至少一个副本的可用情况下，允许节点有短暂的维护态，是否是更好的一种使用方式呢？
上面的这种模式是Decommission模式的一种扩展模式，叫做Maintenance模式，Maintenance就是维护中、保养中的意思。
Maintenance模式
如上面所提到的，Maintenance模式与Decommission模式最大的不同点在于它允许短暂的数据冗余度的降低。但这个前提在于集群数据至少是单副本可用的情况。这么说可能大家感知不到Maintenance的实际使用场景。
假设1个集群30台存储节点，3个副本的冗余度设置，假设现在我们要打算对其中10台节点进行短暂的下线维修操作，
第一种，用Decommission的方式处理，就会出现10台节点上的数据同时进行大量数据replication的操作，而且过程也会比较漫长。大量数据副本的复制也会影响系统正常数据的读写操作。
第二种，用Maintenance的方式处理，假设数据是绝对均匀分布的，我下线了10台节点，另外20台节点应保存这10台节点上的其它2个副本数据。此时我可以将这10台节点进入Maintenance模式，让系统知道这些节点只是临时进入维护状态，不需要触发数据复制的操作。等Maintenance时间一过，重新进入服务状态。
上述的两种方案，显然Maintenance模式对于系统的影响更小。
相比较于Decommission模式，Maintenance中需要考虑的环节会更多一些，这里包括：
- 在进入Maintenance之前，需要检查待Maintenance节点上的数据在系统只能至少保证单副本可用的情况，这个阶段我们称之为Entering Maintenance Mode过程。
- 需要有Maintenance维护时间的设置，维护时间一到，节点重新恢复到In Service状态，因为这里没有涉及到实际数据的拷贝，所以服务的恢复将会十分迅速。
但是这里并不是说Maintenance绝对比Decommission好用，从更深层面来谈论二者的差别，还是本身二者使用场景的差异：
Decommission适用于节点长时间不可用、下线的情况，如果是节点长时间会处于不可用的情况，降低其上数据的冗余度不会是一个好的做法。而Maintenance适用于短期不可服务状态，通过短时间内降低数据的冗余度来降低对于系统服务的影响。
Decommission/Maintenance过程中的限流处理
在Decommission或者Maintenance过程中，会存在为了保证数据期望冗余度的要求，造成大量数据复制的情况。这个时候，我们需要做进一步地限流处理。比如在带宽速率上做throttle处理或其它指标上做处理(这个可参考HDFS Balancer的流控处理)。一个总的原则是，我们宁可让数据复制的速度变慢一些，也尽量别让这个过程对于系统服务造成影响。