《RabbitMQ 实战指南》读书笔记

RabbitMQ的模型架构介绍
可以把消息传递的过程想象成:当你将一个包裹送到邮局,邮局会暂存并最终将邮件通过邮递员送到收件人的手上, RabbitMQ 就好比由邮局、邮箱和邮递员组成的一个系统。
  • producer:生产者(发件人),消息的投递方
  • broker:消息中间件的中间节点(邮局,也可以看作一台Rabbit MQ服务器)
  • exchange:交换器(中分拣员),它根据分发规则,匹配查询表中的routing key,分发消息到queue中去。
  • queue:队列(收件人查收信件时的邮箱)
  • routingkey:路由键(填写在包裹上的地址),在某些情形下, RoutingKey 与BindingKey 可以看作同一个东西。
  • bing:绑定(???),通过绑定将exchange和queue关联起来,某些情况下会分配一个bandingkey(direct、topic)
  • bandingkey:绑定键(于包裹的目的地)
  • comsumer:消费者(收件人),消息的消费方
Exchange分类
  • fanout(广播,一对多)、不用配置RoutingKey 和 BandingKey,交换器会无视BindingKey将消息路由到所有绑定到该交换器的队列中。
  • direct(直连,一对一)、RoutingKey 和 BandingKey 必须相同,消息才能正常发送到queue
  • topic(主题,模糊,一对多)、RoutingKey 和 BandingKey 做模糊匹配,两者不是相同的
  • headers(基本上不用)
Routingkey中可以包含两种通配符
  • “.”  字符串分割符
  • “#” 通配任何零个或多个word
  • “*” 通配任何单个word

connection 和 channel 之间的关系
Connection 可以用来创建多个Channel 实例,但是Channel 实例不能在线程问共享,应用程序应该为每一个线程开辟一个Channel 。某些情况下Channel 的操作可以并发运行,但是在其他情况下会导致在网络上出现错误的通信帧交错,同时也会影响友送方确认( publisherconfrrm)机制的运行,所以多线程问共享Channel 实例是非线程安全的RabbitMQ 采用类似NIO的做法,选择TCP 连接复用,不仅可以减少性能开销便于管理。同时RabbitMQ 可以确保每个线程的私密性,就像拥有独立的连接一样。当每个信道的流量不是很大时,复用单一的Connection 可以在产生性能瓶颈的情况下有效地节省TCP 连接资源。

每个线程把持一个信道(channel),所以信道复用了Connection 的TCP 连接。当信道本身的流量很大时,这时候多个信道复用一个Connection 就会产生性能瓶颈,进而使整体的流量被限制了。此时就需要开辟多个Connection ,将这些信道均摊到这些Connection 中,Connection 可以用来创建多个Channel 实例,但是Channel 实例不能在线程问共享,应用程序应该为每一个线程开辟一个Channel 。某些情况下Channel 的操作可以并发运行,但是在其他情况下会导致在网络上出现错误的通信帧交错,同时也会影响友送方确认( publisher confrrm)机制的运行,所以多线程问共享Channel 实例是非线程安全的。


AMQP 生产者发送消息流程
AMQP 消费者发送消息流程

高级参数
  • mandatory 参数
  • alternate-exchange 备份交换机
  • 过期时间 TTL
    • 设置消息ttl:x-message-ttl
    • 设置队列ttl:x-expires
  • 死信队列 x-dead-letter-exchange
  • 延迟队列,没有直接支持,通过DLX 和TTL 模拟出延迟队列的功能。
  • 优先级队列 x-max-priority

发表评论