HmilyMing

消费端进行消费的时候，如果由于业务异常导致失败了，返回 NACK 达到最大重试次数，此时我们可以进行日志的记录，然后手动 ACK 回去，最后对这个记录进行补偿。 或者由于服务器宕机等严重问题，导致 ACK 和 NACK 都没有，那我们就需要手工进行 ACK 保障消费端消费成功，…

假设一个场景，由于我们的消费端突然全部不可用了，导致 rabbitMQ 服务器上有上万条未处理的消息，这时候如果没做任何现在，随便开启一个消费端客户端，就会导致巨量的消息瞬间全部推送过来，但是我们单个客户端无法同时处理这么多的数据，就会导致消费端变得巨卡，有可能直接崩溃不可用了…

先启动消费端，再启动生产端，查看运行结果：注意看消费端的日志，打印出了我们自定义消费者里面的东西了。 至此，简单的使用自定义消费者demo就完成了。

消息的确认是指生产者投递消息后，如果 Broker 接收到消息，则会给生产者一个应答。生产者进行接收应答，用来确认这条消息是否正常的发送到 Broker，这种方式也是消息可靠性投递的核心保障。其流程图如下所示 自此，confirm 机制的用法接受完毕。 2. return 消息…

可以参考数据库乐观锁机制，比如执行一条更新库存的 SQL 语句，在并发场景，为了性能和数据可靠性，会在更新时加上查询时的版本，并且更新这个版本信息。可能你要对一个事情进行操作，这个操作可能会执行成百上千次，但是操作结果都是相同的，这就是幂等性。 在海量订单生成的业务高峰期，生产…

一. 生产端的可靠性投递 在实际生产中，很难保障前三点的完全可靠，比如在极端的环境中，生产者发送消息失败了，发送端在接受确认应答时突然发生网络闪断等等情况，很难保障可靠性投递，所以就需要有第四点完善的消息补偿机制。 流程的示意图如上所示，比如我下单成功了，这是进行 step1，…

注意:direct模式可以使用 rabbitMQ 自带的 exchange:default exchange，所以不需要将 exchange 进行任何绑定(binding)操作，消息传递时，routingkey 必须完全匹配才会被队列接收，否则该消息会被抛弃。 该消费端只接收 …

流程： 首先是获取连接工厂 ConnectionFactory --> 获取一个连接 Connection --> 通过连接建立数据通信 信道 Channel，用 Channel 发送或接收消息。

如上图所示，rabbitMQ 在启动后会自动创建一个 / 的虚拟主机，当然你也可以自己创建虚拟主机。