前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MQ实战-削峰填谷

MQ实战-削峰填谷

作者头像
用户1212940
发布2022-04-13 16:57:09
1.2K0
发布2022-04-13 16:57:09
举报
文章被收录于专栏:LambdaLambda

对于突然到来的大量请求,您可以配置流控规则,以稳定的速度逐步处理这些请求,起到“削峰填谷”的效果,从而避免流量突刺造成系统负载过高。

场景

请求的到来,往往是没有规律的。

例如,某应用的处理能力是每秒 10 个请求。在某一秒,突然到来了 30 个请求,而接下来两秒,都没有请求到达。在这种情况下,如果直接拒绝 20 个请求,应用在接下来的两秒就会空闲。所以,需要把请求突刺均摊到一段时间内,让系统负载保持在请求处理水位之内,同时尽可能地处理更多请求,从而起到“削峰填谷”的效果。

11464886-dddea79ecca299d3.png
11464886-dddea79ecca299d3.png

image.png 上图中,红色的部分代表超出消息处理能力的部分。观察得出,消息突刺往往都是瞬时的、不规律的,其后一段时间系统往往都会有空闲资源。把红色的那部分消息平摊到后面空闲时去处理,这样既可以保证系统负载处在一个稳定的水位,又可以尽可能地处理更多消息。通过配置流控规则,可以达到消息匀速处理的效果。

分析问答

1. 问:站点与服务,服务与服务上下游之间,一般如何通讯?

答:有两种常见的方式 一种是“直接调用”,通过RPC框架,上游直接调用下游:

11464886-c55c8231e0a3f949.png
11464886-c55c8231e0a3f949.png

还有一种,在某些业务场景之下,可以采用“MQ推送”,上游将消息发给MQ,MQ将消息推送给下游。

11464886-b6dcf69c06a906dd.png
11464886-b6dcf69c06a906dd.png

2. 问:以上两种为什么为有流量冲击?

答:不管采用“直接调用” 还是 “MQ推送”,都有一个很大的缺点,下游消息接收方无法控制到达自己的流量,如果调用方不断的调用且不限速,很有可能把下游服务压垮。

  • 举个例子: 秒杀业务 上游发起高并发的下单请求。 下游完成秒杀业务逻辑(库存检查 - 库存冻结 - 余额检查 - 余额冻结 - 订单完成 - 余额扣减 - 库存扣减 - 生成流水 - 余额解冻 - 库存解冻)。 上游下单业务简单,每秒发起10000+个请求,下游秒杀业务复杂,每秒只能处理2000+个请求,很有可能上游不限速的下单,导致下游系统被压垮,引起雪崩。

3. 问:MQ怎么改能缓冲流量? 答:由MQ-server 推(push)模式,改为 MQ-client(pull)为拉模式

11464886-cc579bcfb8b13d95.png
11464886-cc579bcfb8b13d95.png

MQ-client根据自己的处理能力,每隔一定时间,或者每次拉取若干条消息,实施流控,达到保护自身的效果。并且这是MQ提供的通用功能,无需上下游修改代码。

4. 问:如果上游发送流量过大,MQ提供拉模式确实可以起到下游自我保护的作用,会不会导致消息在MQ中堆积? 答:下游MQ-client拉取消息,消息接收方能够批量获取消息,需要下游消息接收方进行优化,方能够提升整体吞吐量,例如:批量写。

结论

  • MQ-client提供拉模式,定时或者批量拉取,可以起到削平流量,下游自我保护的作用(MQ需要做的)
  • 要想提升整体吞吐量,需要下游优化,例如批量处理等方式(消息接收方需要做的)
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2019-07-15 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 场景
  • 分析问答
  • 结论
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档