为什么使用消息中间件

为什么要使用消息中间件

如有一个电商交易的场景,用户下单之后调用库存系统减库存,然后调用物流系统进行发货,如果刚开始交易,库存,物流都是属于一个系统,那么他们之间就是接口调用。但是随着系统的发展,各个模块业务越来越庞大、业务逻辑越来越复杂,这个时候就必然要做服务化和业务拆分。这个时候就需要考虑这些系统之间是如何交互的。首先想到的就是RPC(Remote Procedure Call),但是随着系统的发展,可能一笔交易后序需要调用几十个接口位于不同系统的接口,比如短信服务、邮件服务等等,这个时候就需要消息中间件来解决问题了。

消息中间件最突出的特点就是提供数据传输的可靠性和高效性,主要解决分布式的系统数据传输需求

消息队列的应用场景

消息中间件主要解决分布式系统数据传输的需求,同时提供数据传输的可靠性和高效性。

低耦合

低耦合:消息中间件在处理过程中插入了一个接口层,两边的处理过程都实现这接口,这允许你独立的扩展或是修改两边的处理过程,只要确保他们遵守同样的接口约束。

应用场景

用户下单后,订单系统需要通知库存系统。通常的做法是订单系统调用库存系统的接口。

为什么使用消息中间件_第1张图片

缺点:1.加入库存系统无法访问,则订单减库存将失败,从而导致订单失败。

2.库存系统更改了减库存的接口(例如修改了入参),订单系统需要进行相应的改变,订单系统会被影响。

引入消息队列之后:

订单系统,用户下单之后,订单系统完成持久化处理,并将消息写入消息队列,返回用户订单下单成功。

库存系统:订阅下单的消息,获取下单信息,进行库存操作。

如果在下单时库存系统不能正常使用。也不影响下单,因为下单之后订单系统写入消息队列之后不用关系其他操作,库存系统系统恢复之后,获取消息队列中的消息,进行减库存的操作。并且单独修改库存系统并不会影响到订单系统。

为什么使用消息中间件_第2张图片

 异步通信

异步通信:在很多时候应用不想也不需要立即处理消息。消息中间件提供了异步处理机制,允许应用把一些消息放入消息中间中,但并不立即处理它,之后需要的时候再慢慢处理。

应用场景

用户注册以后,需要发送注册邮件和注册短信,传统的方式有两种串行处理和并行处理。

串行处理:进注册信息写入数据库成功之后,发送注册短信再发送注册短信,三个任务完成之后返回客户端。假设每个业务节点使用50毫秒,不考虑网络等其他开销,总共花费150ms时间

为什么使用消息中间件_第3张图片

并行处理:将注册信息写入数据库成功之后,发送注册短信的同时发送注册邮件,三个任务完成之后返回给客户端。假设每个业务节点使用50ms,不考虑网络等开销,并行的时间为100ms。

虽然并行处理可以提高效率,但是由于发送短信和发送邮件对于我们正常使用应用来说是没有影响的,所以客户端不需要当它发送短信和邮件完成之后才提示用户注册成功,当成功写入数据库时,就可以返回了。

为什么使用消息中间件_第4张图片

 引入消息队列之后:将不是必须的业务逻辑(发送注册短信和注册邮件),进行异步处理。用户的响应时间=写入数据库时间+写入消息队列时间(可以忽略不计)

为什么使用消息中间件_第5张图片

 缓冲能力和流量削峰

缓冲能力和流量削峰:消息中间件通过一个缓冲层来帮助任务最高效率地执行,写入消息中间件的处理会尽可能快速。该缓冲层有助于控制和优化数据流过系统的速度。使用消息中间件能够使关键组件支撑突发访问压力,不会因为突发的超负荷请求而完全崩溃。

应用场景:

流量削峰一般在秒杀活动或团抢购活动中使用广泛,在秒杀活动中,一般会因为流量暴增,导致应用挂掉。为了解决这个问题一般在应用前端加入消息队列,可以控制活动的人数,可以缓解短时间内高流量。

传统模式:在下单的时候就往数据库中写入数据,但是如果并发量过高,可能就会宕机。

引入消息队列之后

为什么使用消息中间件_第6张图片

消息被写入消息队列之后,系统可以根据自己的消费能力来消费,比如每秒2000个数据写入数据库。

如果加入消息队列长度超过最大数量,则可以直接抛弃用户请求或挑战到错误页面。

参考博文:消息中间件概述https://zengyihong.blog.csdn.net/article/details/127019856什么是消息中间件https://blog.csdn.net/weixin_43561060/article/details/118195543

你可能感兴趣的:(《消息中间件》,微服务,分布式,中间件)