为什么要选择RabbitMQ?而不是ActvieMQ,优势在哪里?直接上图来介绍:
direct
direct类型的Exchange路由规则也很简单,它会把消息路由到那些binding key与routing key完全匹配的Queue中。
以上图的配置为例,我们以routingKey=”error”发送消息到Exchange,则消息会路由到Queue1(amqp.gen-S9b…,这是由RabbitMQ自动生成的Queue名称)和Queue2(amqp.gen-Agl…);如果我们以routingKey=”info”或routingKey=”warning”来发送消息,则消息只会路由到Queue2。如果我们以其他routingKey发送消息,则消息不会路由到这两个Queue中。
RPC
MQ本身是基于异步的消息处理,前面的示例中所有的生产者(P)将消息发送到RabbitMQ后不会知道消费者(C)处理成功或者失败(甚至连有没有消费者来处理这条消息都不知道)。 但实际的应用场景中,我们很可能需要一些同步处理,需要同步等待服务端将我的消息处理完成后再进行下一步处理。这相当于RPC(Remote Procedure Call,远程过程调用)。在RabbitMQ中也支持RPC。
RabbitMQ 中实现RPC
的机制是:
- 客户端发送请求(消息)时,在消息的属性(
MessageProperties
,在AMQP
协议中定义了14中properties
,这些属性会随着消息一起发送)中设置两个值replyTo
(一个Queue
名称,用于告诉服务器处理完成后将通知我的消息发送到这个Queue
中)和correlationId
(此次请求的标识号,服务器处理完成后需要将此属性返还,客户端将根据这个id了解哪条请求被成功执行了或执行失败) - 服务器端收到消息并处理
- 服务器端处理完消息后,将生成一条应答消息到
replyTo
指定的Queue
,同时带上correlationId
属性 - 客户端之前已订阅
replyTo
指定的Queue
,从中收到服务器的应答消息后,根据其中的correlationId
属性分析哪条请求被执行了,根据执行结果进行后续业务处理
总结
本文介绍了RabbitMQ
中个人认为最重要的概念,充分利用RabbitMQ
提供的这些功能就可以处理我们绝大部分的异步业务了。
RabbitMQ 选型和对比
1.从社区活跃度
按照目前网络上的资料,RabbitMQ
、activeM
、ZeroMQ
三者中,综合来看,RabbitMQ
是首选。
2.持久化消息比较
ZeroMq
不支持,ActiveMq
和RabbitMq
都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了,消息不会丢失的机制。
3.综合技术实现
可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。
RabbitMq
/ Kafka
最好,ActiveMq
次之,ZeroMq
最差。当然ZeroMq
也可以做到,不过自己必须手动写代码实现,代码量不小。尤其是可靠性中的:持久性、投递确认、发布者证实和高可用性。
4.高并发
毋庸置疑,RabbitMQ
最高,原因是它的实现语言是天生具备高并发高可用的erlang
语言。
5.比较关注的比较, RabbitMQ 和 Kafka
RabbitMq
比Kafka
成熟,在可用性上,稳定性上,可靠性上, RabbitMq 胜于 Kafka (理论上)。
另外,Kafka
的定位主要在日志等方面, 因为Kafka
设计的初衷就是处理日志的,可以看做是一个日志(消息)系统一个重要组件,针对性很强,所以 如果业务方面还是建议选择 RabbitMq
。
还有就是,Kafka
的性能(吞吐量、TPS
)比RabbitMq
要高出来很多。
选型最后总结:
如果我们系统中已经有选择 Kafka ,或者 RabbitMq ,并且完全可以满足现在的业务,建议就不用重复去增加和造轮子。
可以在 Kafka 和 RabbitMq 中选择一个适合自己团队和业务的,这个才是最重要的。但是毋庸置疑现阶段,综合考虑没有第三选择。
上面废话比较多,都是copy过来的,简单的介绍一下几个特征:高可用、PRC、高并发、支持半脑裂问题。最主要的是它是spring boot 和spring cloud首选,官方推荐,3分钟快速集成才是重点。废话不多说,直接上配置:
1.application:
2.生产发送者(一对多)
3.消费者
4.topic 主题发送