基于java语言使用RabbitMQ开发过程记录

此处不再一一粘贴代码，只记录开发学习过程中遇到的一些问题和解决办法，还有一些理论知识，留着以后面试的时候不啦不啦~~

刚才使用简单队列实现了生产者和消费者模式（基于旧 的API和新的API两种方式）

简单队列

一个生产者对应一个消费者，耦合性高，无法实现让多个消费者共同消费一个生产者，而且若想修改队列名称，就得全部修改。

实际场景中，生产者生产消息很快，一般都是插入一条数据之类的；而消费者则需要根据业务逻辑处理很多流程，所以简单队列的一对一场景满足不了现实的需要，如果同时起两个简单队列，就会发现两个消费者所接收的消息数量一致，不管它们各自消费一个消息需要多久，它们接收的消息数量都是一样的，均分的，轮询分发，round-robin，是一次全部发送出去，不管消费者有没有处理完成；

若一开始生产者给每一个消费者都只发一个消息，等消费者处理完成以后通知生产者再发送下一个，这样就提高整体的效率。这种叫做公平分发。公平分发就不能使用自动应答，而需要手动应答，由消费者在消费完成的时候再应答。

生产者和消费者都要声明：

消费者的应答模式

以及在处理完成（callback）最后手动应答

 

消息应答（针对于消费者）

若是自动应答，即生产者将消息发送出去，rabbitMq将消息分发给消费者之后，就会从内存中删除；如果消费者刚接收到消息就死机了，那么这个消息没有处理完成就丢失了。应为应答是在接收之时自动发出的，而不是真正完成时发出的。

所以，手动应答，若一个消费者在处理过程中挂了，则将它正在处理未完成的消息重新分发给另一个消费者。

 

消息持久化

将消息持久化可以避免rabbitMq服务死机消息丢失的问题。

若是将上述方法，第二个参数直接修改成true(持久化)，启动报错，因为队列是已经声明好的未持久化的（），rabbitmq不允许使用不同的参数重新定义一个已经存在的队列。

                                                           （work-queue已经存在，以未持久化的方式存在）

解决办法：在控制台中将这个队列删除，然后重新创建；或者重新创建一个新的队列。

？？？

上面讲述的都是只有一个队列，一个消息只能由一个消费者消费。下面引入一个新的概念：交换器

中间X就是交换器。生产者将消息发送给交换器，由交换器通过路由分发给队列；而队列和消费者是一一对应的。

交换器可以将同一个消息发给一个队列或多个队列，这样一个消息就可以由多个消费者共同消费了。

注意：交换器没有存储能力，所以交换机必须与队列绑定。

如果控制台中还没有该交换器，就先运行与该交换器绑定的消费者，那么启动将报错；如果与该交换器绑定的消费者还没有进行监听，那么生产者发送的消息将丢失。

交换器分发类型

fanout：每一个消费者接收全部消息，不处理路由键。

生产者要声明交换器，不需要声明队列了

发送消息时使用交换器参数，第二个参数路由键为空。

注意：简单队列不使用交换器时，生产者发送消息的路由键与队列名称一致。

消费者声明队列，且要与交换器绑定

 

 queueBind方法的最后一个参数路由键为空

direct：消息的路由键与队列匹配，交换器则将该消息分发给该队列

因为消费者的队列可以绑定多个路由键，所以同一个消息还是可以被多个消费者接收。

direct模式要求不管是生产者还是消费者都要有自己明确的路由键，而在实际复杂的业务中，可以需要定义多个路由键，这样一一绑定，可能会比较麻烦。

topic ：将路由键与某个模式进行匹配，相当于direct的模糊匹配

#匹配一个或多个字符

*匹配一个字符

这里有一个问题：生产者的路由键必须由XXX.XXX格式组成，消费者的路由键若使用topic模式，格式为XXX.#或#.XXX，否则就接收不到消息。

若在控制台中手动解绑，则被解绑的队列及其消费者就不能再接收消息了

消息确认机制

生产者将消息发送出去以后，到底有没有成功发给rabbitMq呢？注意，不是消费者有没有成功处理完成。

1、可以通过AMQP协议的事务机制进行确认

‘

发消息后提交

’

出现异常回滚

每一次都要两到三步向服务器发送事务，会降低服务器的吞吐量，效率比较低。

2、rabbitMq消息确认机制之confirm模式（串行）

注意：若队列、信道之前已经是事务模式的，不能直接修改为confirm模式。

先开启confirm确认模式

发送消息--确认

若是批量发送的消息，确认时若是有一条消息发送失败，就会确认失败。

3、rabbitMq消息确认机制之confirm模式（异步）

在消息发送成功时，删除set中的标识；消息发送失败时，可以重新发送，根据自己的业务去实现。

注意：此时若在生产者处关闭连接，则不能再进行监听。