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

责任共担模型

朋友和我吐槽，自从他负责的系统上云后，在云数据库上经历了好几回故障，而过后的故障复盘，竟然都是他们本身的责任和问题，这让他很被动。更尴尬的是，原想着上云后，数据库的问题都是公有云厂商负责，因此他们运维团队中也没有招聘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也都看到这个问题，全部的接口都没有作限流，你们能够发起随意量级的访问，所以随便一个用户发起批量请求都足以将系统打垮。

云平台质量部的建议

结合该朋友的状况，云平台质量部的同窗通过讨论后，对数据库的改进给出以下建议，而对于一些较为通用的问题，如系统异常后直接崩溃，空参数等等，则不在此进行讨论，咱们后续会有专门的文章进行说明。

TOP-N的SQL限流

TOP-N的SQL分为两种情形：

• 慢SQL，也就是执行耗时的TOP-N

  • SQL优化
  • 合理设置数据库链接数
  • 执行耗时超过1s的SQL直接kill（对于部分场景能够进行自定义，如同步任务，写SQL，重要性较高的SQL等）
  • SQL问题较多的帐号进行紧急封禁

• 高频SQL，也就是执行频次的TOP-N

  • 经过业务层的缓存功能减小高频SQL

在京东云上，提供了性能优化的功能，能够查询到全部的慢SQL，必定要加以使用

最后提一句，必定要想办法在集群上实现自动化kill慢SQL的功能，而不要等遇到出问题后挨个找人来看能不能杀这些SQL，那就太晚了，经验值，一旦走到这个地步，故障时长起步40分钟。

隔离部署

核心业务必须使用独立的数据库实例，仅非核心业务能够考虑共用数据库实例。从而避免单个用户的问题影响到全部业务。但隔离不只仅是基于业务角度进行隔离，还能够根据业务状况进行其余维度的隔离，例如将一些报表类业务从核心业务中剥离出来，相似的思路，业务运维的隔离方式有不少，能够参考《任务调度系统如何经过隔离提高可用性？》

从成本角度看，京东云很好的考虑到了这点，两个小实例的价格等于一个大实例的价格，所以拆分并不会增长费用，而管理成本的增长也很是低。

读写分离

京东云的云数据库提供只读实例，须要利用好该特性。简单点就是新增几个只读实例将读请求进行迁移，复杂点，能够将不一样业务类型的读请求分配到不一样的只读实例上，利用隔离的特性将故障控制在较小的范围内，从而保障大部分功能的正常使用。

限流

限流不只仅在数据库层面经过链接数的方式进行控制，更须要前置在业务侧进行，毕竟业务侧的限流机制会更为灵活和定制化，更能知足业务的需求。如何限流，能够参考《预案三板斧的限流大法》。

数据备份

对数据库的任何修改和调整，都须要进行备份，以避免发生上述朋友的问题。京东云提供了灵活的数据库备份管理功能，须要好好的使用起来。这个地方的重要性，就不赘述了。

数据库的监控

没上云以前，可能会有专门的DBA团队来对数据库进行监控，上云后，若是没有专职的DBA，那么业务运维团队就须要承担起这个责任来。下面是从京东云的监控中截取的几个关键指标，固然，还须要有对数据库功能的监控。在这点上，云平台质量部有较为丰富的经验，你们也能够参考《监控不到位，宕机两行泪》。

流程创建

对于变动和权限管理等，都须要逐步创建起相关的流程，并尽可能自动化起来。同时，针对各类高频操做，还能够提供如操做手册，checklist手册等，尽可能减小手工操做。

三板斧

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

• 隔离部署&&读写分离，利用京东云的能力，能够快速搞定，因此放第一位；
• TOP-N的SQL，找出来容易，优化则须要研发配合，所以放第二位，能够先从那些执行时间几十秒的SQL开始下手；
• 限流，或者在接入层进行，或者核心模块上进行开发，耗时略长，所以放第三位。

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

---

参考文献：

任务调度系统如何经过隔离提高可用
https://www.infoq.cn/article/...

预案三板斧的限流大法
https://www.infoq.cn/article/...

监控不到位，宕机两行泪
https://www.infoq.cn/article/...

责任共担模型
https://aws.amazon.com/cn/com...

---

点击“连接”了解云数据库 SQL Server更多详情！

欢迎点击“京东云”了解更多精彩内容。