精选留言(16)

• 
  星空123

  2019-11-07

  我们的售货机系统是每天有几个时间段请求会成倍的增加。像每天中午11点-12点半。晚上的5点半到6点还有晚上21点到24点。 这几个时间段的订单量是比较大的。 我们第一次碰到的问题是机器代理商反馈有客户购买了，但是出货很慢。并且还发现了系统出现了大量的订单退款。我们开始从日志方面看，发现了好像系统的处理速度变慢了。并且这些退款的订单都是出货了的。这样的话，系统就亏大了。并且随着高峰的到来，系统开始报mysql的连接数用完了。导致数据库写入和更新操作都没法做。我们立刻把生产系统停掉。老板也是致电我们，搞不好就滚蛋。然后我们连夜对机器下单这块的业务做优化, 减少访问mysql的压力。并且把消息处理类中用到的连接池的大小给扩大一倍。 就这样消停了几天。 但是由于系统内设备不断增加，隔了大概一周左右，晚上10点左右又来投诉说这个问题，我们犹如惊弓之鸟，立马打开日志查看。还是这个问题。 而且以前忽略了微信的支付回调如果处理不及时，微信会向回调地址重复发送订单结果的通知。这个是导致系统崩盘的重要的点之一。 关键这次发现了最重要的问题：系统在处理终端设备订单的微信支付宝的回调在做异步处理的时候，由于回调部分没有做并发处理。 导致数据库的表被锁住，引发的回调部分业务要处理堆积，系统处理不过来。恶性循环，消息越多，越处理不过来。越处理不过来，支付回调部分越堆积。导致我们的机器又出货，又退款。 最终我们花了一夜时间把微信支付回调做了多线程处理。系统才稳定了下来。 第二天把支付宝的回调处理部分也做了多线程处理。一段时间内没有问题。 现在系统加了redis做缓存。但是缓存刚上线也是有不少问题的。但是我们慢慢解决了。 目前的系统算是比较稳定了。 阿里云的双核4G服务器 支撑我们系统的600多台设备。 老师文章中提到的方案对我们后面工作不论是在这个公司，还是以后都是有很大启发的。

  展开

  作者回复: 谢谢肯定

  共 5 条评论

  29
• 
  阿卡牛

  2019-11-05

  有场景直接上，没有场景创造场景也要上，千万别怂，底线是不能说谎:)

  共 1 条评论

  18
• 
  斐波那契

  2019-11-04

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

  作者回复: 其实有时候只是自己比较容易容忍问题而已：） 比如一些偶发的超时，重启时的慢请求，系统中有没有出现，有没有追查根本的原因

  共 4 条评论

  16
• 
  大雄

  2019-11-04

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

  展开

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

  

  7
• 
  helloworld

  2020-06-09

  我的总结： 1. 在面试的时候确实应该把话题转移到自己熟悉的技术上，但是前提是自己一定要对自已所谓的熟悉的技术不仅要熟练，更要超出平均水平 2. 项目当中其实没有很多高并发的实战的，自己设想一个和自己项目有关联的就行，前提是不能生搬硬套

  

  3
• 
  钱

  2020-04-25

  有上亿人都用到的项目固然好，没有其实可以自己造一个，比如：一亿条数据的一个文件，怎么高效的落库。

  作者回复: 👍

  共 2 条评论

  3
• 
  小高

  2020-11-24

  干货满满，谢谢唐老师，准备拿下高并发这块硬骨头

  

  2
• 
  Alex Liu

  2020-03-26

  受益匪浅

  作者回复: 谢谢

  

  1
• 
  海罗沃德

  2019-11-12

  這講內容相當實用，檢討了一下之前我們遇到的一個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時間長

  展开

  

  1
• 
  longslee

  2019-11-04

  如果我把老师的经验吹给面试官听他会反应过来么😄

  作者回复: ：）

  共 2 条评论

  1
• 
  xu晓晨

  2019-11-04

  这些东西还是得有场景呀。面试的时候答不上这类问题 还是因为平时工作中没有接触过这种问题。

  

  1
• 
  小喵喵

  2019-11-04

  1.性能核心指标是我的痛，比如并发是如何回答QPS和TPS分别是多少合适，一般相关的硬件设施又是怎么样的？ 2.老师能不能多举例几个案例呢？

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

  

  1
• 
  罗青

  2022-06-22

  strace这些问题排查工具是如何学到的呢？

  

  
• 
  亚林

  2021-11-19

  我们项目涉及到高并发场景比较少，我们就问他是怎么样使用Google的，已经使用Google需要了解到的技术

  

  
• 
  良记

  2019-11-05

  老师这么一问，我也说发现了自己项目上的不足。每次做项目都是上线完了之后就换一个地方，继续做。这种核心的问题，指标完全不知道，也不知道能怎样提高。

  共 1 条评论

  
• 
  吃饭饭

  2019-11-04

  从数据出发才能体现程序的价值

  

  