一、RabbitMQ的中的常用方法
1）exchangeDeclare ： 声明一个交换机
参数列表：
exchange - 交换机的名称
type - 交换机的类型 （fanout | direct | topic | header）
durable - 当前交换机是否持久化，true表示持久化，false表示非持久化，非持久化的交换机在rabbitmq服务关闭后，会消失。通常来说，交换机是否持久化，关系不大。
autoDelete - 是否自动删除，true表示会自动删除，自动删除的交换机，一旦有队列和交换机进行绑定，然后所有绑定的队列全部解绑，这个时候交换机就会自动删除。通常这个属性设置为false。
internal - 是否为内置交换机，true表示是内置交换机。提供者不能直接给内置交换机发送消息，内置交换机必须从其他的交换机中获得消息。通常这个属性设置为false。
arguments - 用来设置交换机的额外参数。
2）queueDeclare（重要）：声明一个队列
参数列表：
queue - 队列名称
durable - 是否为持久化队列，true表示持久化队列，一个非持久化队列，服务关闭后，队列消失。
exclusive - 是否为排他队列，true表示排他队列，一个排他队列只有声明这个队列的连接能够使用。
注意：1、其他的连接不能使用排他队列，同时也不能再去声明一个队列名相同的队列
2、排他队列是和创建的连接绑定的，连接声明的多个Channel是可以共享排他队列的
3、排他队列不能设置为持久化，一旦创建排他队列的连接关闭，排他队列自动删除
autoDelete - 是否为自动删除的队列，一个自动删除的队列，如果有消费者和它绑定，然后所有绑定的消费者进行了解绑，这个时候队列就会自动删除。
思考？如果一个队列是自动删除的队列，消费者和这个队列发生解绑时，
队列中还有消息没有消费，请问该队列是否自动删除？- 不会
arguments - 用来设置队列的额外属性。
3）queueBind（重要）：队列绑定交换机
参数列表：
queue - 绑定的队列名称
exchange - 绑定的交换机
routingKey - 路由键（fanout类型的交换机会忽略路由键）
arguments - 用来设置绑定的额外属性
二、RabbitMQ的过期时间
rabbitmq分为两种类型的过期时间：
1）消息的过期时间（重要）
· 通过队列的方式设置消息的过期时间 - 对队列中所有的消息有效
· 通过消息本身设置过期时间 - 只对当前设置的消息有效
注意：
1、如果一个过期消息，刚好是排在队头的，到期后，队列会自动的移除这个过期消息，但是如果一个过期消息没有排在队头，则消息过期后，队列不会移除，等这个消息到队头之后，才会被移除。
2、通过队列的方式设置消息的过期时间，一定是队头的数据最先过期
3、通过消息本身的方式设置过期时间，则最先过期的消息有可能出现在队中，这个时候，过期消息有可能不会被及时的移除掉。
2）队列的过期时间（了解）
给队列本身设置过期时间，实际开发过程中，很少进行这种设置。
三、死信队列
什么是死信队列？
当一个普通队列中，出现了死信消息时，消息会发送到对应的死信交换机，和这个死信交换机绑定的队列称之为死信队列
什么时候消息会成为死信消息？
· 消息过期后，会变成死信消息
· 当队列已满，继续添加消息，则队头的消息，会变成死信消息
· 当消费者拒绝消息后，并且requeue属性设置为false时，消息变成死信消息
如何设置一个死信队列？
四、延迟队列
什么是延迟队列？
提供者发送消息后，延迟一段时间，消费者才能消费消息，这种队列称之为延迟队列。
注意：RabbitMQ没有提供延迟队列，但是开发者可以通过死信队列 + TTL实现一个延迟队列
如何实现一个延迟队列？
延迟队列的实战模型：
延迟队列的运用场景：
五、消息的持久化
在RabbitMQ中，有3个种持久化方式：交换机持久化、队列持久化、消息持久化
消息如何持久化？
方式一：
方式二：
注意：
1、如果队列没有持久化，消息持久化没有意义
2、交换机有没有持久化，不影响消息持久化
3、每个持久化的消息，RabbitMQ都会将这条消息写入磁盘，所以如果大量的消息需要持久化，RabbitMQ的服务就需要将这些消息大量的写入磁盘，因此会严重的降低RabbitMQ的性能，所以，在实际开发过程中，应该只对需要绝对安全的数据进行持久化处理，从而尽可能的提高服务器的吞吐量。
问题：如果一个RabbitMQ的服务，交换机、队列、以及消息都是持久化的，能否保证消息的绝对安全？
不能。
六、RabbitMQ的消息确认机制（重要）
· 发送方的确认机制
发送方的确认机制用来确保提供者是否已经将消息写入RabbitMQ服务中，但是不保证消费者是否已经消费
1）事务机制
注意：
1、事务机制可以确保消息是否正常的发送到RabbitMQ的服务，如果执行了事务回滚，说明当前消息没有写入RabbitMQ中，这个时候就需要引入补偿机制，重发消息。
2、事务机制相对来说是一个同步的过程，发送方必须等待RabbitMQ的回复，才能确定当前消息是否发送成功。如果有大量的消息发送到RabbitMQ，那么事务机制势必影响程序的性能。
2）publisher confirm
因为事务机制的重量级，所以RabbitMQ提供了一种更加轻量级的事务确认机制 - publisher confirm
模式一：同步模式（性能和事务机制差不多）
模式二：异步模式
· 消费方的消息确认机制
手动确认：
手动拒绝：
消费方的消息数量的限制：
注意：发送方的确认机制和消费方的确认机制，都只能保证消息最少会被发送一次，有可能造成一个消息多次发送。
所以为了避免消息的重复消费，消费方的接口应该设置成幂等模式。
幂等：多次调用一个方法（接口），得到的结果永远一样。
七、RabbitMQ的运用场景
1、消息异步化
服务和服务之间，异步化处理消息
2、消息广播
发送方发布一次消息，多个接收方消费消息
3、消息延迟处理
延迟队列....
4、请求削峰