京东云mysql 外网访问_干货|上云了，如何保障云数据库的高可用？

责任共担模型

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

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

上云后他经历了什么？

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

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

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

批量创建的任务，其执行时间完全一致，系统在瞬间对数据库请求大量数据，连接数上涨