后端存储实战课
李玥
京东零售计算存储平台部资深架构师
立即订阅
3106 人已学习
课程目录
已更新 12 讲 / 共 26 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (2讲)
开篇词 | 从今天起,换种方式学存储
免费
课前加餐 | 电商系统是如何设计的?
创业篇 (7讲)
01 | 创建和更新订单时,如何保证数据准确无误?
02 | 流量大、数据多的商品详情页系统该如何设计?
03 | 复杂而又重要的购物车系统,应该如何设计?
04 | 事务:账户余额总是对不上账,怎么办?
05 | 分布式事务:如何保证多个系统间的数据是一致的?
06 | 如何用Elasticsearch构建商品搜索系统?
07|MySQL HA:如何将“删库跑路”的损失降到最低?
高速增长篇 (3讲)
08 | 一个几乎每个系统必踩的坑儿:访问数据库超时
09 | 怎么能避免写出慢SQL?
10 | 走进黑盒:SQL是如何在数据库中执行的?
后端存储实战课
登录|注册

08 | 一个几乎每个系统必踩的坑儿:访问数据库超时

李玥 2020-03-14
你好,我是李玥。
每一个创业公司,它的系统随着公司的发展一起成长的过程中,都难免会发生一些故障或者是事故,严重的会影响业务。搞技术的同学管这个叫:坑儿,分析解决问题的过程,称为:填坑儿。而访问数据库超时这个坑儿,是我见过的被踩的次数最多的一个坑儿,并且这个坑儿还在被不停地踩来踩去。
今天这节课,我和你分享一个典型的数据库超时案例。我也希望你通过和我一起分析这个案例,一是,吸取其中的经验教训,日后不要再踩类似的坑儿;二是,如果遇到类似的问题,你能掌握分析方法,快速地解决问题。最重要的是,学习存储系统架构设计思想,在架构层面限制故障对系统的破坏程度。

事故排查过程

我们一起来看一下这个案例。
每一个做电商的公司都梦想着做社交引流,每一个做社交的公司都梦想着做电商将流量变现。我的一个朋友他们公司做社交电商,当年很有前途的一个创业方向,当时也是有很多创业公司在做。
有一天他找到我,让我帮他分析一下他们系统的问题。这个系统从圣诞节那天晚上开始,每天晚上固定十点多到十一点多这个时段,大概瘫痪一个小时左右的时间,过了这个时段系统自动就恢复了。系统瘫痪时的现象就是,网页和 App 都打不开,请求超时。
这个系统的架构是一个非常典型的小型创业公司的微服务架构。系统的架构如下图:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《后端存储实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 冯玉鹏
    老师,慢SQL 我感觉也没有个人标准,个人的标准也要分场景,业务复杂度等;如果作为常规的用户业务系统,超过1秒就是慢SQL;但是如果是类似生成报表的服务,选择在业务低峰期,从库执行等策略,时间长点也不是不能接受。
    避免慢SQL:第一点肯定想到的是合适的索引,毕竟SQL执行速度的快慢关键还是语句需要扫描数据的行数,如尽量不要使用 对where 条件列进行计算的做法让MySQL查询优化器不知道怎么选择索引,特定业务 可以设置联合索引让需要查询返回的列都在索引中避免回表操作。
    第二:排序也是可能完成慢SQL的因素,尤其是数据量大,需要使用外部排序的时候又可以与磁盘IO性能扯上关系等,常见的问题还有limit m,n m很大又无法使用索引的时候
    第三:多表联合查询的时候,尽量使用小表驱动大表。
    第四:避免大事务,这也是发生死锁常见的雷区,尽量减小事务粒度,尽量注意不同事务对表操作的顺序一致,大事务其实也包含着批量操作的隐式事务,如一个update 影响100万行数据。

    第五:见过的关于架构方面的慢SQL问题 1~数据量到达一定规模后,单机性能容易受限导致数据库响应慢;2~读写分离,从库提供读服务,错误的认为从库只需要提供查询服务采用了达不到性能指标的机器,其实是主库承受的数据更新压力,从库一个不落的都要承受,还要更多的提供查询服务

    作者回复: 👍👍👍👍👍

    2020-03-14
    6
  • 美美
    个人感觉,算不算慢SQL首先取决于这条SQL有没有正确的命中索引。如果可以正确的命中索引,那么从业务上是否正确。如果业务匹配,且正常命中索引,那应该不算是慢查询。
    看完本章还有一点疑惑,就是当第一个慢查询SQL处理完成后,MySQL的CPU使用率已经降到了20%以下。那么即便会有周期性的SQL执行,但是以这个利用率不足以整体导致服务不可用吧。

    作者回复: 20%左右那个是闲时的图,忙时依然是100%....

    2020-03-15
    1
  • 小袁
    不仅仅要扫描长时间执行的sql语句,还要扫描长事务。有些python库不开启自动提交,会导致长事务占据表的元数据锁,从而导致更多的问题。
    2020-03-17
  • 一步
    上面那个小型创业公司的微服务架构,想知道有关 Nginx 的主备是怎么实现的?

    作者回复: 我们例子里面当时它采用的就是人肉冷备,主节点出问题的时候人肉切换到备用节点上。

    其实更合理的做法是做通过负载均衡器或者域名把流量均匀的打到多个NGINX节点上,配合探活机制,当某个节点有问题的时候,自动摘掉这个节点。

    2020-03-17
    1
  • 星星滴蓝天
    我们这种一般先上读写分离,死从库不死主库
    2020-03-16
    1
  • Regis
    老师讲的非常好,给出了查找问题的思路和解决问题思路,对于项目经验少的很有用。后续课程里面有没有涉及对于视频类的大文件存储方式和使用方式的课程?这部分数据知道使用对象存储进行存储比较好,但是对于有这种大文件的存储的系统架构方面还是不清晰,老师要是了解给指导一下可以吗

    作者回复: 后面有一节课是专门讲对象存储的,敬请期待。

    2020-03-16
  • 发条橙子 。
    老师 针对两个问题排查后处理的方法能不能给个思路

    1. 缓存热点数据 : 因为使用连表查询等复杂语句在数据量大的时候会产生慢差 。是否该考虑修改查询语句或者上搜索(es / 阿里open search ) 然后再加一道缓存 缓存的读写策略采用旁路策略。

    2. 像这种定时任务应该大部分公司都会有很多,一般都是放到凌晨来执行 ,经常会有人问当数据量大的时候 这种定时任务是否可行。 所以像数据量非常大(京东这种级别数据) 定时任务扫表是否还可行 有没有其他的解决思路

    希望老师给些思路 谢谢🙏

    作者回复: 这两个问题我在后续的课程中都会讲到一些解决的经验和方法。

    这种大查询,首先肯定是要用缓存,但要根据实际情况选择合适的缓存更新策略。

    数据量特别大的统计分析,一般选择放到其它分析型数据库或者数据仓库中去执行,或者使用流计算来解决。

    2020-03-15
    2
  • 观弈道人
    作者文中描述的问题可以理解成就是缓存更新慢,导致的缓存穿透
    2020-03-14
  • webmin
    1. 以你个人的标准,什么样的 SQL 算是慢 SQL?
    SQL的快慢是个相对标准,与数据量和设备性能有相关性,需要建立监控机制,了解SQL在正常情况下的执行时间的基线是多少,偏离基线超过阀值时可以认为是慢了。
    2. 如何才能避免写出慢 SQL?
    抓大放小,针对查询量大和查询大数据集的SQL
    2.1 先通过SQL执行计划看看是否使用了与预想一至的索引和SQL的执行路径是否与预想的一至;(需要在生产库上看执行计划,现在的DB大都是用成本法对SQL进行优化,数据量不一样会导致执行路径不同)
    2.2 利用好测试DB,在无法模拟生产数据量的情况下,也需要按一定比例在测试DB在灌入数据,通过实际执行测量执行时间。
    2020-03-14
  • 肥low
    老师好 你讲的例子好像就发生在昨天,慢SQL的话执行时间超过1秒就算是了,长的主要原因有: 语句复杂,比如各联表,group by我就被搞死过一次; 还有就是没有建立合适的索引,总而言之,如果对数据库如MySQL BTree有较深入的理解的话,肯定不会写出这么慢的SQL来
    2020-03-14
  • myrfy
    慢SQL要以业务场景来区分。例如做即时通讯或者消息类等有实时性要求的,可能2秒就算慢查询了,但是读从库做大数据分析的场景,可能跑一个小时也不算慢。另外,对于请数量大的时候,如果存在多个请求会加锁,即使一个查询是毫秒级别的,上百个查询访问一个热数据加锁也会有很大的问题,所以,没有慢查询的具体标准,影响到业务,拖慢了服务的,就算慢查询。
    2020-03-14
收起评论
11
返回
顶部