本章要点：RabbitMQ工作机制、简单应用等

第二章 RabbitMQ工作机制

一、工作机制

1. 消息通信基本概念
   • 生产者（应用）：创建消息，并推送到消息服务器
   • 代理（rabbitmq server）：也就是RabbitMQ Server本身（Broker），不产生消息，扮演【快递】的角色
   • 消费者（应用）：消息接受方，确认消息和处理数据

二、简单应用

1. 消息发送和连接

   • 程序和RabbitMq Server建立一个TCP连接并且进行验证（用户名和密码），验证通过后彼此间就建立了一个AMQP信道（channel）。
   • 信道是创建在TCP上的虚拟连接，所有的AMQP命令都是通过信道发送的。每个信道都有一个唯一的id，消息的创建、订阅和接收都是在信道完成。
   • 为何不直接用tcp发送命令。因为tcp的创建和销毁开销昂贵，且有限。如果一个请求只用一个TCP处理，然后命令在信道上发送，既能满足性能，又有较好的私密性。

2. 消息生产

   

3. 消息持久化

   • 默认情况下，rabbit中的消息不进行持久化，要想消息能从磁盘中恢复，必须满足：
     • 声明消息队列时，开启持久化参数：channel.queueDeclare(x, true, false, false, null)，参数2设置为true持久化
     • 投递时，设置参数存储到文本到磁盘：channel.basicPublish(x, x, MessageProperties.PERSISTENT_TEXT_PLAIN,x)，参数3设置为存储纯文本到磁盘
     • 消息已到达持久化的交换器上
     • 消息已到达持久化的队列
   • rabbit会将持久化消息写到日志文件，消费后标志此消息等待回收
   • 会影响性能，因为写入磁盘比写入内存更低效得多

4. 消息确认

   • 消费者收到消息后必须手动或者自动确认，否则rabbit会认为该消费方还没准备好接收消息，将不会再发送更多消息。此时队列中的消息状态也会是unacked状态，会重新发送给其他订阅者。
   • 可利用这一点特性，订阅者可延时确认消息（完成业务逻辑后），避免rabbit发送过多的消息导致程序崩溃。

5. 消息拒绝，消息确认前可有以下选择：

   • 断开rabbit连接，此时消息会重新发给其他订阅者
   • 使用rabbit提供的方法（channel.basicReject(long deliveryTag, boolean requeue)），拒绝消息：
     • 参数为true,重新回到队列
     • 参数为false，分配到【死信】队列（存放被拒绝而不重新回到正常队列的消息）