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

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

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

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

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

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

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

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

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

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

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

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，那么业务运维团队就需要承担起这个责任来。下面是从京东云的监控中截取的几个关键指标，当然，还需要有对数据库功能的监控。在这点上，云平台质量部有较为丰富的经验，大家也可以参考《监控不到位，宕机两行泪》

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

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

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

参考文献：