小码农一枚 2019-06-21
其实在业界没有统一的标准,一般认为,消息中间件属于分布式系统中的一个子系统,关注数据的发送与接收,利用高效可靠的异步消息传递机制对分布式中的子系统进行整合。
为什么要用消息中间件:
假设一个电商交易场景,用户下单有调用库存系统减库存,然后调用物流系统进行发货,如果交易、库存、物流属于一个系统,那么就是接口调用,但是随着系统的发展,各个模块会越来越强大,业务逻辑也会越来越复杂,必然也是要做服务化及业务拆分的。这个时候就要考虑到系统如何进行交互,第一个反应就是就是RPC(Remote Procedure Call)。系统继续发展,一笔交易可能需要几十个接口来执行业务,比如短信系统、邮件系统等等。这时候就需要消息中间件了。
消息中间件主要是解决分布式系统中消息的传递,同时为分布式系统其它子系统提供了伸缩性和扩展性,为系统带来了:低耦合,异步通信、缓冲的能力
名词解释:
和RPC有什么区别?
RPC和消息中间件的很大差异就在 “依赖性” 和 “同步性”
比如短信服务并不是交易环境必须的,并不影响下单,不存在强依赖,所以交易系统不需要依赖短信服务。 消息中间件出现出现以后对于交易系统可能调用库存中心等强依赖系统执行业务,之后发布一条消息(这条消息存储在消息中间件中)。像消息通知服务、数据统计服务都是依赖于消息中间件去消费这条消息来完成业务逻辑的处理。
RPC的方式是典型的同步方式,让远程调用像本地调用。消息中间件事异步调用方式。消息队列是系统级的,模块级的的通信,RPC是是对象级,函数级的通信 他们有个共同点就是都是分布式下的通信方式
消息中间件使用场景:
1)异步处理:
场景说明:用户注册后,需要发送注册邮件和注册短信。传统的方法有两个,1、是串行,2、并行 复制代码
引入消息队列业务处理方式:
引入消息队列,将不是必须的业务逻辑做异步处理。
2)应用解耦:
场景说明:用户下单后,订单系统需要通知库存系统。传统的做法是订单系统直接调用库存系统接口。
传统模式的缺点:
引入消息队列后解决方案
这样在下单的时候库存系统不能正常使用也不会影响到用户下单,因为下单之后订单系统把信息写入消息队列后就不管其他后续操作了,从而实现订单系统与库存系统的解耦。
流量削峰:
流量削峰是队列常用的使用场景,一般秒杀系统或者团购中广泛使用 应用场景:秒杀活动时会因为流量过大,用户流量暴增,导致应用崩溃。解决这个问题就是在中间加入消息队列,这样可以 控制当前活动的人数;缓解短时间的涌入大量的流量压垮系统;
用户请求后,服务器接收后,先写入消息队列,假如消息队列长度超过的最大数量,则抛弃用户请求或者跳转到其他页面;秒杀信息根据消息队列中的请求信息再做后续处理。
日志处理:
日志处理是指将消息队列用在日志处理中,比如说kafka的应用,解决大量日志传输的问题,架构简化如下
日志采集客户端负责采集,定时写入kafka消息队列:消息队列负责消息的接收、存储、转发;日志处理应用负责订阅及消费消息队列中的日志数据。
end:如果你觉得本文对你有帮助的话,记得关注点赞转发,你的支持就是我更新动力。