百度推广建设网站是不是合发,注册新公司网上怎么核名,vue做直播网站,手机app开发制作多少钱消息队列是系统设计中存在时间最长的中间件之一#xff0c;从系统有通信需求开始#xff0c;就产生了消息队列。
消息队列的使用场景
在日常系统设计与实现的过程中#xff0c;下面3种场景会涉及到消息队列#xff1a;
异步处理流量控制服务解耦
异步处理
典型的应用场…消息队列是系统设计中存在时间最长的中间件之一从系统有通信需求开始就产生了消息队列。
消息队列的使用场景
在日常系统设计与实现的过程中下面3种场景会涉及到消息队列
异步处理流量控制服务解耦
异步处理
典型的应用场景是秒杀系统它要解决的核心问题是如何利用有限的服务器资源尽可能多的处理短时间内的海量请求。
一般秒杀系统会包含下面的步骤
风险控制库存锁定生成订单短信通知更新统计数据
在没有引入消息队列时上述5个步骤会依次执行在引入消息队列后只要风险控制和库存锁定完成那么就可以返回用户秒杀成功后面的步骤和秒杀没有直接关联我们可以在库存锁定完成后向消息队列中发送用户和商品信息之后的子系统会读取消息队列的消息进行后续处理。
这秒杀场景中引入消息队列带来两个好处
可以更快的返回结果。减少等待实现步骤之间并行处理提升性能。
流量控制
一个设计健壮的程序有自我保护能力在海量请求下可以在自身能力范围内尽可能多的处理请求拒绝处理不了的请求并且保证自身运行正常。
还是以秒杀场景为例我们可以进一步调整设计思路使用消息队列隔离网关和后端服务
网关收到请求后将请求放入到请求消息队列。后端服务从请求消息队列中获取APP请求完成后续秒杀处理过程然后返回结果。
这样当海量请求到来时不会直接冲击到后端的秒杀服务而是堆积在消息队列中后端服务按照自己的最大处理能力从消息队列中消费请求进行处理。对于超时的请求可以直接丢弃APP可以将其视为秒杀失败。
这其实就是流量控制中的“漏桶流量控制”网关在这里充当了”漏桶“的角色。
这样的设计可以根据下游的处理能力自动调节流量达到”削峰填谷“的目的但是有两个问题
增加了系统调用链环节导致总体响应时间变长。上下游系统都要将同步调用改为异步调用增加了系统复杂度。
我们还可以使用“令牌桶”来控制流量。它的原理是单位时间内只发放固定数量的令牌到令牌桶中规定服务在处理请求前必须先从令牌桶中拿出一个令牌如果令牌桶中没有令牌则拒绝请求。这样就保证在单位时间内能处理的请求不超过发放令牌的数量。
令牌桶可以简单地用一个有固定容量的消息队列一个“令牌发生器”来实现令牌发生器按照预估的处理能力匀速生产令牌并放入令牌队列如果队列满了就丢弃令牌网关在收到请求时到令牌队列消费一个令牌获取到令牌则继续调用后端服务如果获取不到则等待或者返回失败。
服务解耦
消息队列还可以起到服务解耦的作用例如订单是电商系统中比较核心的数据当创建一个新订单时
支付系统需要发起支付流程风控系统需要审核订单的合法性客服系统需要给用户发送短信经营分析系统需要更新统计数据。。。。。
这些订单下游的系统都需要实时获取订单数据随着业务发展这些订单下游系统会不断增加不断变化并且每个系统可能只需要订单数据的一个子集负责订单服务的开发团队不得不花费很大精力应付不断增加变化的下游系统不停修改调试订单系统与这些下游系统的接口。任何一个下游系统接口变更都需要订单模块重新上线这是不可接受的。
问题的解决办法是所有的下游系统可以通过消息队列来和订单系统通信引入消息队列后订单服务在订单变化时发送一条消息到消息队列所有订阅相关主题的下游系统都可以实时获得一份完整的订单数据。
这样无论下游系统如何变化订单服务都无需做任何更改实现了订单服务和下游服务的解耦。
除了上述三种典型场景消息队列还可以应用到
作为发布/订阅系统实现一个微服务级系统间的观察者模式连接流计算任务和数据用于将消息广播给大量接收者
消息队列并不是“银弹”下面的场景就不适合用消息队列
实时响应要求高数据强一致性要求高不能容忍数据或者消息丢失
在引入消息队列后也可能带来一些新的问题包括
异步通信带来的延迟问题增加了系统设计的复杂度可能会产生数据不一致的问题
