本章问题
消息通信概念—生产者、消费者和代理AMQP元素—交换机、队列和绑定虚拟主机消息持久化消息从生产到消费的生命周期rabbitmq扮演代理服务器（提供投递服务，==》邮局），在我的理解中消息队列使用的就是生产者消费者模式
生产者创建消息，消息包含两部分：有效载荷和标签（邮件）
有效载荷：传输的数据（内容）标签：决定谁来消费（收件人）消费者接收每一条消息都必须手动进行确认（邮件手动签收），或者设置在订阅队列时就自动确认（邮件自动签收==》消费者接收消息，rabbitmq自动视其确认了消息），消费者对消息的确认和告诉生产者消息已被接收这两件事毫不相关
rabbitmq收到消费者的确认后，才会认为消息投递成功并删除队列中的消息
信道建立在真实Tcp连接中的虚拟连接，AMQP命令都是通过信道传输的。因为对于操作系统而言建立和销毁Tcp连接代价十分高昂，所以引入信道概念（可以把Tcp连接想象成电缆，信道就是光纤）
direct交换器：路由键匹配，消息就被投递到对应的队列。此处路由键为warning的消息会被路由到Queue1，而路由键为info，warning，debug的消息会被路由到Queue2
fanout交换器：将消息广播到绑定的队列上
topic交换器：通配符匹配，以“.”为分隔，BindingKey中可以同时存在两种特殊字符串“*”和“#”，用于模糊匹配，其中”※“用于匹配一个单词，而“#”匹配一个或多个单词（可以是0个），以下图为例
路由键为"com.rabbitmq.client"的消息会同时路由到 Queue1 Queue2路由键为"com.hidden.client"的消息只会路由到 Queue2中路由键为"com.hidden.demo"的消息只会路由到 Queue2中路由键为"java.rabbitmq.demo"的消息只会路由到 Queue1中路由键为"java.uti l. concurrent" 的消息将会被丢弃或者返回给生产者(需要设置mandatory 参数) ，因为它没有匹配任何路由键。header交换器（基本不用，不做解释）
存放生产者发送的消息，消息的容器和终点
生产者发送消息给交换器，交换器根据特定规则投递到相应队列，这里的规则就是路由键（routing key），队列通过路由键绑定到交换器。
那么问题来了，如果消息的路由键为空（“”）或路由键没有匹配到任何绑定会发生什么？
路由键为空时交换机也会去尝试匹配绑定队列，若匹配（队列绑定的路由键为空），则投递到队列消息没有匹配到任何绑定时，消息会进入“黑洞”（彻底丢失）rabbitmq服务器可以创建多个虚拟消息服务器，称为”虚拟主机“（vhost），每个vhost都是mini版的rabbitmq服务器，拥有自己的队列、交换器、绑定等，还拥有自己的权限控制，从而达到各个实例间逻辑上的分离
如果都使用默认的vhost（/），非常容易产生命名冲突。所以对于通用模块（web日志）消息队列的使用，应创建属于自己的vhost，保证了安全性和可移植性
说了那么多，万一你的rabbitmq宕机，消息岂不是全丢了？
rabbitmq有自己的持久化策略：维护持久化日志文件。宕机重启后自动重建持久化交换器和队列并重播持久化日志文件的消息到合适的队列或交换器上
在消息发布前将它的”投递模式“选项设置为2（AMQP客户端会使用人性化常量来代替数值），此时发布的消息被标记为持久化消息，当消息被发布到持久化交换器中且到达持久化队列时，才算真正的持久化完成。因此消息可恢复的三个前提为：
投递模式设为持久发送到持久化交换器到达持久化队列rabbitmq会把持久化消息写入磁盘上的持久化日志文件，当消息到达持久化交换器时会被写入磁盘日志文件，写入成功后返回响应。此时又有一个问题，持久化日志文件何时移除消息：
持久化消息被路由到非持久化队列持久化消息被消费你肯定还会有疑问，生产者如何知道自己发送的消息被rabbit接收了？
事务，非常影响性能且会产生同步效果，背离使用mq的初衷
发送方确认模式（confirm模式）
将信道设置为confirm模式，信道上发布的消息都会被分配唯一ID号（从1开始），当消息到达匹配队列时信道会发送**发送方确认（包含消息的ID号）**给生产者，使生产者知道消息安全到达队列。如果消息是持久化消息，发送方确认会在消息写入磁盘后回执给生产者。
好处是更轻量，异步
