exchange：交换器名称。
type：交换器类型。
durable：是否持久化。
autoDelete：是否自动删除，前提是必须要有解绑动作，且是全部与这个交换器解绑。
internal：是否内置路由器，客户端无法直接发送消息到交换器，只能通过交换器路由到内置路由器。
argument：其它结构化参数。

argument：alternate-exchange（备份交换器）

Map<String, Object> args = new HashMap<String, Object>();

args.put("alternate-exchange", "exchangeName");

public AMQP.Exchange.DeleteOk exchangeDelete(String exchange, boolean ifUnused) throws IOException

删除交换器参数说明：

exchange：交换器名称。
ifUnused：是否未使用，true=交换器未使用时才会被删除，false=直接删除。

b、队列：

Queue.DeclareOk queueDeclare(String queue, boolean durable, boolean exclusive, boolean autoDelete, Map<String, Object> arguments) throws IOException;

定义队列参数说明：

queue：队列名称。
durable：是否持久化。
exclusive：是否排他，true=仅对首次创建它的连接可见，并在连接段开始自动删除；适用于同一个客户端同时发送读写消息的场景。
autoDelete：是否自动删除，当连接该队列的消费者都断开连接后，队列删除。
arguments：定义队列的参数列表。

arguments：

x-message-ttl：消息过期时间，单位ms。
x-expries：静置消息删除时间，单位ms。
x-max-length：队列消息最大长度。
x-max-length-bytes：队列最大占用空间大小，单位B。
x-dead-letter-exchange：死信队列交换器名称。
x-dead-letter-routing-key：死信队列路由键。
x-max-priority：队列优先级。
x-queue-mode：将消息保存在磁盘上，不存在内存中，当消费者开始消费时才加载到内存中。

通过x-dead-letter-exchange、x-dead-letter-routing-key实现死信队列（DLX）：

DLX实质就是一个交换器，只是在队列满足以下条件时会将消息转到DLX里：

消息被拒，且requeue=false
队列过期或队列达到最大长度

Queue.DeleteOk queueDelete(String queue, boolean ifUnused, boolean ifEmpty) throws IOException;

删除队列参数说明：

queue：队列名称。
ifUnused：无消费者消费时删除。
ifEmpty：队列无消息时删除。

c、生产者：

void basicPublish(String exchange, String routingKey, boolean mandatory, boolean immediate, BasicProperties props, byte[] body) throws IOException;

发送消息参数说明：

exchange：交换器名称。
routingKey：路由键。
mandatory：true=当发送的消息无法根据交换器类型和路由键匹配到合适的队列上时（自身未满足条件），将消息返回给生产者；false=将消息丢弃。
immediate：true=当路由到队列上时无任何消费者（他人不满足条件），则将消息返回给生产者；false=将消息丢弃。
props：消息的属性。
body：消息体。

d、消费者：

消费者有两种方式消费，一种是推（自动监听），一种是拉（手动获取单条消息）。

推：String basicConsume(String queue, boolean autoAck, String consumerTag, boolean noLocal, boolean exclusive, Map<String, Object> arguments, Consumer callback) throws IOException;

拉：GetResponse basicGet(String queue, boolean autoAck) throws IOException;

参数说明：

autoAck：是否自动确认消息已被消费。
noLocal：设置为ture时，不能将同一个connection生产的消息在此connection消费，也就是说一个connection不能同时为生产者和消费者。
exclusive：是否排他。
callback：接收到消息的回调函数，用于处理具体逻辑。

消息的确认与拒绝：

当消费消息autoAck=false时，消费者可以手动确认消息已消费。

void basicAck(long deliveryTag, boolean multiple) throws IOException;

参数说明：

multiple：true=确认消费该信道上deliveryTag标签之前所有未确认的消息。

拒绝单条消息：void basicReject(long deliveryTag, boolean requeue) throws IOException;

拒绝多条消息：void basicNack(long deliveryTag, boolean multiple, boolean requeue) throws IOException;

5、消息过期

RabbitMQ中消息过期分为两种，一种是队列过期，一种是消息过期。

队列过期就是设置queueDeclare的arguments的x-message-ttl，消息过期是通过发送消息的props参数确定。

AMQP.BasicProperties.Builder publishBuilder = new AMQP.BasicProperties.Builder();

// expiration单位ms

publishBuilder.expiration("10000");

channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY_NAME, publishBuilder.build(),

        "ttl".getBytes());

对于第一种TTL来说，队列一但过期就会删除掉；但对于第二种TTL来说，队列过期不会马上删除，而是等队列要被消费时再判断是否要删除。

那为什么会不一样呢，我们都知道mq对性能的要求是非常高的，如果第二种TTL的方式也要及时删除的话势必要扫描整个队列，这样的话，若队列长度较大是性能便会非常的差。

而第一种为什么可以做到及时删除呢，我们知道队列具有先进先出的特性，所以先入队的肯定要比后入队的要先过期，所以只要删除头部的就好啦。

而第二种的消息过期时间都是不固定的，考虑到MQ的性能，所以采用了上述的方式。

6、RabbitMQ实现延迟队列

a、DB轮询：通过job或其它逻辑将订单表的必要字段查出（如：orderId、createTime、status），当订单超过xx时间，将状态置为失效。

b、JDK DelayQueue：java api提供的延迟队列的实现，通过poll()、take()方法获取超时任务。

c、Redis sortedSet：通过zset类型的score来实现。

d、RabbitMQ TTL + DLX：使用RabbitMQ的过期时间和死信队列实现。

7、持久化

a、客户端不要设置自动确认消息（autoAck），而是由服务端确认。

b、发送端确认机制、镜像队列。

8、事务

a、开启事务：channel.txSelect()

b、提交事务：channel.txCommit()

c、回滚事务：channel.txRollback()

9、发送方确认机制

因为事务太过重量了，严重影响的RabbitMQ的吞吐量，所以RabbitMQ提供了一种更为轻量的方式，来保证生产者发送的消息真真的到达了RabbitMQ。

a、首先需要将信道设置为发送方确认模式

channel.confirmSelect();

b、然后通过waitForConfirms()或waitForConfirmsOrDie()确认消息已发送成功

boolean waitForConfirms(long timeout) throws InterruptedException, TimeoutException;

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

public class PublisherConfirmProduct {

    private static final String EXCHANGE_NAME = "demo.exchange";

    private static final String ROUTING_KEY = "demo.routingkey";

    private static final String QUEUE_NAME = "demo.queue";

    private static final String MESSAGE = "Hello World！";

    /**

     * 单条确认

     */

    public static void commonConfirm() throws Exception {

        Connection connection = RabbitMqUtils.getConnection();

        Channel channel = initChannel(connection);

        channel.confirmSelect();

        for (int i = 0; i < 100; i++) {

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

            if (channel.waitForConfirms()) {

                // 逐条确认是否发送成功

                System.out.println("send success!");

            }

        }

        RabbitMqUtils.close(connection, channel);

    }

    /**

     * 批量确认

     */

    public static void batchConfirm() throws Exception {

        Connection connection = RabbitMqUtils.getConnection();

        Channel channel = initChannel(connection);

        channel.confirmSelect();

        for (int i = 0; i < 100; i++) {

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

        }

        // 批量确认是否发送成功，如果某一次确认失败这一批都要重新发送

        if (channel.waitForConfirms()) {

            System.out.println("send success!");

        }

        RabbitMqUtils.close(connection, channel);

    }

    /**

     * 异步确认

     */

    public static void asyncConfirm() throws Exception {

        Connection connection = RabbitMqUtils.getConnection();

        Channel channel = initChannel(connection);

        channel.basicQos(1);

        channel.confirmSelect();

        // 定义一个未确认消息集合

        final SortedSet<Long> unConfirmSet = Collections.synchronizedNavigableSet(new TreeSet<>());

        for (int i = 0; i < 100; i++) {

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

            unConfirmSet.add(channel.getNextPublishSeqNo());

        }

        channel.addConfirmListener(new ConfirmListener() {

            @Override

            public void handleNack(long deliveryTag, boolean multiple) throws IOException {

                System.err.println(format("拒绝消息 deliveryTag:{0}, multiple:{1}", deliveryTag, multiple));

            }

            @Override

            public void handleAck(long deliveryTag, boolean multiple) throws IOException {

                System.err.println(format("确认消息 deliveryTag:{0}, multiple:{1}", deliveryTag, multiple));

                if (multiple) {

                    // multiple为true，则deliveryTag之前的所有消息全部被确认

                    unConfirmSet.headSet(deliveryTag + 1).clear();

                } else {

                    // 否则只确认一条消息

                    unConfirmSet.remove(deliveryTag);

                }

            }

        });

        TimeUnit.SECONDS.sleep(5);

        System.out.println(unConfirmSet.size());

        RabbitMqUtils.close(connection, channel);

    }

    private static Channel initChannel(Connection connection) throws IOException {

        Channel channel = connection.createChannel();

        channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT, true, false, null);

        channel.queueDeclare(QUEUE_NAME, true, false, false, null);

        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);

        return channel;

    }

    public static void main(String[] args) throws Exception {

//        commonConfirm();

//        batchConfirm();

        asyncConfirm();

    }

}

10、RabbitMQ管理

a、vhost：

Vhost（virtual host），其本质是一个独立的小型RabbitMQ服务器，拥有自己独立的队列、交换器以及绑定关系等，并且它拥有自己独立的权限。

客户端连接RabbitMQ时必须制定一个vhost，默认使用"/"。

也就是说一个RabbitMQ服务可以拥有很多个子RabbitMQ服务，这些子RabbitMQ服务可以为其它很多应用程序提供服务；这样可以减少RabbitMQ服务器搭建的成本。

b、角色与权限：

权限控制是以vhost为单位，创建用户时至少要指定一个vhost；对于用户来说可以跨vhost授权，不同的vhost可以有不同的权限。

角色：

none：无任何角色，新创建的用户默认角色为none。
management：可以访问web管理页面。
policymaker：包含management的所有权限，并可以管理策略(Policy) 和参数(Parameter)。
monitoring：包含management的所有权限，并可以看到所有连接、信道及节点相关信息。
administartor：包含minitoring的所有权限，并可以管理用户、虚拟主机、权限、策略、参数等。

11、RabbitMQ集群

a、为什么要集群：人多力量大，通过线性扩展来提高RabbitMQ的吞吐量。

b、集群后就能保证RabbitMQ的消息不丢失嘛：当然不能保证，默认情况下RabbitMQ的消息是不会在集群中复制的，节点宕机后消息就会丢失。

c、队列和交换器再集群中是以什么样的形式存在：队列不会复制，其它节点只存储了此队列所在节点的元数据；而交换器本质就是一个hashMap的映射，节点间会进行复制。

d、关于集群的建议：集群中至少要有一个磁盘节点（也就是持久化的RabbitMQ节点），虽然磁盘节点挂掉了依然可以发送和接受消息，但却不能执行创建队列、交换器、绑定关系等等操作。高可用的话建议至少两个磁盘节点，如果不确认如何选择磁盘节点与内存节点时建议全部选择磁盘节点，但这样的话会在一定程度上影响RabbitMQ的吞吐量。

12、镜像队列

RabbitMQ集群并不能保证队列的复制，而镜像队列就是用来解决这一问题的。它可以将对队列镜像到其它集群节点中，若集群中一个节点失效了它会自动切换到另一个镜像的节点上，来保证服务的可用性。

13、关于RabbitMQ性能优化的建议

影响RabbitMQ性能的因素有很多，主要的分为硬件性能与软件性能。

）硬件性能：如网络、内存、CPU等等。

）软件性能：消息持久化、消息确认、路由算法与绑定规则等等。

1、消息持久化：持久化会写入磁盘，多一次IO操作，设置非持久化可提升性能（durable=false）。

2、消息确认：消费者订阅队列时，设置自动确认也可以提升性能（autoAck=true）。

3、路由算法与绑定规则：fanout，只要绑定了交换器就可以匹配到，匹配规则少，性能肯定是绑定规则中最佳的；direct，除了交换器还需要匹配路由键，性能次之；topic，最复杂的匹配规则，相对其它两个性能最差。（比较fanout > direct > topic）

14、RabbitMQ实战

见 https://www.cnblogs.com/bzfsdr/p/11906222.html