RabbitMQ从入门到放弃
MQ的相关概念
什么是MQ？
MQ（message queue），从字面意思上看，本质是个队列，FIFO先进先出，只不过队列中存放的内容是message，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ是一种非常常见的上下游"逻辑解耦+物理解耦"的消息通信服务。使用MQ之后，消息发送上游只需要依赖MQ，不用依赖其他服务。<!--more-->
为什么要使用MQ？
-
流量削峰
-
应用解耦
-
异步处理
四大核心概念
生产者
产生数据发送消息的程序是生产者
交换机
交换机是RabbitMQ非常重要的一个组件，一方面它接受来自生产者的消息，另一方面它将消息推送到队列中。交换机必须确切知道如何处理它接受到的消息，是将这些消息推送到特定队列还是发送到多个队列，亦或者是把消息丢失，这个得由交换机类型决定
队列
队列是RabbitMQ内部使用得一种数据结构，尽管消息流经RabbitMQ和应用程序，但是它们只能存储到队列中。队列仅受主机得内存和磁盘限制的约束，本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列，许多消费者可以尝试从一个队列接收数据。这就是我们使用队列的方式。
消费者
消费和接受具有类似的含义，消费者大多时候是一个等待接受消息的程序。请注意生产者，消费者和消息中间件许多时候并不在同一机器上。同一个应用程序可以是生产者又可以是消费者。
Broker：接收和分发消息的应用，RabbitMQ Server就是Message Broker。
Connection：publisher/consumer和broker之间的TCP连接。
Channel：如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP Connection的开销将是巨大，效率也比较低。Channel是在connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别channel，所以channel之间是完全隔离的。channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。
Exchange：message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中。
Hello-World初识MQ
注意上方的MQ工作原理
生产者代码
public class Producer {
//队列名称
public static final String QUEUE_NAME = "hello";
//发消息
public static void main(String[] args) throws Exception {
//创建一个连接工厂
ConnectionFactory factory = new ConnectionFactory();
//工厂IP连接虚拟机
factory.setHost("192.168.58.129");
//账号和密码
factory.setUsername("root");
factory.setPassword("250259");
//创建连接
Connection connection = factory.newConnection();
//创建信道
Channel channel = connection.createChannel();
/**
* 生成一个队列
* 1.队列名称
* 2.队列里面的消息是否持久化(磁盘/内存)
* 3.该队列是否只提供一个消费者进行消费，是否进行消息的共享，如果是true可以供多个消费者消费
* 4.是否自动删除 最后一个消费者断开连接后 该队列是否自动删除
* 5.延迟消息...
*/
channel.queueDeclare(QUEUE_NAME, true, false, false, null);
//准备发消息
String message = "hello world";
/**
* 发送一个消息
* 1.发送到哪个交换机
* 2.路由的key值是哪个 本次的队列名称
* 3.其它参数信息-消息持久化
* 4.发送消息的消息体的字节
*/
channel.basicPublish("", QUEUE_NAME, MessageProperties.PERSISTENT_BASIC, message.getBytes());
System.out.println("消息发送完毕");
}
}
消费者代码
public class Consumer {
//队列名称
public static final String QUEUE_NAME = "hello";
//接受消息
public static void main(String[] args) throws Exception {
//创建连接工厂
ConnectionFactory factory = new ConnectionFactory();
//工厂IP连接虚拟机
factory.setHost("192.168.58.129");
//账号和密码
factory.setUsername("root");
factory.setPassword("250259");
//创建连接
Connection connection = factory.newConnection();
//创建信道
Channel channel = connection.createChannel();
/**
* 消费者消费消息
* 1.消费哪个队列
* 2.消费成功之后是否要自动应答
* 3.消费者成功消费的回调
* 4.消费者取消消费的回调
*/
//第三个参数
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println(new String(message.getBody()));
};
//第四个参数
CancelCallback cancelCallback = (consumerTag) -> {
System.out.println("消息消费被中断");
};
channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback);
}
}
WorkQueue
因为生产者消费者都有创建连接工厂ConnectionFactory，设置IP和账号密码，创建连接factory.newConnection()，创建信道connection.createChannel()等一系列重复操作所以首先将抽取重复代码创建工具类
/**
* 连接工厂工具类
*/
public class RabbitMqUtils {
public static Channel getChannel() throws Exception {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("192.168.58.129");
factory.setUsername("root");
factory.setPassword("250259");
Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
return channel;
}
}
工作队列(又称任务队列)的主要思想是避免立即执行资源密集型任务，而不得不等待它完成。相反我们安排任务在之后执行。我们把任务封装为消息并将其发送到队列。在后台运行的工作进程将弹出任务并最终执行作业。当有多个工作线程时，这些工作线程将一起处理这些任务。
/**
* 生产者可以发送大量的消息
*/
public class Task01 {
public static final String QUEUE_NAME = "hello";
public static void main(String[] args) throws Exception {
Channel channel = RabbitMqUtils.getChannel();
channel.queueDeclare(QUEUE_NAME, true, false, false, null);
//从控制台当中接收信息
Scanner scanner = new Scanner(System.in);
while (scanner.hasNext()) {
String message = scanner.next();
channel.basicPublish("", QUEUE_NAME, null, message.getBytes());
System.out.println("发送消息完成");
}
}
}
这里有一个细节开启单个类的多线程
/**
* 这是一个工作线程相当于之前的消费者
*/
public class Work01 {
public static final String QUEUE_NAME = "hello";
public static void main(String[] args) throws Exception {
Channel channel = RabbitMqUtils.getChannel();
//第三个参数
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println(new String(message.getBody()));
};
//第四个参数
CancelCallback cancelCallback = (consumerTag) -> {
System.out.println(consumerTag + "消费者取消消费接口回调逻辑");
};
System.out.println("C2等待接受消息......");
channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback);
}
}
消息应答
为了保证消息在发送过程中不丢失，rabbitmq 引入消息应答机制，消息应答就是:消费者在接收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了，rabbitmq 可以把该消息删除了。
自动应答
消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权衡,因为这种模式如果消息在接收到之前，消费者那边出现连接或者 channel 关闭，那么消息就丢失了,当然另一方面这种模式消费者那边可以传递过载的消息，没有对传递的消息数量进行限制，当然这样有可能使得消费者这边由于接收太多还来不及处理的消息，导致这些消息的积压，最终使得内存耗尽，最终这些消费者线程被操作系统杀死，所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。
其它应答
-
Channel.basicAck(用于肯定确认) RabbitMQ 已知道该消息并且成功的处理消息，可以将其丢弃了
-
Channel.basicNack(用于否定确认)
-
Channel.basicReject(用于否定确认) 与 Channel.basicNack 相比少一个参数，不处理该消息了直接拒绝，可以将其丢弃了
肯定应答Channel.basicAck()参数解释
void basicAck(long deliveryTag, boolean multiple) throws IOException;
参数multiple批量应答的解释
true代表批量应答 channel 上未应答的消息，比如说 channel 上有传送 tag 的消息 5,6,7,8 当前 tag 是 8 那么此时5-8 的这些还未应答的消息都会被确认收到消息应答。
false代表只会应答 tag=8 的消息 5,6,7 这三个消息依然不会被确认收到消息应答
消息自动重新入队
如果消费者由于某些原因失去连接(其通道已关闭，连接已关闭或 TCP 连接丢失)，导致消息未发送 ACK 确认，RabbitMQ 将了解到消息未完全处理，并将对其重新排队。如果此时其他消费者可以处理，它将很快将其重新分发给另一个消费者。这样，即使某个消费者偶尔死亡，也可以确保不会丢失任何消息。
消费者代码和之前并无差异，重点在于生产者代码。
public class Work01 {
public static final String TASK_QUEUE_NAME = "ack_queue";
public static void main(String[] args) throws Exception {
Channel channel = RabbitMqUtils.getChannel();
System.out.println("C1等待接受消息处理时间较短");
//第三个参数
DeliverCallback deliverCallback = (consumerTag, message) -> {
//沉睡一秒之后手动应答
SleepUtils.sleep(1);
System.out.println(new String(message.getBody()));
/**
* 1.消息的标记 tag
* 2.是否批量应答
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
};
//第四个参数
CancelCallback cancelCallback = (consumerTag) -> {
System.out.println(consumerTag + "消费者取消消费接口回调逻辑");
};
System.out.println("C1等待接受消息......");
//取消自动应答，改为手动应答
channel.basicConsume(TASK_QUEUE_NAME, false, deliverCallback, cancelCallback);
}
}
值得注意的是消费者1代码中与之前代码不同的是
-
关闭了自动应答，即第二个参数为false
-
成功消费之后的回调函数中进行了睡眠，此次消费者1睡眠时间较短，消费者2睡眠时间较长，在睡眠期间关闭程序以验证消息自动重新入队
临时队列
每当我们连接到 Rabbit 时，我们都需要一个全新的空队列，为此我们可以创建一个具有随机名称的队列，或者能让服务器为我们选择一个随机队列名称那就更好了。其次一旦我们断开了消费者的连接，队列将被自动删除。
String queueName = channel.queueDeclare().getQueue();
持久化
这里只讲代码层面
队列持久化
channel.queueDeclare(QUEUE_NAME, true, false, false, null)
消息持久化
channel.basicPublish("", QUEUE_NAME, MessageProperties.PERSISTENT_BASIC, message.getBytes())
将消息标记为持久化并不能完全保证不会丢失消息。尽管它告诉 RabbitMQ 将消息保存到磁盘，但是这里依然存在当消息刚准备存储在磁盘的时候 但是还没有存储完，消息还在缓存的一个间隔点。此时并没有真正写入磁盘。持久性保证并不强，需要发布确认来保证。
不公平分发
默认情况下，采用轮询分发，如果出现消费者消费速度不一致的情况轮询分发无法保证高吞吐所以我们可以设置为不公平分发
消费者代码设置channel.basicQos(1)
0轮询分发
1不公平分发
生产者分发10个消息，而消费者2只消费了一个消息，成功验证了不公平分发。
预取值
本身消息的发送就是异步发送的，所以在任何时候，channel 上肯定不止只有一个消息另外来自消费者的手动确认本质上也是异步的。因此这里就存在一个未确认的消息缓冲区，因此希望开发人员能限制此缓冲区的大小，以避免缓冲区里面无限制的未确认消息问题。这个时候就可以通过使用 basic.qos 方法设置“预取计数”值来完成的。该值定义通道上允许的未确认消息的最大数量。一旦数量达到配置的数量，RabbitMQ 将停止在通道上传递更多消息，除非至少有一个未处理的消息被确认，例如，假设在通道上有未确认的消息 5、6、7，8，并且通道的预取计数设置为 4，此时 RabbitMQ 将不会在该通道上再传递任何消息，除非至少有一个未应答的消息被 ack。比方说 tag=6 这个消息刚刚被确认 ACK，RabbitMQ 将会感知这个情况到并再发送一条消息。消息应答和 QoS 预取值对用户吞吐量有重大影响。
//分别设置work01和work02的预取值为2和4
channel.basicQos(2);
channel.basicQos(4);
可以看到work02确实只消费了4条消息
发布确认
发布确认原理
生产者将信道设置成 confirm 模式，一旦信道进入 confirm 模式，所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始)，一旦消息被投递到所有匹配的队列之后，broker就会发送一个确认给生产者(包含消息的唯一 ID)，这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会在将消息写入磁盘之后发出，broker 回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号，此外 broker 也可以设置basic.ack 的 multiple 域，表示到这个序列号之前的所有消息都已经得到了处理。confirm 模式最大的好处在于他是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果 RabbitMQ 因为自身内部错误导致消息丢失，就会发送一条 nack 消息，生产者应用程序同样可以在回调方法中处理该 nack 消息。
发布确认模式
单个确认
这是一种简单的确认方式，它是一种同步确认发布的方式，也就是发布一个消息之后只有它被确认发布，后续的消息才能继续发布。
这种确认方式有一个最大的缺点就是:发布速度特别的慢，因为如果没有确认发布的消息就会阻塞所有后续消息的发布，这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。
批量确认
与单个等待确认消息相比，先发布一批消息然后一起确认可以极大地提高吞吐量，当然这种方式的缺点就是:当发生故障导致发布出现问题时，不知道是哪个消息出现问题了，我们必须将整个批处理保存在内存中，以记录重要的信息而后重新发布消息。当然这种方案仍然是同步的，也一样阻塞消息的发布。
异步确认
异步发布确认和上文发布确认原理一致
如何处理异步未确认消息
最好的解决的解决方案就是把未确认的消息放到一个基于内存的能被发布线程访问的队列，比如说用 ConcurrentSkipListMap这个队列在 confirm callbacks 与发布线程之间进行消息的传递。
三种模式代码及对比
public class ConfirmMessage {
//批量发消息的个数
public static final int MESSAGE_COUNT = 1000;
public static void main(String[] args) throws Exception {
//单个确认发送1000条消息耗时1695ms
//publishMessageIndividually();
//批量发送消息，批量发布确认1000条消息耗时127ms
//publishMessageBatch();
//异步发布确认1000条消息耗时57ms
publishMessageBatchAsync();
}
//单个确认
public static void publishMessageIndividually() throws Exception {
Channel channel = RabbitMqUtils.getChannel();
String queueName = UUID.randomUUID().toString();
//开启队列持久化
channel.queueDeclare(queueName, true, false, false, null);
//开启发布确认
channel.confirmSelect();
long start = System.currentTimeMillis();
for (int i = 1; i <= MESSAGE_COUNT; i++) {
String message = i + "";
//开启消息持久化
channel.basicPublish("", queueName, MessageProperties.PERSISTENT_BASIC, message.getBytes());
//单个消息发布确认
boolean flag = channel.waitForConfirms();
if (flag) {
System.out.println("消息发送确认成功" + i);
}
}
long end = System.currentTimeMillis();
System.out.println("单个发送确认" + MESSAGE_COUNT + "条消息耗时" + (end - start) + "ms");
}
//批量发送消息，批量发布确认
public static void publishMessageBatch() throws Exception {
Channel channel = RabbitMqUtils.getChannel();
String queueName = UUID.randomUUID().toString();
//开启队列持久化
channel.queueDeclare(queueName, true, false, false, null);
//开启发布确认
channel.confirmSelect();
//批量确认大小
int batchCount = 100;
long start = System.currentTimeMillis();
for (int i = 1; i <= MESSAGE_COUNT; i++) {
String message = i + "";
//开启消息持久化
channel.basicPublish("", queueName, MessageProperties.PERSISTENT_BASIC, message.getBytes());
if (i % batchCount == 0) {
System.