工作中其实已经用了多年的rabbitmq， 现在重新整理下rabbitmq的相关技术点。

特点

  • 基于erlang，支持高并发
  • 客户端语言支持广泛，重要的是还有相应的web管理界面，还有cli命令行管理工具
  • 可靠性高
    • 可以持久化，传输确认（事务机制，如果失败就重来），发布确认（发送者要等待接受者手动返回确认）
  • 性能高，比kafaka，rocketmq这种稍微差点，针对性场景不同。kafaka 大数据领域用的比较多，rocketmq电商领域用多比较多。

快速安装

1docker run -d  --name rabbit -p 15672:15672 -p 5672:5672  rabbitmq:3-management
  • 15672 管理web端口
  • 5672 通信端口
  • 25672 集群通信端口

amqp协议

Broker

接收和分发消息的应用，RabbitMQ Server就是Message Broker。

Virtual host

虚拟broker ，用于进行逻辑隔离，最上层的消息路由。一个Virtual Host里面可以有若干个Exchange和Queue，同一个Virtual Host 里面不能有相同名称的Exchange或Queue。

Connection

publisher/consumer和broker之间的TCP连接。断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。

Channel

Channel是在connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的Channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别 channel，所以Channel之间是完全隔离的。

Exchange

message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。

常用的类型有:

  • direct (point-to-point)
    • 类似单播，routingkey 和bindingkey完全匹配
  • topic (publish-subscribe) 路由匹配。（推荐，扩展性好)
    • 全匹配和direct一样
    • binding key中 # 代表任意个 单词
    • binding key中 * 代表一个单词
  • fanout(multicast)
    • 类似广播，转发到所有绑定交换机的queue
  • headers （不怎么用)
    • 请求头与消息头匹配，才能接受消息

Queue

消息队列、消息最终被送到这里等待consumer取走。

Binding

exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询表中，用于message的分发依据。把exchange和queue按照路由规则绑定起来。

Routing key

一个路由规则，可用它来确定如何路由一个特定消息。

生产者在将消息发送给Exchange的时候，一般会指定一个routing key，来指定这个消息的路由规则，而这个routing key需要与Exchange Type及binding key联合使用才能最终生效。在Exchange Type与binding key固定的情况下（在正常使用时一般这些内容都是固定配置好的），我们的生产者就可以在发送消息给Exchange时，通过指定routing key来决定消息流向哪里。RabbitMQ为routing key设定的长度限制为255 bytes。

Message

消息，服务器和应用程序之间传送的数据，由Properties和Body组成。Properties可以对消息进行修饰，比如消息的优先级、延迟等高级特性;Body则就是消息体内容。