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

成都创新互联公司的客户来自各行各业，为了共同目标，我们在工作上密切配合，从创业型小企业到企事业单位，感谢他们对我们的要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。专业领域包括网站设计制作、成都网站建设、电商网站开发、微信营销、系统平台开发。

慢SQL

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

高频SQL

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

复用

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

读写未分离

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

数据库连接数设置不合理

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

缺乏变更流程

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

权限管理混乱

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

不限流

TOP-N的SQL限流

在京东云上，提供了性能优化的功能，可以查询到所有的慢SQL，一定要加以使用

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

隔离部署

读写分离

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

限流

数据备份

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

数据库的监控

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

流程建立

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

参考文献：