如何预防处理大数据雪崩？

本文主要讨论如何在系统内部的逻辑处理上防止系统整体雪崩的发生。预防的重要性大于事故之后的处理，预测集群状态、提前进行优化也成为预防雪崩的一个方向。

下面选取可能发生过的几个场景与大家分享。

1. 跨机架副本选择算法和机器资源、用户逻辑隔离现场还原：

某天运维同学发现某集群几十台机器瞬间失联，负责触发修复副本的主控节点开始进行疯狂的副本修复。大量用户开始反馈集群变慢，读写夯住。

现场应对:

优先解决——副本修复量过大造成的集群整体受影响。

a. 处理的工程师当机立断，gdb到进程更改修复副本的条件为副本<2，而非原本的3（replicas_num），让主控节点这个时候仅修复副本数小于2个的文件，即保证未丢失的文件有至少一个冗余副本，防止只有一个副本的数据因可能再次发生的挂机造成文件丢失。

b. 紧急解决这批机器失联问题，发现是交换机问题，a.b.c.d ip网段的c网段机器批量故障。催促网络组尽快修复。

c. 副本修复到>=2之后，Gdb更改检测副本不足周期，将几十秒的检测时间推迟到1天。等待网络组解决交换机问题。

d. 网络恢复，原有的机器重新加入集群。大量2副本文件重新变为3副本，部分3副本全丢失文件找回。

e. 恢复主控节点到正常参数设置状态，系统开始正常修复。

改进措施:

在改进措施前，先分析下这次事件暴露的系统不足：

1) Master参数不支持热修正，Gdb线上进程风险过大。

2) 一定数量但局域性的机器故障影响了整体集群（几十台相对一个大集群仍属于局域性故障）。如上所述，月千分之几的故障率总有机会让你的存储系统经历一次交换机故障带来的集群影响。

案例分析后的改进措施出炉：

1) Master支持热修正功能排期提前，尽早支持核心参数的热修改。

热修改在上线后的效果可观，后续规避过数次线上问题。

2) 在选择数据副本存储宿主机器的pickup算法中加入跨交换机（机架位）策略，强制——或者尽量保证——副本选择时跨机架位。这种算法底下的副本，至少有1个副本与其他两个副本处于不同的交换机下（IP a.b.c.d的c段）。

该措施同时作用于新的存储数据副本选择和副本缺失后的副本补全策略，能在副本宿主选择上保证系统不会因为交换机的宕机而出现数据丢失，进而避免一直处于副本补全队列/列表的大量的丢失副本节点加重主控节点负载。

3) 机器按region划分隔离功能提上日程；用户存储位置按照region进行逻辑划分功能提上日程；Pickup算法加入跨region提上日程。

a) 机器按照物理位置划分region、用户按照region进行逻辑存储位置划分，能让集群在局部故障的情况下仅影响被逻辑划分进使用这部分机器的用户。

这样一来，最坏情况无非是这个region不可用，导致拥有这个region读写权限的用户受影响。Pickup算法跨region的设计进一步保证被划分region的用户不会因为一个region不可用而出现数据丢失，因为其他副本存到其他region上了。于是，核心交换机故障导致一个region数百台机器的宕机也不会对集群造成范围过大的影响了。

b) 增加region可信度概念，将机器的稳定性因素加入到副本冗余算法中。

当集群规模达到一定量后，会出现机器稳定性不同的问题（一般来说，同一批上线的机器稳定性一致）。通过标记region的稳定性，能强制在选择数据副本的时候将至少一个副本至于稳定副本中，减少全部副本丢失的概率。

c) Region划分需要综合考虑用户操作响应时间SLA、物理机器稳定情况、地理位置等信息。

合理的region划分对提升系统稳定性、提升操作相应时间、预防系统崩溃都有益处。精巧的划分规则会带来整体的稳定性提升，但也增加了系统的复杂度。这块如何取舍，留给读者朋友深入思考了。

2. 让集群流控起来流控方面有个通用且符合分布式存储系统特点的原则：任何操作都不应占用过多的处理时间。这里的“任何操作”包含了在系统出现流量激增、局部达到一定数量的机器宕机时进行的操作。只有平滑且成功的处理这些操作，才能保证系统不因为异常而出现整体受影响，甚至雪崩。

现场还原：

1) 场景1 某天运维同学发现，集群写操作在某段时间大增。通过观察某个存储节点，发现不仅是写、而且是随机写！某些产品线的整体吞吐下降了。

2) 场景2 某集群存储大户需要进行业务调整，原有的数据做变更，大量数据需要删除。

运维同学发现，a. 整个集群整体上处于疯狂gc垃圾回收阶段 b. 集群响应速度明显变慢，特别是涉及到meta元信息更新的操作。

3) 场景3 某天运维同学突然发现集群并发量激增，单一用户xyz进行了大量的并发操作，按照原有的用户调研，该用户不应该拥有如此规模的使用场景。

此类集群某些操作预期外的激增还有很多，不再累述。

现场应对:

1) 立刻电联相关用户，了解操作激增原因，不合理的激增需要立刻处理。

我们发现过如下不合理的激增：

a. 场景1类：通过Review代码发现，大量的操作进行了随机读写更改。建议用户将随机读写转换为读取后更改+写新文件+删除旧文件，转换随机读写为顺序读写。

b. 场景3类：某产品线在线上进行了性能测试。运维同学立刻通知该产品线停止了相关操作。所有公有集群再次发通过邮件强调，不可用于性能测试。如有需要，联系相关人员在独占集群进行性能场景测试。

2) 推动设计和实现集群各个环节的流控机制功能并上线。

改进措施：

1) 用户操作流控

a. 对用户操作进行流控限制可通过系统内部设计实现，也可通过外部的网络限流等方式实现，对单用户做一定的流控限制，防止单个用户占用过多整个集群的资源。

b. 存储节点操作流控可按照对集群的资源消耗高低分为High – Medium – Low三层，每层实现类似于抢token的设计，每层token数目在集群实践后调整为比较适合的值。这样能防止某类操作过多消耗集群负载。若某类操作过多消耗负载，其他操作类的请求有较大delay可能，继而引发timeout后的重试、小范围的崩溃，有一定几率蔓延到整个集群并产生整体崩溃。

c. 垃圾回收gc单独做流控处理。删除操作在分布式存储系统里面常用设计是：接收到用户删除操作时，标记删除内容的meta信息，直接回返，后续进行策略控制，限流的删除，防止大量的gc操作消耗过多单机存储节点的磁盘处理能力。具体的限流策略和token值设置需要根据集群特点进行实践并得出较优设置。

2) 流控黑名单用户因为对线上做测试类的场景可以通过人为制度约束，但无法避免线上用户bug导致效果等同于线上测试规模的场景。这类的场景一般在短时间内操作数严重超过限流上限。

对此类场景可进行流控黑名单设置，当某用户短时间内（e.g. 1小时）严重超过设置的上限时，将该用户加入黑名单，暂时阻塞操作。外围的监控会通知运维组同学紧急处理。

3) 存储节点并发修复、创建副本流控大量的数据副本修复操作或者副本创建操作如果不加以速度限制，将占用存储节点的带宽和CPU、内存等资源，影响正常的读写服务，出现大量的延迟。而大量的延迟可能引发重试，加重集群的繁忙程度。

同一个数据宿主进程需要限制并发副本修复、副本创建的个数，这样对入口带宽的占用不会过大，进程也不会因为过量进行这类操作而增加大量其他操作的延迟时间。这对于采用分发的副本复制协议的系统尤其重要。分发协议一般都有慢节点检查机制，副本流控不会进一步加重系统延迟而增大成为慢节点的可能。如果慢节点可能性增大，新创建的文件可能在创建时就因为慢节点检查机制而缺少副本，这会让集群状况更加恶化。

3. 提前预测、提前行动1) 预测磁盘故障，容错单磁盘错误。

场景复现：

某厂商的SSD盘某批次存在问题，集群上线运行一段时间后，局部集中出现数量较多的坏盘，但并非所有的盘都损坏。当时并未有单磁盘容错机制，一块磁盘坏掉，整个机器就被置成不可用状态，这样导致拥有这批坏盘的机器都不可用，集群在一段时间内都处于副本修复状态，吞吐受到较大影响。

改进措施:

a) 对硬盘进行健康性预测，自动迁移大概率即将成为坏盘的数据副本近年来，对磁盘健康状态进行提前预测的技术越来越成熟，技术上已可以预判磁盘健康程度并在磁盘拥有大概率坏掉前，自动迁移数据到其他磁盘，减少磁盘坏掉对系统稳定性的影响。

b) 对单硬盘错误进行容错处理存储节点支持对坏盘的异常处理。单盘挂掉时，自动迁移/修复单盘的原有数据到其他盘，而不是进程整体宕掉，因为一旦整体宕掉，其他盘的数据也会被分布式存储系统当做缺失副本，存储资源紧张的集群经历一次这样的宕机事件会造成长时间的副本修复过程。在现有的分布式存储系统中, 也有类似淘宝TFS那样，每个磁盘启动一个进程进行管理，整机挂载多少个盘就启动多少个进程。

根据现有存储分布，预测均衡性发展，提前进行负载均衡操作。

这类的策略设计越来越常见。由于分布式存储集群挂机后的修复策略使得集群某些机器总有几率成为热点机器，我们可以对此类的机器进行热点预测，提前迁移部分数据到相对负载低的机器。

负载均衡策略和副本选择策略一样，需要取舍复杂度和优化程度问题。复杂的均衡策略带来好的集群负载，但也因此引入高复杂度、高bug率问题。如何取舍，仍旧是个困扰分布式存储系统设计者的难题。