深入理解消息中间件RabbitMQ
现在的市面上有很多MQ可以选择,比如ActiveMQ、ZeroMQ、Appche Qpid、Kafka,那问题来了为什么要选择RabbitMQ?
- 除了Qpid,RabbitMQ是唯一一个实现了AMQP标准的消息服务器;
- 可靠性,RabbitMQ的持久化支持,保证了消息的稳定性;
- 高并发,RabbitMQ使用了Erlang开发语言,Erlang是为电话交换机开发的语言,天生自带高并发光环,和高可用特性;
- 集群部署简单,正是应为Erlang使得RabbitMQ集群部署变的超级简单;
- 社区活跃度高,根据网上资料来看,RabbitMQ也是首选;
消息协议
在理解消息中间件之前,首先需要了解常见的消息协议。
- 高级消息队列协议即Advanced Message Queuing Protocol(AMQP)是一个用于统一面向消息中间件实现的一套标准协议,其设计目标是对于消息的排序、路由(包括点对点和订阅-发布)、保持可靠性、保证安全性。
- 流文本定向消息协议(STOMP),由Codehaus开发,基于文本的消息的传输协议,使用类似JMS的目的地语义;
- 可扩展消息与存在协议(XMPP),一种基于XML的开放式即时通信协议;
- 消息队列遥测传输(MQTT),一种轻量级订阅-发布协议。
AMQP概念
Broker:简单来说就是消息队列服务器实体。
Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列。
Queue:消息队列载体,每个消息都会被投入到一个或多个队列。
Binding:绑定,它的作用就是把exchange和queue按照路由规则绑定起来。
Routing Key:路由关键字,exchange根据这个关键字进行消息投递。
vhost:虚拟主机,一个broker里可以开设多个vhost,用作不同用户的权限分离。
producer:消息生产者,就是投递消息的程序。
consumer:消息消费者,就是接受消息的程序。
channel:消息通道,在客户端的每个连接里,可建立多个channel,每个channel代表一个会话任务。
Exchange交换机的作用根据具体的路由策略分发到不同的队列中,交换机有四种类型。
- Direct exchange(直连交换机)是根据消息携带的路由键(routing key)将消息投递给对应队列
- Fanout exchange(扇型交换机)将消息路由给绑定到它身上的所有队列
- Topic exchange(主题交换机)队列通过路由键绑定到交换机上,然后,交换机根据消息里的路由值(使用了通配符来管理消费者接收消息),将消息路由给一个或多个绑定队列
符号#:匹配一个或者多个词lazy.# 可以匹配lazy.irs或者lazy.irs.cor
符号*:只能匹配一个词lazy.* 可以匹配lazy.irs或者lazy.cor - Headers exchange(头交换机)类似主题交换机,但是头交换机使用多个消息属性来代替路由键建立路由规则。通过判断消息头的值能否与指定的绑定相匹配来确立路由规则。
消息中间件的作用
1.异步解耦,Http协议是基于请求与响应,可以理解未同步方式进行;消息中间件则可以实现异步解耦,异步通信使得生产者和消费者得以充分执行自己的逻辑而无需等待
2.流量削峰,把高峰期大量的请求存储下来慢慢交给后台进行处理,例如秒杀业务
3.消息可靠传输,设置消息持久化,使得消息只有在被消费之后才会删除
消息队列RabbitMQ的五种形式队列
1.点对点(简单)的队列
2.工作(公平性)队列模式;消费者空闲的时候会发送下一条信息
3.发布订阅模式 Fanout
4.路由模式 RoutingKey
5.通配符模式 Topics
常见问题
-
保证生产者消息发送可靠
生产者发送消息出去之后,不知道到底有没有发送到RabbitMQ服务器, 默认是不知道的。而且有的时候我们在发送消息之后,后面的逻辑出现异常等;此时这条消息就不应该发送。
解决方案: 1.AMQP 事务机制 2.Confirm 模式
事务模式:
txSelect 将当前channel设置为transaction模式
txCommit 提交当前事务
txRollback 事务回滚 -
消费者在消费消息的时候,如果消费者业务逻辑出现程序异常,这时候应该如何处理?
答案:使用消息重试机制。(演示重试机制)
如何合适选择重试机制:
情况1: 消费者获取到消息后,调用第三方接口,但接口暂时无法访问,是否需要重试? (需要重试机制)
情况2: 消费者获取到消息后,抛出数据转换异常,是否需要重试?(不需要重试机制)需要发布进行解决。 -
消费者如果保证消息幂等性,不被重复消费
产生原因:网络延迟传输中,消费出现异常或者是消费延迟消费,会造成MQ进行重试补偿,在重试过程中,可能会造成重复消费。
消费者如何保证消息幂等性,不被重复消费
解决办法:
①使用全局MessageID判断消费方使用同一个,解决幂等性。
②或者使用业务逻辑保证唯一(比如订单号码)