即时通讯云 LeanCloud 4月22日存储集群因故瘫痪

52im.net · 8 年前 | 阅读（12714）· 评论（0）| 来源 LeanCloud 转发收藏0

摘要 4月22日即时通讯云 LeanCloud 发生了因存储集群故障而致服务瘫痪，从事故原因中可以想够用的出目前LeanCloud这类即时通讯云厂商所面临的各种挑战。

前言

4月22日即时通讯云 LeanCloud 发生了因存储集群故障而致服务瘫痪，从事故原因中可以想象的出目前LeanCloud这类即时通讯云厂商所面临的各种挑战：当用户量持续增大，所面临的各种因大并发、高服务需求问题，时常导致整体服务品质的下降，这也侧面反映出，要做出可靠的云即时通讯服务，在没有现成方案可用的情况下，各厂商要走的路显然还很长。

以下是官方事故通报情况

2016 年 4 月 22 日 13:04 开始，LeanCloud 中国节点的后端存储集群出现问题，导致该节点上所有应用都出现了存储 API 访问故障，将近半小时后得到恢复。故障的详细经过通报如下。

故障时间

13:09－13:28 所有应用的数据存储服务都出现访问异常（持续 19 分钟）
13:28－13:40 大部分应用已经恢复，但还有 20% 的应用依然无法正常访问（持续 12 分钟）

影响范围

中国节点上所有应用的存储服务都受到影响，同时依赖于数据存储的实时通信、云引擎服务也可能出现内部错误。
美国节点不受影响，所有服务均工作正常。

事故经过

13:04 我们监控系统陆续发出报警，后端存储集群访问超时慢慢增多，工程师介入调查，并向用户发出了短信和邮件通知。
13:10 整个集群的存储 API Server 不再响应外部请求。调查后确认是后端存储系统在做大量耗时的关系数据写入操作，导致系统失去响应。于是我们马上重启集群，并分批开放流量。
13:28 部分存储分片（shard）得到恢复，80% 的应用访问恢复正常；发送第二次故障进度通知。
13:40 所有应用恢复正常；发送故障解决通知。

后续改进措施

这一次故障的根本原因在于 AVRelation 模型的底层实现存在缺陷，某些特殊条件下会导致后端存储系统因忙于处理而失去响应。我们已完成替代方案的开发，正在测试中，下周会发布更合理的解决方案。（4 月 27 日周三完成）
改进并发限制的算法，以便在异常条件下更好地限制故障的影响范围。（4 月 25 日周一完成）
排查所有危险／耗时操作，在上层进行写入控制，避免对后端存储系统造成太大影响。（4 月 25 日周一完成）