rabbitmq试用总结

组成结构，概念

具体参考：RabbitMQ基本概念 - 简书 

• 代理服务器（Message Broker）：接收和分发消息的应用，RabbitMQ Server就是消息代理服务器。
• 信道（channel）: 应用程序（生产与/或消费）和代理服务器之间TCP连接内的虚拟连接，解决TCP连接数量限制及降低TCP连接代价。每个信道有一个ID，其概念与“频分多路复用”类似。

官网demo入门

官网总文档 ，channel等内容在这里都能搜到，Documentation: Table of Contents — RabbitMQ

zzRabbitMQ Tutorials — RabbitMQhttps://www.rabbitmq.com/getstarted.html在mq向导中，把1-6个引导案例看完了，其实就是简单教你怎么用。

• 第一个传送一条消息
• 第二个发布给一个队列，启动两个消费者,一个消息只会被一个消费者消费，没指定exchange用默认的exchange，最好指定
• 第三个给订阅这个exchange的所有queue广播，exchange type fanout，代替第二个广播
• 第四个消费者把queue和exhcange间用routekey绑定，queue和exchange间可以绑定多种routekey,发消息也指定routekey ，两个key对上 就能消费，相当于订阅，在上一步的广播中抽取一部分子集进行消费。exchange type direct
• 第五个模糊订阅，上一个是完全匹配,exchange type topic
• 第六个，之前都只消费消息，没有返回数据，如果返回数据就相当于rpc调用。
• 第七个生产者消息发送确认，确认生产者是否把消息成功发送到broker，方法有：单条消息同步等待确认、批量同步等待确认、异步确认。三种方法各有适用场景。异步确认可以用map记录  发出的消息序号和消息内容的映射关系，一旦回调消息成功函数或失败ack函数，对map进行相应处理，但没有说怎么重发失败的消息

文档结尾说了，这些案例为了说明使用，省去了很多细节，不能用于生产，例如省略了连接管理，错误处理，连接恢复，并发性和度量标准集合等主题。此类简化代码不应被视为准备生产。

所以要看一下Publisher Confirms and Consumer Acknowledgements,，1-6案例最下方有链接，二要看一下怎么和spring结合使用。

Publisher Confirms and Consumer Acknowledgements

Consumer Acknowledgements and Publisher Confirms — RabbitMQ

这篇文档讲了消息确认。

消费者消息确认：

• 自动ack，broker发出消息就算是确认，不能保证可靠、但性能好。
• 消费者手动ack，单条确认，批量确认（确认大序号，小序号也被认为确认）。手动确认要注意消费者被大量消息淹没、导致消费者处理不过来的问题，手动确认要保证消费者能处理这么多消息。如果没确认，broker会一直重发消息、直到过了设置的消息有效期ttl
• 消费者拒绝确认，适用于是这个消费队列处理不过来了，会导致broker重发消息到其他队列。消息重新排列顺序规则看文档
• Qos,限制消费者未处理消息的数量，避免在消费者端出现无界缓冲区问题、避免消耗消费者的内存。可全局、针对频道设置，对吞吐量有影响
• 吞吐量是发送端到接收到每秒能处理的消息量，消费者手动ack和qos设置低都会影响吞吐量
• 消费者异常导致没有完成手动ack，如客户端的 TCP 连接丢失、消费者应用程序（进程）故障和通道级协议异常。broker会自动重排，会重发消息，当然检测异常需要时间，重发的消息Redeliveries 字段是true
• 客户端双重确认、未知标签，双重确认是确认了两次会报错，未知标签是确认一个频道里没有的消息会报错，所以接受消息的频道 和 回复ack的频道必须是同一个频道。(频道是伪连接，一个tcp很多频道，发消息是生产者发给broker，收消息是broker发给消费者，所以发消息和收消息可以是不同的频道)

生产者确认，这在demo7里也讲了。

• broker什么时候发确认，不同exchange类型时间不同，如路由消息在发送到队列后就发ack，持久化消息持久磁盘后才ack
• 如果broker要持久化消息，则生产者确认消息会在持久化到磁盘后才会发出，所以生产者发出消息后要延迟一会才能收到ack，建议生产者确认用异步
• 如果broker在持久化消息前就出故障把消息丢了怎么办，生产者要有确认机制、没收到消息就重新发
• 每个channel上消息标签最大为64bit,一般不会达到

总结来说，就是如何让保证消息发送到。分三个步骤

1.生产者发送到broker。一种方法是事务，这种方法性能不好，吞吐量低，但可以完全保证 生产者到broker这一段路程。另一种就是生产者confirm，这种方法性能好，但官网也没说怎么在失败后重发消息，网友案例有把失败的消息缓存，用定时任务重发006 rabbitmq生产者消息可靠投递实现_haishui2的专栏-CSDN博客

2.broker宕机，让broker持久化，把exchange、queue、message全部持久化到磁盘，三个持久化设置。另外持久化并没有把每条消息调用fsync，可能只是到了操作系统缓存，或者在broker收到消息后、持久化前就宕机了，所以要跟生产者确认机制结合使用

3.broker发送到消费者，用消费者ack，失败了broker会重传

参考​​​​​​【173期】面试官问：引入 RabbitMQ 后，你如何保证全链路数据 100% 不丢失？|rabbitmq|持久化|队列|重发|queue_网易订阅
 

项目使用spring

官网java案例用amqp-client依赖操作。

spring有spring AMQP，方便操作https://spring.io/projects/spring-amqp#overview

连接池：【RabbitMQ-3】连接池的配置_小胖学编程的博客-CSDN博客

到这就是mq的初步使用，但rabbitmq的功能不止于此，官网文档还有很多协议细节、分布式、监控等