分布式存储系统是将数据存放在多个服务器上，同时按照一定规则做备份，冗余出2-3套副本，以保障有服务器出故障时，整个系统不受影响，依旧可用。
当一部分服务器节点出故障无法访问的时候，存储在故障服务器上的副本无法访问，分布式系统会自动复制健康的数据，保证再有服务器节点无法访问时，数据不会丢失，这个策略就叫做副本补全策略。
然而在一段时间内数目较多的宕机事件有较大可能性诱发系统的大规模副本补全策略（这时就发生了雪崩，由于雪花（这里是指副本修复）的大规模不受控制的产生导致雪崩）。目前的分布式存储系统的两个特点导致这个大规模副本补全策略容易让系统产生雪崩效应：
a.集群整体的free空间较小：通常整体<=30%, 局部机器小于<=20% 甚至10%
b.应用混布：不同的应用部署在同一台物理/虚拟机器上以最大化利用硬件资源
各种网盘、云盘类服务就是a的典型情况。为运营成本的考虑，后端分布式存储系统的空闲率很低。而瞬间的批量宕机会带来大量的副本修复，大量的副本修复很有可能继而打满原本就接近存储quota的其他存活机器，继而让该机器处于宕机或者只读状态。如此继续，整个集群可能雪崩，系统残废。
预防雪崩的方法
1.跨机架副本选择算法和机器资源、用户逻辑隔离
2.让集群流控起来
3.提前预测、提前行动
4.安全模式
安全模式是项目实践过程中产生的防分布式存储系统雪崩大杀器。其基本思路是在一定时间内宕机数目超过预期上限则让集群进入安全模式，按照策略配置、情况严重程度，停止修复副本、停止读写，直到停止一切操作（一般策略）。
通过前面说明，应该可以知道导致分布式存储系统发生雪崩效应的原因就是由于过度的修复副本，所以预防雪崩效应的主要方式就是对修复副本进行控制，让修复副本这个操作从无法控制到可控。主要是控制修复副本发生规模使他在可控范围内。至于怎么控制这个规模呢，就取决于修复副本的实现方式了（使用框架还是自己实现），这里由于各种框架使用方式不一，所以指说明自己实现修复副本的方式，其实通过前面描述可以知道修复副本就是从一台正常运行的服务器上将数据库内容复制到宕机后数据库损坏或者数据库已非最新的服务器，这个过程其实可分为以下几个步骤：
1. 删除宕机后服务器的数据库数据。
2. 查询正常服务器数据库数据。
3. 插入数据到宕机后服务器数据库。
其实就这三个步骤，就可以完成修复副本的功能了，这三个步骤都可在DAO这个层面通过jdbc 方式实现。
实现之后，就要预防雪崩了，控制修复发生条件；
1. 有服务器宕机导致数据库损坏。
2. 正在修复的线程没到达上限，如果达到上限，最简单的方法是，就停止后续一切修复。这样好处是简单粗暴，但是不够灵活，可能会出现一种情况就是修复规模可能暂时到达上限，过一段时间后就少于上限。所以直接停止后续一切修复有弊端，最好的方法是将后续所有修复放入一个等待队列，当然这个等待队列得控制大小，达到一定值就停止一切修复。
这样一个能预防副本修复导致的雪崩效应的分布式系统就实现了。
作者：奋斗中的Android小生
来源：CSDN
原文：https://blog.csdn.net/huang_rong12/article/details/52053452
版权声明：本文为博主原创文章，转载请附上博文链接！