Rabbitmq相关

Rabbitmq相关知识点

相关概念：

消息队列可以被看做是一个存放消息的容器，当我们需要使用消息的时候可以取出消息供自己使用。

消息队列是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。

目前使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ。

消息队列的应用场景：

异步处理，应用解耦，流量削峰，日志处理

日志处理：（主要是Kafka）

日志采集客户端，负责日志数据采集，定时写受写入Kafka队列；

Kafka消息队列，负责日志数据的接收，存储和转发；

日志处理应用：订阅并消费kafka队列中的日志数据。

消息队列实现：

简单队列：

工作队列：

轮询发布：

一个生产者生产消息到队列，多个消费者从队列依次轮询消费消息。

这里的轮询机制是你一个，我一个轮询分发机制，比如我有50个消息，

无论C1、C2的消费处理能力如何，最后他们都会按照你一个我一个的

方式都拿到25个消息消费，这就是所谓的轮询，轮着来的意思。

公平发布：

使用公平发布需要关闭自动应答ack

 

消息应答与消息持久化

autoAck = true；自动确认模式，一旦将消息分发给消费者，就会从内存中删除；

在这种情况下，如果消费者宕机，就会丢失正在处理的消息。

autoAck = false。手动模式，如果有一个消费者宕机，就会交给其他消费者。

RabbitMQ支持消息的持久化，也就是数据写在磁盘上。

队列和交换机有一个创建时候指定的标志durable。durable的唯一含义就是具有这个标志的队列和交换机会在重启之后重新建立，它不表示说在队列当中的消息会在重启后恢复。

消息队列持久化包括3个部分：

1、exchange持久化，在声明时指定durable => true
2、queue持久化，在声明时指定durable => true
3、消息持久化，在投递时指定delivery_mode=> 2（1是非持久化）

@Queue

当所有的消费客户端都断开连接，是否自动删除队列

@Exchange

当所有的绑定队列都不再使用，是否 自动删除交换器

如果exchange和queue都是持久化的，那么它们之间的binding也是持久化的。如果exchange和queue两者之间有一个持久化，一个非持久化，就不允许建立绑定。

注意：一旦创建了队列和交换机，就不能修改其标志了。例如，如果创建了一个non-durable的队列，然后想把它改变成durable的，唯一的办法就是删除这个队列然后重现创建。

订阅模式

1.一个消费者多个生产者；

2.每个消费者都有自己的队列；

3.生产者没有直接把消息发送到队列，而是发到交换机  转发器 exchange；

4.每个队列都要绑定到交换机上。

路由模式

比发布订阅模式多了一个路由选择，称为路由key。

路由key指定一个名称。

队列在绑定到交换机时，还要设置这个路由key。

消息的队列中不是所有的消息了，交换机会根据消息的路由key，选择性将消息传递给消息队列。

主题模式

在路由模式基础上，让路由key可以使用通配符。

相当于进行分类。灵活程度更高些。

隐患：容易误伤

消息确认机制

事务机制

通过AMQP事务机制实现，这也是AMQP协议层面提供的解决方案

RabbitMQ中与事务机制有关的方法有三个：txSelect(), txCommit()以及txRollback(),

txSelect用于将当前channel设置成transaction模式，

txCommit用于提交事务，

txRollback用于回滚事务，

在通过txSelect开启事务之后，我们便可以发布消息给broker代理服务器了，如果txCommit提交成功了，则消息一定到达了broker了，如果在txCommit执行之前broker异常崩溃或者由于其他原因抛出异常，这个时候我们便可以捕获异常通过txRollback回滚事务了。

可以看到带事务的多了四个步骤：

• client发送Tx.Select
• broker发送Tx.Select-Ok(之后publish)
• client发送Tx.Commit
• broker发送Tx.Commit-Ok

通过将channel设置成confirm模式来实现

生产者通过调用channel的confirmSelect方法将channel设置为confirm模式

信道进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，broker就会发送一个确认给生产者（包含消息的唯一ID）,这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会将消息写入磁盘之后发出，broker回传给生产者的确认消息中deliver-tag域包含了确认消息的序列号，此外broker也可以设置basic.ack的multiple域，表示到这个序列号之前的所有消息都已经得到了处理

客户端实现生产者confirm有三种编程方式：

普通confirm模式：每发送一条消息后，调用waitForConfirms()方法，等待服务器端confirm。实际上是一种串行confirm。
批量confirm模式：每发送一批消息后，调用waitForConfirms()方法，等待服务器端confirm。
异步confirm模式：提供一个回调方法，服务端confirm了一条或者多条消息后Client端会回调这个方法。

confirm串行

confirm批量

confirm异步

异步confirm模式中Channel对象提供的ConfirmListener()回调方法只包含deliveryTag（当前Chanel发出的消息序号），

需要为每一个Channel维护一个unconfirm的消息序号集合，每publish一条数据，集合中元素加1，每回调一次handleAck方法，unconfirm集合删掉相应的一条（multiple=false）或多条（multiple=true）记录

参考链接：

https://www.cnblogs.com/wu-cai/p/7373520.html

https://blog.csdn.net/u013256816/article/details/55515234/

https://www.jianshu.com/p/36a7775b04ec