从语雀文档宕机聊聊 CAP 定理

背景

最近蚂蚁集团旗下的在线文档产品-《语雀文档》突发数据故障，导致系统宕机近 8 个小时。所有用户的在线文档及重要资料都无法打开。这么长时间的服务停摆基本定义为 P0 事故(P0 为事故定义最高级别)。从事故的处理时长可以分析肯定是数据出了问题。应用发布问题都可以及时回滚到之前的版本，数据问题就比较难恢复了。最后官方事故通报是数据存储服务器误下线引发系统故障。结合这一事件来聊聊分布式的基础理论-CAP，分析下语雀文档的事故处理过程及架构设计。

CAP 定理

首先，什么是 CAP 定理呢。这个定理指的是：一个分布式系统，不可能同时满足以下三点

• 一致性（Consistency）这里一致性指的是数据的瞬时一致性，等同于所有节点访问同一份最新的数据副本
• 可用性（Availability）每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
• 分区容错性（Partition tolerance）分区相当于对通信的时限要求，分区容错是系统的网络分区的区间通信可能会失败。因此，可以认为 CAP 理论中分布式系统的 P 总是成立。

CAP 定理表明上述三个指标不可能同时做到，而一般来说，分布式系统中的分区容错性 P 又总是成立，所以就需要我们在系统设计时是首要考虑 CP 还是 AP。

CAP 理论示意图

CAP 理论示意图

案例分析

结合语雀文档的案例来分析 CAP 定理。我们从复杂的系统中抽象简化。如图，假设语雀的数据存储及应用节点分为 AB 两个分区。实际对用户而言，并不感知这两个分区节点。

在分布式系统正常运行时，用户可以通过客户端或者网页读写在线文档。当用户编辑更新文档资料时，文档数据通过应用程序 system1(S1) 更新记录在数据库 database1(D1)中，同时网络通信正常，将数据库 D1的数据同步到数据库 D2 中。此时，用户在多个客户端看到的文档数据是内容完全一致的数据。当然，这只是理想情况。实际现实情况远远比这复杂，有很多因素会引发系统故障。从图中我们逐个分析。

• 首先是应用程序 bug，任何程序员都不能保证一辈子不写一两个 bug。这就导致图中应用程序 s1 或者 s2 故障。此时，快速的解决方案可以通过发布系统及时回滚到上一个可用的版本。回滚后，程序可用，系统数据也没有写错，OK，万事大吉，再仔细定位系统程序 bug 问题。
• 其次，网络通信故障。现实中的网络环境比较复杂，比如：光纤挖断，机房网络交换机故障，瞬时流量过大，带宽负载太高等等。这就是图中数据库 D1 到 D2 的数据复制通路中断。此时，用户在客户端编辑更新的文档数据只在数据库 D1 中有保存，应用程序 S2 不能返回最新的数据给用户，这种场景就是我们 CAP 理论中的 AP 还是 CP 取舍的问题。 现在有两种解决方案： 1. 为了保证系统可用性，牺牲数据一致性，直接返回旧的文档数据给用户，也就是 AP without C；对于数据时效性并不敏感的系统可以选用这种方案，暂时不能返回最新的数据给用户，待系统故障修复后及时同步最新数据。比如电商系统的购物车，或者历史订单查询系统等。这种方案只是牺牲数据的瞬时一致性，数据的最终一致性还是需要保证的，可以通过事后核对及异常补偿机制来保证。 2. 保证数据一致性，牺牲系统可用性。中断用户的操作，待系统故障及网络完全恢复后，再给用户返回最新数据，也就是CP without A。对于数据强一致性要求较高的系统可以选用这种方案，直接暂时不让用户使用系统操作了。比如银行的交易系统，微信支付、支付宝的支付链路等等，因为一旦出现数据不一致故障还继续操作极有可能导致资损，后果不可估量。
• 最后，看下语雀官方通报的事件故障处理过程

据语雀公告，10 月 23 日下午，服务语雀的数据存储运维团队在进行升级操作时，由于新的运维升级工具 bug，导致华东地区生产环境存储服务器被误下线。
受其影响，语雀数据服务发生严重故障，造成大面积的服务中断。为了尽快恢复服务，语雀和数据
存储运维团队全力进行数据恢复工作，但受限于恢复方案、数据量级等因素，整体用时较长。
具体过程如下：

14:07 数据存储运维团队收到监控系统报警，定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线；

14:15 联系硬件团队尝试将下线机器重新上线；

15:00 确认因存储系统使用的机器类别较老，无法直接操作上线，立即调整恢复方案为从备份系统中恢复存储数据；

15:10 开始新建存储系统，从备份中开始恢复数据，由于语雀数据量庞大，此过程历时较长，19 点完成数据恢复，同时为保障数据完整性，在完成恢复后，用时 2 个小时进行数据校验；

21 点存储系统通过完整性校验，开始和语雀团队联调，最终在 22 点恢复语雀全部服务。用户所有数据均未
丢失。

从官方通报的事件故障处理过程来看，系统发生故障的根本原因是图中的 D1 或者 D2 出问题了。直接导致数据存储服务器故障。这时候已经别无选择了，只能停服修数据了。通常系统重要数据都会有存储备份，存储备份又可以分类为冷备和热备。从开始恢复到最终恢复完成并通过数据校验，耗时近 7 个小时，很有可能是系统缺少热备数据，不能及时切换，只能从定时备份的冷备中恢复数据。

可借鉴的措施

通过以上事件，语雀也公布了针对性的改进措施

1. 升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成；
2. 运维团队加强运维工具的质量保障与测试，杜绝此类运维 bug 再次发生；
3. 缩小运维动作灰度范围，增加灰度时间，提前发现 bug；
4. 从架构和高可用层面改进服务，为语雀增加存储系统的异地灾备。

前 3 点都是保证系统操作流程的规范性，第 4 点是从架构设计出发，增加系统的高可用性。目前通常的异地灾备方案有以下几种

• 同城双活，一般是指在同一城市或相近区域内建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行，这样短距离的网络通信可以保证数据的时延性低，数据之间的复制变得更加可靠。数据存储异常时可以作为热备数据集群及时切换。
• 异地容灾，通常主备数据节点之间的距离相对较远， 因此一般采用异步镜像，会有少量的数据丢失。这部分数据节点通常作为数据冷备，定时做数据快照备份。数据中心可靠性较高，恢复时效性相对同城双活较慢
• 两地三中心，这种方案就是前面两种架构的结合，同城双活+异地容灾。数据可靠性大大提高，但建设成本也比较高。 我正在参与2023腾讯技术创作特训营第三期有奖征文，组队打卡瓜分大奖！