写点什么

上云了,如何保障云数据库的高可用?

2019 年 11 月 29 日

上云了,如何保障云数据库的高可用?

责任共担模型


朋友和我吐槽,自从他负责的系统上云后,在云数据库上经历了好几次故障,而事后的故障复盘,居然都是他们自己的责任和问题,这让他很被动。更尴尬的是,原想着上云后,数据库的问题都是公有云厂商负责,所以他们运维团队中也没有招聘 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 分钟。


隔离部署


核心业务必须使用独立的数据库实例,仅非核心业务可以考虑共用数据库实例。从而避免单个用户的问题影响到所有业务。但隔离不仅仅是基于业务角度进行隔离,还可以根据业务情况进行其他维度的隔离,例如将一些报表类业务从核心业务中剥离出来,类似的思路,业务运维的隔离方式有很多,可以参考《任务调度系统如何通过隔离提升可用性?


从成本角度看,京东云很好的考虑到了这点,两个小实例的价格等于一个大实例的价格,因此拆分并不会增加费用,而管理成本的增加也非常低。




读写分离


京东云的云数据库提供只读实例,且只读实例应该尽量分布到多个 AZ 中,从而实现应用程序的就近访问。简单点就是新增几个只读实例将读请求进行迁移,复杂点,可以将不同业务类型的读请求分配到不同的只读实例上,利用隔离的特性将故障控制在较小的范围内,从而保障大部分功能的正常使用。



限流


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


数据备份


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



数据库的监控


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





流程建立


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


三板斧


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


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

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

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


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


参考文献:


责任共担模型


2019 年 11 月 29 日 11:5812033

评论 2 条评论

发布
用户头像
还需要增加一下因为锁导致的故障
2020 年 11 月 06 日 18:40
回复
用户头像
传统的运维其实干的不仅仅是系统运维,还做了一些鞭策开发的事情。上云不是简单的购买云资源并把运维岗位给去掉,而是把系统运维的部分职责给了云服务商,一些优化工作,系统设计工作还是需要自己干。这就要求开发能更独立的进行系统研发,能考虑更多。
2019 年 12 月 30 日 11:26
回复
没有更多了
发现更多内容

刷了LeetCode的链表专题,我发现了一个秘密!

Simon郎

Java 链表 面试数据结构与算法

Redis-缓存雪崩,缓存击穿,缓存穿透

topsion

redis

架构师训练营 W03 总结

Geek_f06ede

架构师训练

vivo 云服务海量数据存储架构演进与实践

vivo互联网技术

数据库 架构 云服务 数据存储

JDK8中的新时间API:Duration Period和ChronoUnit介绍

程序那些事

java8 jdk8 新特性 程序那些事 时间API

5G时代的到来对直播的影响

anyRTC开发者

5G 音视频 WebRTC 直播 RTC

环球易购数据平台如何做到既提速又省钱?

苏锐

大数据 hdfs S3 CDH 成本优化

架构师训练营 W03 作业

Geek_f06ede

架构师训练

面经手册 · 第16篇《码农会锁,ReentrantLock之公平锁讲解和实现》

小傅哥

Java 面试 小傅哥 ReentrantLock 公平锁

redis的stream类型命令详解

LLLibra146

redis stream 消息队列

推进AI融合 2020 LF AI & DATA DAY(AI开源日)即将召开

Geek_459987

区块链数字货币交易所开发方案,交易平台搭建app

WX13823153201

Linux-技术专题-Linux命令如何进行查看进程

李浩宇/Alex

第一届“多模态自然语言处理研讨会”精彩回顾(免费获取PPT)

京东智联云开发者

人工智能 自然语言处理

TensorFlow 篇 | TensorFlow 数据输入格式之 TFRecord

Alex

tensorflow keras dataset tfrecord

Linux高级编程常用的系统调用函数汇总

哒宰的自我修养

Linux 线程 网络编程 进程 MySQL数据库

开源技术够用了么?我的 NAS 选型与搭建过程

LeanCloud

开源 NAS

网易云音乐基于 Flink + Kafka 的实时数仓建设实践

Apache Flink

flink

一场关于FLV是否要支持HEVC的争论

wangwei1237

技术文化

23张图!万字详解「链表」,从小白到大佬!

王磊

Java 数据结构与算法

深度解读智能推荐系统搭建之路 | 会展云技术揭秘

京东智联云开发者

人工智能 推荐系统

CloudQuery V1.2.0 版本发布

CloudQuery社区

数据库 sql 编辑器 工具软件

英特尔独显终于来了!锐炬®Xe MAX为非凡S3x带来设计师级创作体验

intel001

程序人急速变富指南(一)

陆陆通通

程序员 职业 财富 认知 眼界

甲方日常 44

句子

工作 随笔杂谈 日常

接口测试用例编写和测试关注点

测试人生路

接口测试 测试用例

如何在面试中解释关键机器学习算法

计算机与AI

学习 数据科学

「排序算法」图解双轴快排

bigsai

排序算法 快速排序 双轴快排

央视呼吁电商双十一少一些套路:应该严打网店套路营销

石头IT视角

腾讯内容首发:分布式核心原理解析笔记+分布式消息中间件实践笔记PDF版

Java架构追梦

Java 架构 面试 分布式 消息中间件

给萌新HTML5 入门指南(二)

Geek_Willie

上云了,如何保障云数据库的高可用?-InfoQ