深入理解消息中间件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判断消费方使用同一个，解决幂等性。
  ②或者使用业务逻辑保证唯一（比如订单号码）