什么是消息中间件?
消息中间件属于分布式系统中一个子系统,关注于数据的发送和接收,利用高效可靠的异步消息传递机制对分布 式系统中的其余各个子系统进行集成。
从RPC到消息中间件
什么是RPC?
RPC(Remote Procedure Call)是远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。
RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机,而服务提供程序就是一个服务器。首先,客户机调用进程发送一个有进程参数的调用信息到服务进程,然后等待应答信息。
简单来理解,RPC机制就是跨系统之间的方法调用。这个机制带来的问题就是数据同步。调用方在调用某个接口时,一定要等待被调用方执行完毕并反馈后才会继续执行。
消息中间件的优势
解耦
不管是程序还是模块之间,原本需要直接进行通信,现在添加一个消息中间件,可以进行间接通信。
主要体现在如下两点:
- 发送者和接受者不必了解对方、只需要确认消息
- 发送者和接受者不必同时在线
比如在线交易系统为了保证数据的最终一致,在支付系统处理完成后会把支付结果放到消息中间件里,通知订单系统修改订单支付状态。两个系统通过消息中间件解耦。(对于消息实时性要求不是特别高的场景使用非常频繁)
异步
消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道(主题或队列)上,消息接收者则订阅或是监听该通道。一条信息可能最终转发给一个或多个消息接收者,这些接收者都无需对消息发送者做出同步回应。整个过程都是异步的。
削峰填谷
我们的消费者往往都会存在消费性能瓶颈(往往受限于mysql消息持久化瓶颈)。如果使用在某一时间生产的信息过多,可能会将我们的消费者直接冲垮。
消息中间件像是一个巨大的蓄水池,将高峰期大量的请求存储下来。慢慢交给后台进行处理,对于秒杀业务来说尤为重要。
RPC与消息中间件的区别
同步变异步(保证高性能)
正如上面说的,在大数据量场景下,同步模式会给我们的程序性能带来极大的瓶颈。异步模式本身就是对高性能服务的一种体现。
耦合强变弱(保证高可用)
如果是 RPC 调用,生产者或消费者服务挂了,就会导致整个业务就挂了,这个就是耦合性过高导致的,而消息中间件进行了一次解耦,并且消息中间件本身具备高可用性,尽可能的保证了中间件在生产环境下不会彻底挂掉。
消息中间件的选型
如果我们的公司要引入mq,应该如何选型?
ActiveMQ的场景
用户访问量在 ActiveMQ 的可承受范围内,而且确实主要是基于解耦和异步来用的,可以考虑 ActiveMQ,也比较贴近 Java 工程师的使用习惯,但是ActiveMQ 现在停止维护了,同时 ActiveMQ 并发不高,所以业务量一定的情况下可以考虑使用。
RabbitMQ的使用场景
RabbitMQ 作为一个纯正血统的消息中间件,有着高级消息协议 AMQP 的完美结合,在消息中间件中地位无可取代,但是 erlang 语言让我们很难对源码进行研究与分析,出现使用异常难以通过我们自己去解决。对公司而言,底层技术很难去控制,但是确实是开源的,有比较稳定的支持,活跃度也高。
同时,RabbltMQ的吞吐量较高,并且延时性较低。在中小型公司与比较常见的业务中使用广泛。
kafka的使用场景
kafka可以保证数据的绝对稳定性,并且天然的支持分布式,可以通过添加机器不断地对吞吐量进行提高。
kafka的功能相对于普通mq来说更加丰富。它不仅仅只能做消息的传递,它可以进行消息的持久化保存。
kafka经常被用来记录web用户或者app用户的各种活动,如浏览网页、搜索、点击等活动,这些活动信息被各个服务器发布到kafka的topic中,然后消费者通过订阅这些topic来做实时的监控分析,亦可保存到数据库。
kafka也经常被用常用来记录运营监控数据。包括收集各种分布式应用的数据,生产各种操作的集中反馈,比如报警和报告。
用时,kafka也支持流式处理,可以对内部消息不断的做出汇总以及分析,可以根据分析结果提前改变一些消费逻辑等等。
因此kafka的应用场景绝不仅仅是消息的传递这么简单。在未来我们深入学习kafka后可以帮助我们更加深刻的理解kafka的应用场景。
RocketMQ的使用场景
对自己公司技术实力有绝对自信的,可以用 RocketMQ,但是 RocketMQ 诞生比较晚,并且更新迭代很快,这个意味着在使用过程中有可能会遇到很 多坑,所以如果你们公司 Java 技术不是很强,那么慎重使用。
不过现在RocketMQJava界的龙头老大阿里巴巴开发的,发展的非常迅猛,未来很可能会越来越稳定。