高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9202 人已学习
课程目录
已更新 38 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要学习高并发系统设计?
免费
基础篇 (6讲)
01 | 高并发系统:它的通用设计方法是什么?
02 | 架构分层:我们为什么一定要这么做?
免费
03 | 系统设计目标(一):如何提升系统性能?
04 | 系统设计目标(二):系统怎样做到高可用?
05 | 系统设计目标(三):如何让系统易于扩展?
06 | 面试现场第一期:当问到组件实现原理时,面试官是在刁难你吗?
演进篇 · 数据库篇 (5讲)
07 | 池化技术:如何减少频繁创建数据库连接的性能损耗?
08 | 数据库优化方案(一):查询请求增加时,如何做主从分离?
09 | 数据库优化方案(二):写入数据量增加时,如何实现分库分表?
10 | 发号器:如何保证分库分表后ID的全局唯一性?
11 | NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?
演进篇 · 缓存篇 (6讲)
12 | 缓存:数据库成为瓶颈后,动态数据的查询要如何加速?
13 | 缓存的使用姿势(一):如何选择缓存的读写策略?
14 | 缓存的使用姿势(二):缓存如何做到高可用?
15 | 缓存的使用姿势(三):缓存穿透了怎么办?
16 | CDN:静态资源如何加速?
加餐 | 数据的迁移应该如何做?
演进篇 · 消息队列篇 (6讲)
17 | 消息队列:秒杀时如何处理每秒上万次的下单请求?
18 | 消息投递:如何保证消息仅仅被消费一次?
19 | 消息队列:如何降低消息队列系统中消息的延迟?
20 | 面试现场第二期:当问到项目经历时,面试官究竟想要了解什么?
用户故事 | 从“心”出发,我还有无数个可能
期中测试 | 10道高并发系统设计题目自测
演进篇 · 分布式服务篇 (9讲)
21 | 系统架构:每秒1万次请求的系统要做服务化拆分吗?
22 | 微服务架构:微服务化后,系统架构要如何改造?
23 | RPC框架:10万QPS下如何实现毫秒级的服务调用?
24 | 注册中心:分布式系统如何寻址?
25 | 分布式Trace:横跨几十个分布式组件的慢请求要如何排查?
26 | 负载均衡:怎样提升系统的横向扩展能力?
27 | API网关:系统的门面要如何做呢?
28 | 多机房部署:跨地域的分布式系统如何做?
29 | Service Mesh:如何屏蔽服务化系统的服务治理细节?
演进篇 · 维护篇 (5讲)
30 | 给系统加上眼睛:服务端监控要怎么做?
31 | 应用性能管理:用户的使用体验应该如何监控?
32 | 压力测试:怎样设计全链路压力测试平台?
33 | 配置管理:成千上万的配置项要如何管理?
34 | 降级熔断:如何屏蔽非核心系统故障的影响?
高并发系统设计40问
登录|注册

20 | 面试现场第二期:当问到项目经历时,面试官究竟想要了解什么?

唐扬 2019-11-04
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 星空123
    我们的售货机系统是每天有几个时间段请求会成倍的增加。像每天中午11点-12点半。晚上的5点半到6点还有晚上21点到24点。
     这几个时间段的订单量是比较大的。

     我们第一次碰到的问题是机器代理商反馈有客户购买了,但是出货很慢。并且还发现了系统出现了大量的订单退款。我们开始从日志方面看,发现了好像系统的处理速度变慢了。并且这些退款的订单都是出货了的。这样的话,系统就亏大了。并且随着高峰的到来,系统开始报mysql的连接数用完了。导致数据库写入和更新操作都没法做。我们立刻把生产系统停掉。老板也是致电我们,搞不好就滚蛋。然后我们连夜对机器下单这块的业务做优化, 减少访问mysql的压力。并且把消息处理类中用到的连接池的大小给扩大一倍。
     就这样消停了几天。

    但是由于系统内设备不断增加,隔了大概一周左右,晚上10点左右又来投诉说这个问题,我们犹如惊弓之鸟,立马打开日志查看。还是这个问题。

    而且以前忽略了微信的支付回调如果处理不及时,微信会向回调地址重复发送订单结果的通知。这个是导致系统崩盘的重要的点之一。

    关键这次发现了最重要的问题:系统在处理终端设备订单的微信支付宝的回调在做异步处理的时候,由于回调部分没有做并发处理。
    导致数据库的表被锁住,引发的回调部分业务要处理堆积,系统处理不过来。恶性循环,消息越多,越处理不过来。越处理不过来,支付回调部分越堆积。导致我们的机器又出货,又退款。

    最终我们花了一夜时间把微信支付回调做了多线程处理。系统才稳定了下来。

    第二天把支付宝的回调处理部分也做了多线程处理。一段时间内没有问题。

    现在系统加了redis做缓存。但是缓存刚上线也是有不少问题的。但是我们慢慢解决了。

    目前的系统算是比较稳定了。

    阿里云的双核4G服务器 支撑我们系统的600多台设备。

    老师文章中提到的方案对我们后面工作不论是在这个公司,还是以后都是有很大启发的。

    作者回复: 谢谢肯定

    2019-11-07
    5
  • 斐波那契
    老师 有个问题 一直以来很难接触到高并发的项目 做的项目也都是缝缝补补 排查基本不需要什么技巧 很快就能找到问题 这样下肯定不行 老师有什么建议么

    作者回复: 其实有时候只是自己比较容易容忍问题而已:)

    比如一些偶发的超时,重启时的慢请求,系统中有没有出现,有没有追查根本的原因

    2019-11-04
    1
    4
  • 大雄
    看后不禁想起了一个面试经典问题:平时遇到问题你是怎么解决的?
    我第一次面对这种问题,大脑一片空白,因为没有能拿得出手的问题,只好泛泛而谈,差不多就是“百度,查文档”之类的,想起来真是尴尬。下来之后反思了一下,觉得如果实在没有能拿得出手的案例,也要假设一个有挑战性的问题去回答,回答得好可以体现学习能力,回答不好至少也能留下个好学的印象。
    最后说一句,超喜欢面试现场系列,单凭它这专栏就值得买!

    作者回复: 谢谢鼓励:)
    其实就像文中说的,我们可以在平时多积累问题,多积累解决问题的案例,这样就不会大脑空白了~ :)

    2019-11-04
    1
  • 海罗沃德
    這講內容相當實用,檢討了一下之前我們遇到的一個live site issue,重新復盤了一下,我們系統在AWS上部署,一個新業務需要用到SQS(AWS的簡單消息對列服務),上線之前我測試了所有case萬無一失,剛上線也非常順利,但是我們系統每小時會有一個調用峰值,就在第一個峰值上系統飄紅,下游系統無流量

    通過下游沒有流量,初步判斷問題是在我們的service中,打開日誌發現AWS client拋了大量異常,異常內容是too many visible message,排查代碼發現是在使用AWS SQS client時候為了加快消費速度,開了10個線程來消費隊列,SQS的message有一個中間狀態叫invisible,當時這個狀態過期時間是10分鐘(SQS最大值),而十個線程在處理低流量請求時不會有問題,高流量時會迅速讓invisible數量上升到SQS上線,後續的任何操作都會拋異常

    當時的處理方式是在線程處理是增加個sleep拖慢處理速度,但是本來就是為了加快處理開了這麼多線程,這樣做就沒意義

    學完今天的課程,我回頭看了一下AWS的源碼,發現AWS client在調用SQS時就是單純的發request,而標記invisible的動作應該是在server端,因此client不能感知sever端invisible已經上限了,而我們代碼使用long polling不斷的調用client,client在處理完刪除message時候也有一個異步時間差,這就導致invisible數量快速累積

    其實目前線上的解決方案在更大流量情況下還是可能導致同樣問題(大流量導致處理事件比sleep時間長
    2019-11-12
  • 阿卡牛
    有场景直接上,没有场景创造场景也要上,千万别怂,底线是不能说谎:)
    2019-11-05
  • 良记
    老师这么一问,我也说发现了自己项目上的不足。每次做项目都是上线完了之后就换一个地方,继续做。这种核心的问题,指标完全不知道,也不知道能怎样提高。
    2019-11-05
  • longslee
    如果我把老师的经验吹给面试官听他会反应过来么😄

    作者回复: :)

    2019-11-04
    1
  • xu晓晨
    这些东西还是得有场景呀。面试的时候答不上这类问题 还是因为平时工作中没有接触过这种问题。
    2019-11-04
  • 吃饭饭
    从数据出发才能体现程序的价值
    2019-11-04
  • 小喵喵
    1.性能核心指标是我的痛,比如并发是如何回答QPS和TPS分别是多少合适,一般相关的硬件设施又是怎么样的?
    2.老师能不能多举例几个案例呢?

    作者回复: 在第30节中我详细介绍吧,留言中篇幅有限,其实一般是请求量、错误量、响应时间,当然不同的组件还有一些独特的监控

    2019-11-04
收起评论
10
返回
顶部