干货|上云了，如何保障云数据库的高可用？

责任共担模型

朋友和我吐槽，自从他负责的系统上云后，在云数据库上经历了好几次故障，而事后的故障复盘，居然都是他们自己的责任和问题，这让他很被动。更尴尬的是，原想着上云后，数据库的问题都是公有云厂商负责，所以他们运维团队中也没有招聘DBA，当下没有很好的优化思路，于是找我一起探讨这个问题。

朋友的这个Case很典型，认为上云就万事大吉，上云后一旦出现问题，又会觉得上云各种不靠谱。在公有云厂商中，被大家广为认可的观点是“责任共担模型“ 。 在海外，亚马逊AWS、微软Azure均采用了与用户共担风险的安全策略。例如，AWS 作为IaaS+PaaS为主的服务提供商，负责管理云本身的安全，业务系统安全则由客户负责。客户可以在AWS安全市场里挑选合适的产品来保护自己的内容、平台、应用程序、系统和网络安全。而微软Azure也探讨了IaaS, PaaS和SaaS用户的“责任递减”模式。在这里，我们并不打算展开讨论该问题，只是希望引入该概念，让大家建立初步的认知：上云后，依然是需要客户和平台双方通力合作才能取得好的结果。

上云后他经历了什么？

下面是朋友讲述的故障，限于故障原因的重复，我删减了一些Case，听朋友讲完后，我非常吃惊，心里暗想，这和上云有啥关系，这些问题，你不上云照样都会发生的，只能说你运气好，发生在上云期间，大家对于新事物多少有一些宽容，不然，后果不敢想啊。

• 后端模块批量重启，重启时需要从数据库加载业务数据，因并发重启且该请求为慢SQL（几十秒），云数据库负载快速升高，部分请求开始超时，然后请求失败的模块无限重试，导致云数据库负载过大而崩溃，依赖该数据库的其他业务也全部故障

• 在短时间大量并发请求数据库，高峰期并发达到2200左右，导致数据库出现大量慢SQL，进而数据库性能急剧下降，多个业务页面展现变慢，性能退化明显

• 批量创建的任务，其执行时间完全一致，系统在瞬间对数据库请求大量数据，连接数上涨，导致该数据库上的所有业务均发生故障

• 一次秒杀活动，系统请求量剧增，峰值流量达到平时流量的30倍，远超之前预估流量。部分功能大量请求数据库，占满数据库链接，导致数据库崩溃，进而引起系统无法正常运行

• 其购买的安全扫描产品，对接口进行了空参数请求，而接口对于空参数请求进行了数据库的全表扫描，数据库压力飙升，陆续出现了慢SQL，数据库CPU使用率持续在100%，导致该数据库上的其他业务也全部故障

• 某服务访问数据库错误导致响应下游请求合法用户列表的结果为空值，下游模块直接将所有用户的权限全部删除，导致系统完全不可用

• 没有专职DBA，云数据库的变更直接交由研发自己执行，研发多次数据库修改出现异常，导致服务故障和数据丢失

• 研发怀疑数据库性能恶化，因此就重启了数据库，重启期间，有一个模块请求数据库失败，就直接崩溃了

• 在华南部署的一套业务系统，连到华北的数据库，导致系统的响应时间长期居高不下，原因是一个页面包含了非常多的数据库请求，单个请求延时增加40ms，但几十个请求串行执行，延时足足增加了2s以上

故障原因分析

和京东云平台质量部的同学们对上述的Case进行分析后，我们总结了以下原因

慢SQL

常态下系统中存在很多慢SQL，其执行时间少则15s，多则60s以上，如果慢SQL的执行次数增加，必然导致云数据库压力上升，数据库连接被占用，处理其他请求的速率也慢了下来，直至连接数被耗光，导致服务异常，或者在连接数没耗光之前，就因为数据库CPU使用率100%而导致服务异常了

高频SQL

高频SQL看似没有问题，但延时一旦增加或者网络抖动，高频SQL就可能变为较慢的SQL，基于其基础足够大，足以将系统拖垮

复用

上面的多次故障都是因为某一个业务异常导致数据库故障后，影响到了数据库上的所有业务，这可能是源于期望降低运维复杂度，所以搞了一个最大规格数据库的原因，确实，所有业务共用一个数据库从管理角度肯定更简单

读写未分离

上述的Case，大部分都是读请求导致的故障，突然间因为各种原因，导致请求上涨，而数据库实例只有一个，没有水平扩展，所以很容易被打挂

数据库连接数设置不合理

从故障描述中可以看到，随便一个请求，都可以把数据库的并发连接数打到2000+以上，进而导致其他业务不可用，没有对不同业务进行合理的资源分配

缺乏变更流程

研发直接到线上数据库中修改数据，修改错误的原因有表的名字错了，where条件错了，或者是对较大的表结构进行调整，操作前不在线下进行测试验证，操作前也不进行数据库备份，很容易导致重大事故

权限管理混乱

多个CASE都是研发直接操作线上数据，这是权限管理混乱的表现，也是很危险的事情。试想，人人都能修改数据库，会有什么后果大家应该都很清楚。如果修改了和交易数据相关的数据，或者是删库跑路，那就麻烦了

不限流

多个CASE也都看到这个问题，所有的接口都没有做限流，大家可以发起随意量级的访问，因此随便一个用户发起批量请求都足以将系统打垮

云平台质量部的建议

流程建立

对于变更和权限管理等，都需要逐步建立起相关的流程，并尽量自动化起来。同时，针对各种高频操作，还可以提供如操作手册，checklist手册等，尽量减少手工操作。

我个人的习惯，任何问题，提供了多 个解决方案后，最后都要通过三板斧来进行优先级排序，便于大家抓住重点

• 隔离部署&&读写分离，利用京东云的能力，可以快速搞定，所以放第一位

• TOP-N的SQL，找出来容易，优化则需要研发配合，因此放第二位，可以先从那些执行时间几十秒的SQL开始下手

• 限流，或者在接入层进行，或者核心模块上进行开发，耗时略长，因此放第三位

最后，感谢平台质量部的多个小伙伴一起群策群力完成的上述方案。

参考文献：

任务调度系统如何通过隔离提升可用性

https://www.infoq.cn/article/vsb2jGCAgXPPdqPS38S6

预案三板斧的限流大法

https://www.infoq.cn/article/L1FThcLIgzHSYlIaDk0R

监控不到位，宕机两行泪

https://www.infoq.cn/article/txmNQW_d7Hpi8KyXf4wz

责任共担模型

https://aws.amazon.com/cn/compliance/shared-responsibility-model/