进阶

最新推荐文章于 2020-08-10 16:29:39 发布

wuychn

最新推荐文章于 2020-08-10 16:29:39 发布

阅读量257

点赞数 1

分类专栏： RabbitMQ

本文链接：https://blog.csdn.net/qmqm011/article/details/83857460

版权

RabbitMQ 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

声明：本文是《RabbitMQ实战指南》（朱忠华著）学习笔记，仅供本人学习研究之用，如若喜欢请购买正版书籍。如有侵权，请联系删除。

mandatory 参数

mandatory 这个单词的意思是强制的、托管的、命令的。当 mandatory 为 true 时，如果交换器无法找到一个符合条件的队列，那么 RabbitMQ 会将消息返回给生产者；当 mandatory 参数设置为 false 时，消息会直接被丢弃。

生产者可以通过 channel.addReturnListener 来添加 ReturnListener 监昕器，获取没有被正确路由到合适队列的消息。看下面的例子：

public class RabbitProducer {

    private static final String EXCHANGE_NAME = "exchange_demo";
    private static final String ROUTING_KEY = " routingkey_demo";
    private static final String QUEUE_NAME = "queue_demo";
    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道
        // 创建一个type为direct、持久化的、非自动删除的交换器
        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        // 创建一个持久化的、非排他的、非自动删除的队列
        channel.queueDeclare(QUEUE_NAME, true, false, false, null);
        // 将交换器与队列通过路由键绑定
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);
        // 发送一条持久化消息:Hello World!
        String message = "mandatory returned";

        // 先添加监听，再调用channel.basicPublish，否则获取不到
        channel.addReturnListener((mandatory, replyText, exchange, routingKey, basicProperties, body) ->
                System.out.println("Basic.Return 返回的结果是: " + new String(body))
        );

        // 注意第二个参数是路由键，应该和channel.queueBind方法的第三个参数一致，但是这里为空串，就找不到对应的队列
        // 第三个参数是mandatory参数，这里为true，会将不可达的消息返回给发送者
        channel.basicPublish(EXCHANGE_NAME, "", true, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes());

        // 让现场睡眠一会儿，不然也看不到效果
        try {
            Thread.sleep(10000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 关闭资源
        channel.close();
        connection.close();
    }
}

immediate 参数

immediate 的意思是立即的、直接的、最接近的。当 immediate 为 true 时，如果交换器在将消息路由到队列时发现队列上并不存在任何消费者，那么这条消息将不会存入队列中。当与路由键匹配的所有队列都没有消费者时，该消息会通过 Basic.Return 返回至生产者。

mandatory 和 immediate 的区别是：mandatory 是如果没有队列与交换器绑定，将消息返回给生产者。imrnediate 参数是如果与交换器绑定的所有队列上都没有消费者，则直接将消息返还给生产者，不用将消息存入队列。

RabbitMQ 3.0 版本开始去掉了对 immediate 参数的支持，建议采用 TTL 和 DLX 的方法替代。

备份交换器（Alternate Exchange，AE）

生产者在发送消息的时候如果不设置 mandatory 参数，那么消息在未被路由的情况下将会丢失；如果设置了 mandatory 参数，那么需要添加 ReturnListener 的编程逻辑，生产者的代码将变得复杂。如果既不想复杂化生产者的编程逻辑，又不想消息丢失，那么可以使用备份交换器，这样可以将未被路由的消息存储在 RabbitMQ 中，需要的时候去处理这些消息。

可以通过在声明交换器的时候添加 alternate-exchange 参数来实现，也可以通过策略（Policy）的方式实现。如果两者同时使用，则前者的优先级更高。

使用 alternate-exchange 参数设置备份交换器示例代码如下：

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672;

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        Map<String, Object> params = new HashMap<>();
        params.put("alternate-exchange", "myAe");
        channel.exchangeDeclare("normalExchange", "direct", true, false, params);
        channel.exchangeDeclare("myAe", "fanout", true, false, null);
        channel.queueDeclare("normalQueue", true, false, false, null);
        channel.queueBind("normalQueue", "normalExchange", "normalKey");
        channel.queueDeclare("unroutedQueue", true, false, false, null);
        channel.queueBind("unroutedQueue", "myAe", "");

        channel.basicPublish("normalExchange", "errorKey", true, MessageProperties.PERSISTENT_TEXT_PLAIN, "alternate-exchange".getBytes());
        
        // 关闭资源
        channel.close();
        connection.close();
    }
}

上面的代码中声明了两个交换器 normalExchange 和 myAe，分别绑定了 normalQueue 和 unroutedQueue 这两个队列，同时将 myAe 设置为 normalExchange 的备份交换器。注意 myAe 的交换器类型为 fanout（会将消息路由到所有与之绑定的队列）。如果发送一条消息到 normalExchange 上，当路由键等于 normalKey 的时候，消息能正确路由到 normalQueue 这个队列中。如果路由键设为其他值，比如 errorKey，那么消息不能被正确地路由到与 normalExchange 绑定的任何队列上，此时就会发送给 myAe，进而发送到 unroutedQueue 这个队列。

备份交换器和普通的交换器没有太大的区别，为了方便使用，建议设置为 fanout 类型（当然也可以为 direct 或者 topic）。需要注意的是，消息被重新发送到备份交换器时的路由键和从生产者发出的路由键是一样的。

对于备份交换器，有以下几种特殊情况：

• 如果设置的备份交换器不存在，客户端和 RabbitMQ 服务端都不会有异常出现，此时消息会丢失。

• 如果备份交换器没有绑定任何队列，客户端和 RabbitMQ 服务端都不会有异常出现，此时消息会丢失。

• 如果备份交换器没有任何匹配的队列，客户端和 RabbitMQ 服务端都不会有异常出现，此时消息会丢失。

• 如果备份交换器和 mandatory 参数一起使用，那么 mandatory 参数无效。

过期时间TTL

TTL是Time to Live 的简称，意思是过期时间。RabbitMQ 可以对消息和队列设置过期时间。

设置消息的 TTL

有两种方法可以设置消息的 TTL。第一种方法是通过队列属性设置，这样队列中所有消息都有相同的过期时间。第二种方法是对消息本身进行单独设置，每条消息的 TTL 可以不同。如果两种方法一起使用，则消息的 TTL 以两者之间较小的那个数值为准。消息在队列中的生存时间一旦超过设置的 TTL 值时，就会变成死信（Dead Message），消费者将无法再收到该消息。

通过队列属性设置消息 TTL 的方法是在 channel.queueDeclare 方法中加入 x-message-ttl 参数实现的，这个参数的单位是毫秒：

public class RabbitProducer {

    private static final String EXCHANGE_NAME = "exchange_demo";
    private static final String ROUTING_KEY = " routingkey_demo";
    private static final String QUEUE_NAME = "queue_demo2";
    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道
        // 创建一个type为direct、持久化的、非自动删除的交换器
        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);

        Map<String, Object> params = new HashMap<>();
        params.put("x-message-ttl", 6000);
        channel.queueDeclare(QUEUE_NAME, true, false, false, params);
        // 将交换器与队列通过路由键绑定
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);
        // 发送一条持久化消息:Hello World!
        String message = "Hello World!";

        channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, true, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes());

        // 关闭资源
        channel.close();
        connection.close();
    }
}

运行这个方法，然后等6秒后执行消费者客户端，将获取不到任何消息。

如果不设置 TTL，那么消息不会过期；如果将 TTL 设置为 0，表示除非此时可以直接将消息投递到消费者，否则该消息会被立即丢弃，这个特性可以部分替代 RabbitMQ 3.0 版本之前的 immediate 参数，之所以部分代替，是因为 immediate 参数在投递失败时会用 Basic.Return 将消息返回。

针对每条消息设置 TTL 的方法是在 channel.basicPublish 方法中加入 expiration 的属性参数，单位为毫秒：

public class RabbitProducer {

    private static final String EXCHANGE_NAME = "exchange_chap1_1";
    private static final String ROUTING_KEY = "routingKey_chap1_1";
    private static final String QUEUE_NAME = "queue_chap1_1";
    private static final String IP_ADDRESS = "localhost";
    private static final int PORT = 5672; // RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道
        // 创建一个type为direct、持久化的、非自动删除的交换器
        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        // 创建一个持久化的、非排他的、非自动删除的队列
        channel.queueDeclare(QUEUE_NAME, true, false, false, null);
        // 将交换器与队列通过路由键绑定
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);
        // 发送一条持久化消息:Hello World!
        String message = "ttl message";
        channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, new AMQP.BasicProperties().builder()
                        .deliveryMode(2) // 消息持久化
                        .expiration("6000") // 过期时间
                        .build(),
                message.getBytes());
        // 关闭资源
        channel.close();
        connection.close();
    }
}

对于第一种设置队列 TTL 属性的方法，一旦消息过期，就会从队列中抹去，而在第二种方法中，即使消息过期，也不会马上从队列中抹去，因为每条消息是否过期是在即将投递到消费者之前判定的。第一种方法里，队列中己过期的消息肯定在队列头部，RabbitMQ 只要定期从队头开始扫描是否有过期的消息即可。而第二种方法里，每条消息的过期时间不同，如果要删除所有过期消息势必要扫描整个队列，所以不如等到此消息即将被消费时再判定是否过期，如果过期再进行删除即可。

设置队列的 TTL

通过 channel.queueDeclare 方法中的 x-expires 参数可以设置队列的过期时间，单位是毫秒，不能设置为0，如果在这个时间段内，队列上没有任何的消费者，队列也没有被重新声明，并且也未调用过 Basic.Get 命令，那么队列将被删除。

RabbitMQ 会确保在过期时间到达后将队列删除，但是不保障删除的动作有多及时。在 RabbitMQ 重启后，持久化的队列的过期时间会被重新计算。

下面的例子创建一个过期时间为1分钟的队列：

public class RabbitProducer {

    private static final String EXCHANGE_NAME = "exchange_demo";
    private static final String ROUTING_KEY = " routingkey_demo";
    private static final String QUEUE_NAME = "queue_demo4";
    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道
        // 创建一个type为direct、持久化的、非自动删除的交换器
        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        Map<String, Object> params = new HashMap<>();
        params.put("x-expires", 1000 * 60);
        channel.queueDeclare(QUEUE_NAME, true, false, false, params);
        // 将交换器与队列通过路由键绑定
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);
        // 发送一条持久化消息:Hello World!
        String message = "queuettlTestMessage";
        channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, true, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes());

        // 关闭资源
        channel.close();
        connection.close();
    }
}

死信队列

当消息在一个队列中变成死信（dead message）之后，它能被重新被发送到另一个交换器中，这个交换器叫做死信交换器（Dead-Letter-Exchang，DLX），也可以称为死信邮箱。绑定 DLX 的队列就称之为死信队列。

消息变成死信一般是由于以下几种情况：

• 消息被拒绝（Basic.Reject/Basic.Nack），井且设置 requeue 参数为 false。

• 消息过期。

• 队列达到最大长度。

DLX 也是一个正常的交换器，和一般的交换器没有区别。当队列中存在死信时，RabbitMQ 会自动地将这个消息重新发布到设置的 DLX 上去，进而被路由到另一个队列，即死信队列。可以监听这个队列中的消息，以进行相应的处理，这个特性与将消息的 TTL 设置为 0 配合使用可以弥补 imrnediate 参数的功能。

通过在 channel.queueDeclare 方法中设置 x-dead-letter-exchange 参数来为这个队列添加 DLX：

public class RabbitProducer {

    private static final String EXCHANGE_NAME = "exchange_demo";
    private static final String ROUTING_KEY = " routingkey_demo";
    private static final String QUEUE_NAME = "queue_demo5";
    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        // 创建一个type为direct、持久化的、非自动删除的交换器
        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        channel.exchangeDeclare("dlx_exchange", "direct");

        Map<String, Object> params = new HashMap<>();
        params.put("x-dead-letter-exchange", "dlx_exchange");
        // 为队列添加DLX
        channel.queueDeclare(QUEUE_NAME, true, false, false, params);

        // 将交换器与队列通过路由键绑定
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);
        // 发送一条持久化消息:Hello World!
        String message = "dlx-test";
        channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, true, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes());

        // 关闭资源
        channel.close();
        connection.close();
    }
}

也可以为这个 DLX 指定路由键，如果没有特殊指定，则使用原队列的路由键：

    params.put("x-dead-letter-routing-key", "dlx-routing-key");

下面创建一个队列，为其设置 TTL 和 DLX 等：

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        channel.exchangeDeclare("exchange.dlx", "direct", true);
        channel.exchangeDeclare("exchange.normal", "fanout", true);
        Map<String, Object> params = new HashMap<>();
        params.put("x-message-ttl", 10000);
        params.put("x-dead-letter-exchange", "exchange.dlx");
        params.put("x-dead-letter-routing-key", "routingkey");
        channel.queueDeclare("queue.normal", true, false, false, params);
        channel.queueBind("queue.normal", "exchange.normal", "");
        channel.queueDeclare("queue.dlx", true, false, false, null);
        channel.queueBind("queue.dlx", "exchange.dlx", "routingkey");
        channel.basicPublish("exchange.normal", "rk",
                MessageProperties.PERSISTENT_TEXT_PLAIN, "dlx".getBytes());

        // 关闭资源
        channel.close();
        connection.close();
    }
}

这里创建了两个交换器 exchange.normal 和 exchange.dlx，分别绑定两个队列 queue.normal 和 queue.dlx 。

生产者首先发送一条携带路由键为 "rk" 的消息，然后经过交换器 exchange.normal 顺利地存储到队列 queue.normal 中。由于队列 queue.normal 设置了消息的过期时间为10s，在这 10s 内没有消费者消费这条消息，那么判定这条消息为过期。由于设置了 DLX，过期之时，消息被丢给交换器 exchange.dlx 中，这时找到与 exchange.dlx 匹配的队列 queue.dlx，最后消息被存储在 queue.dlx 这个死信队列中。10秒以后，执行如下消费者客户端，可以获取到进入死信队列的消息：

public class RabbitConsumer {

    private static final String QUEUE_NAME = "queue.dlx";
    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException, InterruptedException {
        Address[] addresses = new Address[]{new Address(IP_ADDRESS, PORT)};
        ConnectionFactory factory = new ConnectionFactory();
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(addresses); // 创建连接
        final Channel channel = connection.createChannel(); // 创建信道
        channel.basicQos(64); // 设置客户端最多接收未被 ack 的消息的个数
        Consumer consumer = new DefaultConsumer(channel) {
            @Override
            public void handleDelivery(String consumerTag,
                                       Envelope envelope,
                                       AMQP.BasicProperties properties,
                                       byte[] body) throws IOException {
                System.out.println("recv message: " + new String(body));
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                channel.basicAck(envelope.getDeliveryTag(), false);
            }
        };
        channel.basicConsume(QUEUE_NAME, consumer);
        // 等待回调函数执行完毕之后，关闭资源
        TimeUnit.SECONDS.sleep(5);
        channel.close();
        connection.close();
    }
}

DLX 是一个非常有用的特性，它可以处理异常情况下，消息不能够被消费者正确消费（消费者调用了 Basic.Nack 或者Basic.Reject）而被置入死信队列中的情况，后续分析程序可以通过消费这个死信队列中的内容来分析当时所遇到的异常情况，进而可以改善和优化系统。DLX 配合 TTL 使用还可以实现延迟队列的功能。

延迟队列

延迟队列存储的是延迟消息，所谓延迟消息是指当消息被发送以后，并不想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费。

延迟队列的使用场景有很多，比如：

• 在订单系统中，用户下单之后通常有 30 分钟的时间进行支付，如果 30 分钟之内没有支付成功，那么这个订单将进行异常处理，这时就可以使用延迟队列来处理这些订单了。

• 用户希望通过手机远程遥控家里的智能设备在指定的时间进行工作。这时候就可以将用户指令发送到延迟队列，当指令设定的时间到了再将指令推送到智能设备。

在 AMQP 协议中，或者 RabbitMQ 本身没有直接支持延迟队列的功能，但是可以通过前面所介绍的 DLX 和 TTL 模拟出延迟队列的功能。

在上一个例子中，不仅展示的是死信队列的用法，也是延迟队列的用法，对于 queue.dlx 这个死信队列来说，同样可以看作延迟队列。假设一个应用中需要将每条消息都设置为 10 秒的延迟，生产者通过 exchange.normal 这个交换器将发送的消息存储在 queue.normal 这个队列中。消费者订阅的并非是 queue.normal 这个队列，而是 queue.dlx 这个队列。当消息从 queue.normal 这个队列中过期之后被存入 queue.dlx 这个队列中，消费者就恰巧消费到了延迟 10 秒的这条消息。

优先级队列

优先级队列是指具有高优先级的队列具有高的优先权，优先级高的消息具备优先被消费的特权。

可以通过设置队列的 x-max-priority 参数来实现：

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        channel.exchangeDeclare("exchange.priority", "direct", true);

        Map<String, Object> params = new HashMap<>();
        params.put("x-max-priority", 10);
        channel.queueDeclare("queue.priority", true, false, false, params);

        channel.queueBind("queue.priority", "exchange.priority", "routingkey");

        channel.basicPublish("exchange.priority", "routingkey", MessageProperties.PERSISTENT_TEXT_PLAIN, "priority".getBytes());

        // 关闭资源
        channel.close();
        connection.close();
    }
}

上面的代码演示的是如何配置一个队列的最大优先级。在此之后，需要在发送时在消息中设置消息当前的优先级。示例代码如下：

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        channel.exchangeDeclare("exchange.priority", "direct", true);

        Map<String, Object> params = new HashMap<>();
        params.put("x-max-priority", 10);
        channel.queueDeclare("queue.priority", true, false, false, params);

        channel.queueBind("queue.priority", "exchange.priority", "routingkey");

        channel.basicPublish("exchange.priority", "routingkey", new AMQP.BasicProperties().builder().priority(5).build(), "priority".getBytes());

        // 关闭资源
        channel.close();
        connection.close();
    }
}

上面的代码中设置消息的优先级为 5，默认最低为 0，最高为队列设置的最大优先级。优先级高的消息可以被优先消费，这个也是有前提的：如果在消费者的消费速度大于生产者的速度且 Broker 中没有消息堆积的情况下，对发送的消息设置优先级也就没有什么实际意义。因为生产者刚发送完一条消息就被消费者消费了，那么就相当于 Broker 中至多只有一条消息，对于单条消息来说优先级是没有什么意义的。

RPC 实现

RPC，是 Remote Procedure Call 的简称，即远程过程调用。它是一种通过网络从远程计算机上请求服务，而不需要了解服务具体实现的技术。RPC 的主要作用是让构建分布式计算更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。

RPC 的协议有很多，比如最早的 CORBA、Java RMI、WebService 的 RPC 风格、 Hessian、Thrift 甚至还有 Restful API。

在 RabbitMQ 中进行 RPC 很简单，客户端发送请求消息，服务端回复响应的消息。为了接收响应的消息，我们需要在请求消息中发送一个回调队列。代码如下：

        String callbackQueueName = channel.queueDeclare().getQueue();
        // replyTo: 通常用来设置一个回调队列。
        channel.basicPublish("", "rpc_queue", new AMQP.BasicProperties().builder().replyTo(callbackQueueName).build(), "rpc_message".getBytes());
        // then code to read a response message from the callback_queue

如果像上面的代码中一样，为每个 RPC 请求创建一个回调队列，是非常低效的。可以为每个客户端创建一个单一的回调队列。这样就产生了一个新的问题，对于回调队列而言，在其接收到一条回复的消息之后，它并不知道这条消息应该和哪一个请求匹配。这里就用到 BasicProperties的correlationld 这个属性了，我们应该为每一个请求设置一个唯一的 correlationld。之后在回调队列接收到回复的消息时，可以根据这个属性匹配到相应的请求。如果回调队列接收到一条未知 correlationld 的回复消息，可以简单地将其丢弃。

为什么要将回调队列中的未知消息丢弃而不是仅仅将其看作失败？这样可以针对这个失败做一些弥补措施。考虑这样一种情况，RPC 服务器可能在发送给回调队列并且在确认接收到请求的消息（rpc_queue中的消息）之后挂掉了，那么只需重启下 RPC 服务器即可， RPC 服务会重新消费 rpc_queue 队列中的请求，这样就不会出现 RPC 服务端未处理请求的情况。这里的回调队列可能会收到重复消息的情况，这需要客户端能够优雅地处理这种情况，并且 RPC 请求也需要保证其本身是幂等的。

RPC 的处理流程如下：

• 当客户端启动时，创建一个匿名的回调队列。

• 客户端为 RPC 请求设置 2 个属性：replyTo 用来告知 RPC 服务端回复请求时的目的队列，即回调队列；correlationld 用来标记一个请求。

• 请求被发送到 rpc_queue 队列中。

• RPC 服务端监听 rpc_queue 队列中的请求，当请求到来时，服务端会处理并且把带有结果的消息发送给客户端。接收的队列就是 replyTo 设定的回调队列。

• 客户端监听回调队列，当有消息时，检查 correlationld 属性，如果与请求匹配，那就是结果了。

下面沿用 RabbitMQ 官方网站的一个例子来做说明，RPC 客户端通过 RPC 来调用服务端的方法以便得到相应的斐波那契值。

服务端：

public class RPCServer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672;
    private static final String RPC_QUEUE_NAME = "rpc_queue";

    public static void main(String[] args) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection();
        Channel channel = connection.createChannel();

        channel.queueDeclare(RPC_QUEUE_NAME, false, false, false, null);
        channel.basicQos(1);
        System.out.println(" [x] Awaiting RPC requests ");

        Consumer consumer = new DefaultConsumer(channel) {
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
                AMQP.BasicProperties replyProps = new AMQP.BasicProperties().builder().correlationId(properties.getCorrelationId()).build();
                String response = "";
                try {
                    String message = new String(body, "UTF-8");
                    int n = Integer.parseInt(message);
                    System.out.println(" [.] fib( " + message + " )");
                    response += fib(n);
                } catch (Exception e) {
                    System.out.println(" [.] " + e.toString());
                } finally {
                    channel.basicPublish(" ", properties.getReplyTo(),
                            replyProps, response.getBytes("UTF-8"));
                    channel.basicAck(envelope.getDeliveryTag(), false);
                }
            }
        };
        channel.basicConsume(RPC_QUEUE_NAME, false, consumer);
    }

    private static int fib(int n) {
        if (n == 0) return 0;
        if (n == 1) return 1;
        return fib(n - 1) + fib(n - 2);
    }

}

客户端：

public class RPCClient {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672;
    private Connection connection;
    private Channel channel;
    private String requestQueueName = "rpc_queue";
    private String replyQueueName;
    private QueueingConsumer consumer;

    public RPCClient() throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection();
        Channel channel = connection.createChannel();

        replyQueueName = channel.queueDeclare().getQueue();
        consumer = new QueueingConsumer(channel);
        channel.basicConsume(replyQueueName, true, consumer);
    }

    public String call(String message) throws Exception {
        String response = null;
        String corrId = UUID.randomUUID().toString();
        AMQP.BasicProperties props = new AMQP.BasicProperties().builder().correlationId(corrId).replyTo(replyQueueName).build();

        channel.basicPublish("", replyQueueName, props, message.getBytes());

        while (true) {
            QueueingConsumer.Delivery delivery = consumer.nextDelivery();
            if (delivery.getProperties().getCorrelationId().equals(corrId)) {
                response = new String(delivery.getBody());
                break;
            }
        }
        return response;
    }

    public void close() throws Exception {
        connection.close();
    }

    public static void main(String[] args) throws Exception {
        RPCClient fibRpc = new RPCClient();
        System.out.println(" [x] Requesting fib(30)");
        String response = fibRpc.call("30");
        System.out.println(" [.] Got '" + response + "'");
        fibRpc.close();
    }

}

持久化

持久化可以提高 RabbitMQ 的可靠性，防止在异常情况（重启、关闭、右机等）下的数据丢失。RabbitMQ 的持久化分为三个部分：交换器的持久化、队列的持久化和消息的持久化。

交换器的持久化是通过在声明交换器时将 durable 参数置为 true 实现的。如果交换器不设置持久化，那么在 RabbitMQ 服务重启之后，相关的交换器元数据会丢失，不过消息不会丢失，只是不能将消息发送到这个交换器中了。对一个长期使用的交换器来说，建议将其置为持久化的。

队列的持久化是通过在声明队列时将 durable 参数置为 true 实现的。如果队列不设置持久化，那么在 RabbitMQ 服务重启之后，相关队列的元数据会丢失，此时数据也会丢失。

队列的持久化能保证队列本身的元数据不会因异常情况而丢失，但是并不能保证内部所存储的消息不会丢失。要确保消息不会丢失，需要将消息设置为持久化的。通过将消息的投递模式（BasicProperties中的 deliveryMode 属性）设置为 2 即可实现消息的持久化。前面示例中多次提及的 MessageProperties.PERSISTENT_TEXT_PLAIN 实际上是封装了这个属性：

public static final BasicProperties PERSISTENT_TEXT_PLAIN = new BasicProperties("text/plain", (String)null, (Map)null, 2, 0, (String)null, (String)null, (String)null, (String)null, (Date)null, (String)null, (String)null, (String)null, (String)null);

设置了队列和消息的持久化，当 RabbitMQ 服务重启之后，消息依旧存在。若只设置队列持久化，重启之后消息会丢失；若只设置消息的持久化，重启之后队列消失，继而消息也丢失。只设置消息持久化而不设置队列的持久化毫无意义。

可以将所有的消息都设置为持久化，但是这样会严重影响 RabbitMQ 的性能。对于可靠性要求不是那么高的消息可以不采用持久化处理以提高整体的吞吐量。

将交换器、队列、消息都设置了持久化之后也不能保证数据百分之百不丢失。首先从消费者来说，如果在订阅消费队列时将 autoAck 参数设置为 true，那么当消费者接收到相关消息之后，还没来得及处理就宕机了，这样也算数据丢失。这种情况很好解决，将 autoAck 参数设置为 false，并进行手动确认。其次，在持久化的消息正确存入 RabbitMQ 之后，还需要有一段时间才能存入磁盘之中。 RabbitMQ 并不会为每条消息都进行同步存盘的处理，可能仅仅保存到操作系统缓存之中而不是物理磁盘之中（Redis的持久化也提到了类似的问题）。如果在这段时间内 RabbitMQ 服务节点发生了岩机、重启等异常情况，消息保存还没来得及保存到磁盘中，那么这些消息将会丢失。为解决这个问题，可以使用 RabbitMQ 的镜像队列机制，相当于配置了副本，如果主节点（master）在此特殊时间内挂掉，可以自动切换到从节点（slave），这样有效地保证了高可用性，除非整个集群都挂掉。虽然这样也不能完全保证 RabbitMQ 消息不丢失，但是配置了镜像队列要比没有配置镜像队列的可靠性要高很多，在实际生产环境中的关键业务队列一般都会设置镜像队列。此外，还可以在发送端引入事务机制或者发送方确认机制来保证消息己经正确地发送并存储至 RabbitMQ 中，前提还要保证在调用 channel.basicPublish 方法的时候交换器能够将消息正确路由到相应的队列之中。

生产者确认

可以通过消息持久化操作来解决因为服务器的异常崩溃而导致的消息丢失，但是，当消息的生产者将消息发送出去之后，怎么知道消息到底有没有正确地到达服务器呢？默认情况下发送消息的操作是不会返回任何信息给生产者的，也就是默认情况下生产者是不知道消息有没有正确地到达服务器。如果在消息到达服务器之前己经丢失，持久化操作也解决不了这个问题，因为消息根本没有到达服务器，何谈持久化。

针对这个问题，RabbitMQ 提供了两种解决方式：

• 通过事务机制实现。

• 通过发送方确认（publisher confirm）机制实现。

事务机制

RabbitMQ 客户端中与事务机制相关的方法有三个：channel.txSelect、channel.txCommit 和 channel.txRollback。channel.txSelect 用于将当前的信道设置成事务模式，channel.txCommit 用于提交事务，channel.txRollback 用于事务回滚。在通过 channel.txSelect 方法开启事务之后，便可以发布消息给 RabbitMQ 了，如果事务提交成功，则消息一定到达了 RabbitMQ 中；如果在事务提交之前由于 RabbitMQ 异常崩溃或者其他原因抛出异常，这个时候可以将其捕获，进而通过执行 channel.txRollback 方法来实现事务回滚。RabbitMQ 中的事务机制与大多数数据库中的事务概念并不相同，需要注意区分。

事务提交示例代码如下：

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672;
    private static final String EXCHANGE_NAME = "exchange_tx";
    private static final String QUEUE_NAME = "queue_tx";
    private static final String ROUTING_KEY = "routing_tx";

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        channel.queueDeclare(QUEUE_NAME, true, false, false, null);
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);
        String message = "tx message";
        channel.txSelect();
        channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes());
        channel.txCommit();

        // 关闭资源
        channel.close();
        connection.close();
    }
}

上面代码对应的 AMQP 协议流转过程如图所示：

• 客户端发送 Tx.Select 将信道置为事务模式。

• Broker 回复 Tx.Select-Ok，确认己将信道置为事务模式。

• 客户端发送消息。

• 发送完消息之后，客户端发送 Tx.Commit 提交事务。

• Broker 回复 Tx.Commit-Ok. 确认事务提交。

再来看看事务回滚的例子：

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672;
    private static final String EXCHANGE_NAME = "exchange_tx";
    private static final String QUEUE_NAME = "queue_tx";
    private static final String ROUTING_KEY = "routing_tx";

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        channel.queueDeclare(QUEUE_NAME, true, false, false, null);
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);

        try {
            String message = "tx message rollback";
            channel.txSelect();
            channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes());
            int result = 1 / 0;
            channel.txCommit();
        } catch (Exception e) {
            e.printStackTrace();
            channel.txRollback();
        }

        // 关闭资源
        channel.close();
        connection.close();
    }
}

上面的代码在事务提交之前捕获到异常，之后显式地进行事务回滚，流转过程如图所示：

如果要发送多条消息，则将 channel.basicPublish 和 channel.txCommit 等方法包裹进循环内即可：

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672;
    private static final String EXCHANGE_NAME = "exchange_tx";
    private static final String QUEUE_NAME = "queue_tx";
    private static final String ROUTING_KEY = "routing_tx";

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        channel.queueDeclare(QUEUE_NAME, true, false, false, null);
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);

        channel.txSelect();
        for (int i = 0; i < 10; i++) {
            try {
                String message = "tx message " + i;
                channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes());
                channel.txCommit();
            } catch (Exception e) {
                e.printStackTrace();
                channel.txRollback();
            }
        }

        // 关闭资源
        channel.close();
        connection.close();
    }
}

事务确实能够解决消息发送方和 RabbitMQ 之间消息确认的问题，只有消息成功被 RabbitMQ 接收，事务才能提交成功，否则便可在捕获异常之后进行事务回滚，与此同时可以进行消息重发。但是使用事务机制会降低 RabbitMQ 的性能，那么有没有更好的方法既能保证消息发送方确认消息已经正确送达，又能基本上不带来性能上的损失呢？从 AMQP 协议层面来看并没有更好的办法，但是 RabbitMQ 提供了一个改进方案，即发送方确认机制。

发送方确认机制

生产者将信道设置成 confirm（确认）模式，所有在该信道上面发布的消息都会被指派一个唯一的 ID（从 1 开始），一旦消息被投递到所有匹配的队列之后，RabbitMQ 就会发送一个确认（Basic.Ack）给生产者（包含消息的唯一 ID），这就使得生产者知晓消息已经正确到达了目的地了。如果消息和队列是可持久化的，那么确认消息会在消息写入磁盘之后发出。RabbitMQ 回传给生产者的确认消息中的 deliveryTag 包含了确认消息的序号，此外 RabbitMQ 也可以设置 channel.basicAck 方法中的 multiple 参数，表示到这个序号之前的所有消息都己经得到了处理。如图所示：

事务机制在一条消息发送之后会使发送端阻塞，以等待 RabbitMQ 的回应，之后才能继续发送下一条消息。相比之下，发送方确认机制最大的好处在于它是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用程序便可以通过回调方法来处理该确认消息，如果 RabbitMQ 因为自身内部错误导致消息丢失，就会发送一条 nack （Basic.Nack）命令，生产者应用程序同样可以在回调方法中处理该 nack 命令。

生产者通过调用 channel.confirmSelect 方法（即 Confirm.Select 命令）将信道设置为 confirm 模式，之后 RabbitMQ 会返回 Confirm.Select-Ok 命令表示同意生产者将当前信道设置为 confirm 模式。所有被发送的后续消息都被 ack 或者 nack 一次，不会出现一条消息既被 ack 又被 nack 的情况，并且 RabbitMQ 也并没有对消息被 confirm 的快慢做任何保证。

下面是使用发送方确认的示例代码：

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672;
    private static final String EXCHANGE_NAME = "exchange_confirm";
    private static final String QUEUE_NAME = "queue_confirm";
    private static final String ROUTING_KEY = "routing_confirm";

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        channel.queueDeclare(QUEUE_NAME, true, false, false, null);
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);

        try {
            // 将信道设置为publisher confirm模式
            channel.confirmSelect();
            channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, null, "publisher confirm".getBytes());
            if (!channel.waitForConfirms()) {
                System.out.println("发送消息失败！");
                // do sth else
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

        // 关闭资源
        channel.close();
        connection.close();
    }
}

如果发送多条消息，只需要将 channel.basicPublish 和 channel.waitForConfirms 方法包裹在循环里面即可，可以参考事务机制，不过不需要把 channel.confirmSelect 方法包裹在循环内部。

publisher confirm 模式下发送多条消息的 AMQP 协议流转过程图如下：

channel.waitForConfirms 有 4 个同类的方法：

    boolean waitForConfirms() throws InterruptedException;

    boolean waitForConfirms(long timeout) throws InterruptedException, TimeoutException;

    void waitForConfirmsOrDie() throws IOException, InterruptedException;

    void waitForConfirmsOrDie(long timeout) throws IOException, InterruptedException, TimeoutException;

如果信道没有开启 publisher confirm 模式，则调用任何 waitForConfirms 方法都会报出 java.lang.IllegalStateException。对于没有参数的 waitForConfirms 方法来说，其返回的条件是客户端收到了相应的 Basic.Ack/.Nack 或者被中断。参数 timeout 表示超时时间，一旦等待 RabbitMQ 回应超时就会抛出 java.util.concurrent.TimeoutException 的异常。两个 waitForConfirmsOrDie 方法在接收到 RabbitMQ 返回的 Basic.Nack 之后会抛出 java.io.IOException。业务代码可以根据自身的特性灵活地运用这四种方法来保障消息的可靠发送。

上面的 publisher confirm 模式的示例代码中，每发送一条消息后就调用 channel.waitForConfirms 方法，之后等待服务端的确认，这实际上是一种串行同步等待的方式。事务机制和它一样，发送消息之后等待服务端确认，之后再发送消息。两者的存储确认原理相同，尤其对于持久化的消息来说，两者都需要等待消息被保存到磁盘之后才会返回。在同步等待的方式下，publisher confirm 机制发送一条消息需要通信交互的命令是 2 条：Basic.Publish 和 Basic.Ack；事务机制是 3 条：Basic.Publish、Tx.Commmit、Tx.Commit-Ok（或者 Tx.Rollback、Tx.Rollback-Ok），事务机制多了一个命令帧报文的交互，所以 QPS 会略微下降。

注意：

• 事务机制和 publisher confirm 机制两者是互斥的，不能共存。

• 事务机制和 publisher confirm 机制确保的是消息能够正确地发送至 RabbitMQ的交换器，如果此交换器没有匹配的队列，那么消息也会丢失。所以在使用这两种机制的时候要确保所涉及的交换器能够有匹配的队列。发送方可以配合 mandatory 参数或者备份交换器一起使用来提高消息传输的可靠性。

publisher confirm 模式的优势在于并不一定需要同步确认。这里我们改进了一下使用方式，总结有如下两种：

• 批量 confirm 方法：每发送一批消息后，调用 channel.waitForConfirms 方法，等待服务器的确认返回。

• 异步 confirm 方法：提供一个回调方法，服务端确认了一条或者多条消息后会回调这个方法进行处理。

在批量 confirm 方法中，客户端程序需要定期或者定量（达到多少条），亦或者两者结合起来调用 channel.waitForConfirms 来等待 RabbitMQ 的确认返回。相比前面示例中的普通 confirm 方法，极大地提升了 confirm 的效率，但是问题在于出现返回 Basic.Nack 或者超时情况时，客户端需要将这一批次的消息全部重发，这会带来明显的重复消息数量，并且当消息经常丢失时，批量 confirm 的性能应该是不升反降的。批量 confirm 方法的示例代码如下：

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672;
    private static final String EXCHANGE_NAME = "exchange_batch_confirm";
    private static final String QUEUE_NAME = "queue_batch_confirm";
    private static final String ROUTING_KEY = "routing_batch_confirm";

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        channel.queueDeclare(QUEUE_NAME, true, false, false, null);
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);

        try {
            // 将信道设置为publisher confirm模式
            channel.confirmSelect();

            int msgCount = 0; // 已发送消息的数量
            int BATCH_COUNT = 10; // 一批消息的大小

            while (true) {
                channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, null, "batch_confirm_msg".getBytes());
                // 将发送出去的消息存入缓存
                if (++msgCount >= BATCH_COUNT) {
                    msgCount = 0;
                    try {
                        if (channel.waitForConfirms()) {
                            // 将缓存的消息清空
                        }
                        // 将缓存的消息重新发送
                    } catch (Exception e) {
                        e.printStackTrace();
                        // 将缓存的消息重新发送
                    }
                }
            }

        } catch (Exception e) {
            e.printStackTrace();
        }

        // 关闭资源
        channel.close();
        connection.close();
    }
}

对于异步 confirm，客户端 Channel 接口中提供的 addConfirmListener 方法可以添加 ConfirmListener 这个回调接口，这个 ConfirmListener 接口包含两个方法：handleAck 和 handleNack，分别用来处理 RabbitMQ 回传的 Basic.Ack 和 Basic.Nack。在这两个方法中都包含有一个参数 deliveryTag （在 publisher confirm 模式下用来标记消息的唯一有序序号），我们需要为每一个信道维护一个 "unconfirm" 的消息序号集合，每发送一条消息，集合中的元素加 1 。每当调用 ConfirmListener 中的 handleAck 方法时，"unconfirm" 集合中删掉相应的一条（multiple 设置为 false）或者多条（multiple 设置为 true）记录。从程序运行效率上来看，这个 "unconfirm" 集合最好采用有序集合 SortedSet 的存储结构。事实上，Java 客户端 SDK 中的 waitForConfirms 方法也是通过 SortedSet 维护消息序号的。下面的代码演示了异步 confirm 的编码实现，其中的 confirmSet 就是一个 SortedSet 类型的集合。

public class RabbitProducer {

    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672;
    private static final String EXCHANGE_NAME = "exchange_async_confirm";
    private static final String QUEUE_NAME = "queue_batch_async_confirm";
    private static final String ROUTING_KEY = "routing_async_confirm";

    public static void main(String[] args) throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(IP_ADDRESS);
        factory.setPort(PORT);
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(); // 创建连接
        Channel channel = connection.createChannel(); // 创建信道

        channel.exchangeDeclare(EXCHANGE_NAME, "direct", true, false, null);
        channel.queueDeclare(QUEUE_NAME, true, false, false, null);
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);

        // Channel的源码中就是这种方式获取的SortedSet
        // 如果不采用同步，会有并发修改异常
        SortedSet<Long> confirmSet = Collections.synchronizedSortedSet(new TreeSet());
        channel.addConfirmListener(new ConfirmListener() {
            @Override
            public void handleAck(long deliveryTag, boolean multiple) {
                System.out.println("Nack, SeqNo: " + deliveryTag + ", multiple: " + true);
                if (multiple) {
                    // 删除deliveryTag之前的消息
                    confirmSet.headSet(deliveryTag + 1).clear();
                } else {
                    // 只删除当前消息
                    confirmSet.remove(deliveryTag);
                }
            }

            @Override
            public void handleNack(long deliveryTag, boolean multiple) {
                if (multiple) {
                    confirmSet.headSet(deliveryTag + 1).clear();
                } else {
                    confirmSet.remove(deliveryTag);
                }
            }
        });

        while (true) {
            long nextSeqNo = channel.getNextPublishSeqNo();
            channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, MessageProperties.PERSISTENT_TEXT_PLAIN, "async_confirm_msg".getBytes());
            confirmSet.add(nextSeqNo);
        }

        // 关闭资源
//        channel.close();
//        connection.close();
    }
}

最后将事务、普通 confirm、批量 confirm 和异步 confirm 这 4 种方式做一下比较。批量 confirm 和异步 confirm 这两种方式的性能要比其余两种好得多。事务机制和普通 confirm 的方式吐吞量很低，但是编程方式简单，不需要在客户端维护状态（这里指的是维护 deliveryTag 及缓存未确认的消息）。批量 confirm 方式的问题在于遇到 RabbitMQ 服务端返回 Basic.Nack 需要重发批量消息而导致的性能降低。异步 confirm 方式编程模型最为复杂，而且和批量 confirm 方式一样需要在客户端维护状态。在实际生产环境中采用何种方式，这里就仁者见仁智者见智了，不过强烈建议读者使用异步 confirm 的方式。

消费端要点介绍

消费者客户端可以通过推模式或者拉模式的方式来获取并消费消息，当消费者处理完业务逻辑需要手动确认消息己被接收，这样 RabbitMQ 才能把当前消息从队列中标记清除。如果消费者由于某些原因无法处理当前接收到的消息，可以通过 channel.basicNack 或者 channel.basicReject 来拒绝掉。

这里对于 RabbitMQ 消费端来说，还有几点需要注意：

• 消息分发。

• 消息顺序。

• 弃用 QueueingConsumer。

消息分发

当 RabbitMQ 队列拥有多个消费者时，队列收到的消息将以轮询（round-robin）的方式发送给消费者。每条消息只会发送给订阅列表里的一个消费者。这种方式非常适合扩展，而且它是专门为并发程序设计的。如果现在负载加重，那么只需要创建更多的消费者来消费处理消息即可。

很多时候轮询的分发机制也不是那么优雅。默认情况下，如果有 n 个消费者，那么 RabbitMQ 会将第 m 条消息分发给第 m%n 个消费者，RabbitMQ 不管消费者是否消费并己经确认（Basic.Ack）了消息。试想一下，如果某些消费者任务繁重，来不及消费那么多的消息，而某些其他消费者由于某些原因（比如业务逻辑简单、机器性能卓越等）很快地处理完了所分配到的消息，进而进程空闲，这样就会造成整体应用吞吐量的下降。

那么该如何处理这种情况呢？这里就要用到 channel.basicQos(int prefetchCount) 这个方法，channel.basicQos 方法允许限制信道上的消费者所能保持的最大未确认消息的数量。

比如，在订阅消费队列之前，消费端程序调用了 channel.basicQos(5)，之后订阅了某个队列进行消费。RabbitMQ 会保存一个消费者的列表，每发送一条消息都会为对应的消费者计数，如果达到了所设定的上限，那么 RabbitMQ 就不会向这个消费者再发送任何消息。直到消费者确认了某条消息之后， RabbitMQ 将相应的计数减1，之后消费者可以继续接收消息，直到再次到达计数上限。

注意，Basic.Qos 的使用对于拉模式的消费方式无效。

channel.basicQos 有三种类型的重载方法：

    void basicQos(int prefetchSize, int prefetchCount, boolean global) throws IOException;

    void basicQos(int prefetchCount, boolean global) throws IOException;

    void basicQos(int prefetchCount) throws IOException;

prefetchCount 参数表示信道上的消费者允许的最大未消费消息的数量，设置为 0 则表示没有上限。prefetchSize 这个参数表示消费者所能接收未确认消息的总体大小的上限，单位为 B，设置为 0 则表示没有上限。

对于一个信道来说，它可以同时消费多个队列，当设置了 prefetchCount 大于 0 时，这个信道需要和各个队列协调以确保发送的消息都没有超过所限定的 prefetchCount 的值，这样会使 RabbitMQ 的性能降低，尤其是这些队列分散在集群中的多个 Broker 节点之中。RabbitMQ 为了提升性能，在 AMQP 0-9-1 协议之上重新定义了 global 这个参数，如下表所示：

global参数	AMQP 0-9-1	RabbitMQ
false	信道上所有消费者都需要遵从prefetchCount的限定值	信道上新的消费者需要遵从prefetchCount的限定值
true	当前通信链路（Connection）上所有的消费者都需要遵从prefetchCount的限定值	信道上所有的消费者都需要遵从prefetchCount的限定值

前面章节中的 channel.basicQos 方法的示例都是针对单个消费者的，对于同一个信道上的多个消费者而言，如果设置了 prefetchCount 的值，那么都会生效。下面的代码中有两个消费者，各自的能接收到的未确认消息的上限都为 10。

public class RabbitConsumer {

    private static final String QUEUE_NAME = "queue.dlx";
    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException, InterruptedException {
        Address[] addresses = new Address[]{new Address(IP_ADDRESS, PORT)};
        ConnectionFactory factory = new ConnectionFactory();
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(addresses); // 创建连接
        final Channel channel = connection.createChannel(); // 创建信道
        channel.basicQos(10); // 设置客户端最多接收未被 ack 的消息的个数
        Consumer consumer1 = new DefaultConsumer(channel) {
            @Override
            public void handleDelivery(String consumerTag,
                                       Envelope envelope,
                                       AMQP.BasicProperties properties,
                                       byte[] body) throws IOException {
                System.out.println(" consumer1 receive message: " + new String(body));
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                channel.basicAck(envelope.getDeliveryTag(), false);
            }
        };

        Consumer consumer2 = new DefaultConsumer(channel) {
            @Override
            public void handleDelivery(String consumerTag,
                                       Envelope envelope,
                                       AMQP.BasicProperties properties,
                                       byte[] body) throws IOException {
                System.out.println(" consumer2 receive message: " + new String(body));
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                channel.basicAck(envelope.getDeliveryTag(), false);
            }
        };

        channel.basicConsume("queue1", false, consumer1);
        channel.basicConsume("queue2", false, consumer2);
        // 等待回调函数执行完毕之后，关闭资源
        TimeUnit.SECONDS.sleep(5);
        channel.close();
        connection.close();
    }
}

如果在订阅消息之前，既设置了 global 为 true 的限制，又设置了 global 为 false 的限制，那么哪个会生效呢? RabbitMQ 会确保两者都会生效。举例说明，当前有两个队列 queue1 和 queue2，queue1 有 10 条消息，分别为 1 到 10，queue2 也有 1 0 条消息，分别为 11 到 20。有两个消费者分别消费这两个队列，代码如下所示：


public class RabbitConsumer {

    private static final String QUEUE_NAME = "queue.dlx";
    private static final String IP_ADDRESS = "192.168.115.128";
    private static final int PORT = 5672; //RabbitMQ服务端默认端口号为5672

    public static void main(String[] args) throws IOException, TimeoutException, InterruptedException {
        Address[] addresses = new Address[]{new Address(IP_ADDRESS, PORT)};
        ConnectionFactory factory = new ConnectionFactory();
        factory.setUsername("root");
        factory.setPassword("123456");
        Connection connection = factory.newConnection(addresses); // 创建连接
        final Channel channel = connection.createChannel(); // 创建信道
        channel.basicQos(3, false);
        channel.basicQos(5, true);
        Consumer consumer1 = new DefaultConsumer(channel) {
            @Override
            public void handleDelivery(String consumerTag,
                                       Envelope envelope,
                                       AMQP.BasicProperties properties,
                                       byte[] body) throws IOException {
                System.out.println(" consumer1 receive message: " + new String(body));
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                channel.basicAck(envelope.getDeliveryTag(), false);
            }
        };

        Consumer consumer2 = new DefaultConsumer(channel) {
            @Override
            public void handleDelivery(String consumerTag,
                                       Envelope envelope,
                                       AMQP.BasicProperties properties,
                                       byte[] body) throws IOException {
                System.out.println(" consumer2 receive message: " + new String(body));
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                channel.basicAck(envelope.getDeliveryTag(), false);
            }
        };

        channel.basicConsume("queue1", false, consumer1);
        channel.basicConsume("queue2", false, consumer2);
        // 等待回调函数执行完毕之后，关闭资源
        TimeUnit.SECONDS.sleep(5);
        channel.close();
        connection.close();
    }
}

那么这里每个消费者最多只能收到 3 个未确认的消息，两个消费者能收到的未确认的消息个数之和的上限为 5。在未确认消息的情况下，如果 consumer1 接收到了消息 1、2 和 3，那么consumer2 至多只能收到 11 和 12。如果像这样同时使用两种 global 的模式，则会增加 RabbitMQ的负载，因为 RabbitMQ 需要更多的资源来协调完成这些限制。如无特殊需要，最好只使用 global 为 false 的设置，这也是默认的设置。

消息顺序性

消息的顺序性是指消费者消费到的消息和发送者发布的消息的顺序是一致的。举个例子，不考虑消息重复的情况，如果生产者发布的消息分别为 msg1、msg2、msg3，那么消费者必然也是按照 msg1、msg2、msg3 的顺序进行消费的。

目前很多资料显示 RabbitMQ 的消息能够保障顺序性，这是不正确的，或者说这个观点有很大的局限性。在不使用任何 RabbitMQ 的高级特性，也没有消息丢失、网络故障之类异常的情况发生，并且只有一个消费者的情况下，最好也只有一个生产者的情况下可以保证消息的顺序性。如果有多个生产者同时发送消息，无法确定消息到达 Broker 的前后顺序，也就无法验证消息的顺序性。

那么哪些情况下 RabbitMQ 的消息顺序性会被打破呢？

如果生产者使用了事务机制，在发送消息之后遇到异常进行了事务回滚，那么需要重新补偿发送这条消息，如果补偿发送是在另一个线程实现的，那么消息在生产者这个源头就出现了错序。同样，如果启用 publisher confirm 时，在发生超时、中断，又或者是收到 RabbitMQ 的 Basic.Nack 命令时，那么同样需要补偿发送，结果与事务机制一样会错序。或者这种说法有些牵强，我们可以固执地认为消息的顺序性保障是从存入队列之后开始的，而不是在发迭的时候开始的。

考虑另一种情形，如果生产者发送的消息设置了不同的超时时间，井且也设置了死信队列，整体上来说相当于一个延迟队列，那么消费者在消费这个延迟队列的时候，消息的顺序必然不会和生产者发送消息的顺序一致。

再考虑一种情形，如果消息设置了优先级，那么消费者消费到的消息也必然不是顺序性的。

如果一个队列按照前后顺序分有 msg1、msg2、msg3、msg4 这 4 个消息，同时有 ConsumerA 和 ConsumerB 这两个消费者同时订阅了这个队列。队列中的消息轮询分发到各个消费者之中，ConsumerA 中的消息为 msg1 和 msg3，ConsumerB 中的消息为 msg2、msg4。ConsumerA 收到消息 msg1 之后并不想处理而调用了 Basic.Nack/.Reject 将消息拒绝，与此同时将 requeue 设置为 true，这样这条消息就可以重新存入队列中。消息 msg1 之后被发送到了ConsumerB 中，此时 ConsumerB 己经消费了 msg2、msg4，之后再消费 msg1，这样消息顺序性也就错乱了。或者消息 msg1 又重新发往 ConsumerA 中，此时 ConsumerA 己经消费了 msg3，那么再消费 msg1，消息顺序性也无法得到保障。同样可以用在 Basic.Recover 这个 AMQP命令中。

包括但不限于以上几种情形会使 RabbitMQ 消息错序。如果要保证消息的顺序性，需要业务方使用 RabbitMQ 之后做进一步的处理，比如在消息体内添加全局有序标识（类似 SequenceID）来实现。

弃用 QueueingConsumer

QueueingConsumer 在 RabbitMQ 客户端 3.x 版本中使用得很多，但是在 4.x 版本开始就被标记为 @Deprecated。前面的实例代码中都是通过继承 DefaultConsumer 类来实现消费的（只有一个地方用了一次 QueueingConsumer）。

QueueingConsumer 本身有几个大缺陷，首先是内存溢出的问题，如果由于某些原因，队列之中堆积了比较多的消息，就可能导致消费者客户端内存溢出假死，于是发生恶性循环，队列消息不断堆积而得不到消化。QueueingConsumer的其他缺陷如下：

• QueueingConsumer 会拖累同一个 Connection 下的所有信道，使其性能降低。

• 同步递归调用 QueueingConsumer 会产生死锁。

• RabbitMQ 的自动连接恢复机制（automatic connection recovery可）不支持 QueueingConsumer 的这种形式。

• QueueingConsumer 不是事件驱动的。

综上，建议在消费的时候尽量使用继承 DefaultConsumer 的方式。

消息传输保障

消息可靠传输一般是业务系统接入消息中间件时首要考虑的问题，一般消息中间件的消息传输保障分为三个层级。

• At most once：最多一次。消息可能会丢失，但绝不会重复传输。

• At least once：最少一次。消息绝不会丢失，但可能会重复传输。

• Exactly once：恰好一次。每条消息肯定会被传输一次且仅传输一次。

RabbitMQ 支持其中的最多一次和最少一次。其中最少一次投递实现需要考虑以下这个几个方面的内容：

• 消息生产者需要开启事务机制或者 publisher confirm 机制，以确保消息可以可靠地传输到 RabbitMQ 中。

• 消息生产者需要配合使用 mandatory 参数或者备份交换器来确保消息能够从交换器路由到队列中，进而能够保存下来而不会被丢弃。

• 消息和队列都需要进行持久化处理，以确保 RabbitMQ 服务器在遇到异常情况时不会造成消息丢失。

• 消费者在消费消息的同时需要将 autoAck 设置为 false，然后通过手动确认的方式去确认己经正确消费的消息，以避免在消费端引起不必要的消息丢失。

最多一次的方式就无须考虑以上那些方面，生产者随意发送，消费者随意消费，不过这样很难确保消息不会丢失。

恰好一次是 RabbitMQ 目前无法保障的。考虑这样一种情况，消费者在消费完一条消息之后向 RabbitMQ 发送确认 Basic.Ack 命令，此时由于网络断开或者其他原因造成 RabbitMQ 并没有收到这个确认命令，那么 RabbitMQ 不会将此条消息标记删除。在重新建立连接之后，消费者还是会消费到这一条消息，这就造成了重复消费。再考虑一种情况，生产者在使用 publisher confirm 机制的时候，发送完一条消息等待 RabbitMQ 返回确认通知，此时网络断开，生产者捕获到异常情况，为了确保消息可靠性选择重新发送，这样 RabbitMQ 中就有两条同样的消息，在消费的时候，消费者就会重复消费。

那么 RabbitMQ 有没有去重的机制来保证恰好一次呢？答案是并没有，不仅是 RabbitMQ，目前大多数主流的消息中间件都没有消息去重机制，也不保障恰好一次。去重处理一般是在业务客户端实现，比如引入 GUID （Globally Unique Identifier）的概念。针对 GUID，如果从客户端的角度去重，那么需要引入集中式缓存，必然会增加依赖复杂度，另外缓存的大小也难以界定。建议在实际生产环境中，业务方根据自身的业务特性进行去重，比如业务消息本身具备幂等性，或者借助 Redis 等其他产品进行去重处理。