MQ消息队列

1、什么是消息队列

消息队列是用队列这种数据结构存储消息，一般用于进程间通信或线程间通信。

1.1 MQ基本框架

JMS中规定的消费模式有两种：P2P模式、Pub/Sub模式。针对这两种模式存在两种MQ基础框架：

• P2P模式：
  P2P模式包含三个角色：消息队列(Queue)、发送者(Sender)、接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。接收者在成功接收消息之后需向队列应答成功。
  
• Pub/Sub模式：
  Pub/Sub模式包含三个角色：主题(Topic)、发布者(Publisher)、订阅者(Subscriber) 。多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。
  

1.2 消息队列的优点

（1）消息通信
MQ的基础功能即为消息通信。使用MQ的客户端可以将消息发送到MQ中，也可以从MQ中消费消息。
（2）异步处理
生产者将消息生产放入MQ中，可以继续生产其他消息，不要求获得消费者的消费信号之后再生产。MQ也可以将RPC异步化。传统的RPC直接调用，可以转化为调用方生产消息，将原本RPC请求的内容放在消息体中，然后由RPC的被调用方去消费消息并进行处理。如果有返回结果，可以将结果再通过另外一个队列发送给调用方。
（3）应用解耦
将系统按照不同的业务功能拆分出来，消息生产者只管把消息发布到 MQ 中而不用管谁来取，消息消费者只管从 MQ 中取消息而不管是谁发布的。消息生产者和消费者都不知道对方的存在；
（4）削峰/限流：将所有请求都写到消息队列中，消费服务器按照自身能够处理的请求数从队列中拿到请求，防止请求并发过高将系统搞崩溃；

1.3 消息队列的缺点

（1）系统的可用性降低：系统引用的外部依赖越多，越容易挂掉，如果MQ 服务器挂掉，那么可能会导致整套系统崩溃。这时就要考虑如何保证消息队列的高可用了
（2）系统复杂度提高：加入消息队列之后，需要保证消息没有重复消费、如何处理消息丢失的情况、如何保证消息传递的有序性等问题；
（3）数据一致性问题：A 系统处理完了直接返回成功了，使用者都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，就会导致数据不一致了

1.4 消息队列比对

	ActiveMQ	RabbitMQ	RocketMQ	Kafka
开发语言	Java	erlang	Java	scala
单机吞吐量	万级（较低）	万级（较低）	10万级，支持高吞吐	10万级，支持高吞吐
时效性	ms级	us级，延迟最低	ms级	ms级以内
可用性	高，基于主从架构实现高可用	高，基于主从架构实现高可用	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢失	经过参数化配置，可以做到0丢失	经过参数化配置，可以做到0丢失
优点	功能成熟强大，在业内大量的公司和项目都有应用	基于erlang开发，并发能力强，性能极好，延时很低，管理界面非常棒，社区活跃	1. 性能、吞吐量经过阿里高并发业务的验证 2. 可靠性和可用性都不错、分布式扩展也方便 3. 源码是Java，方便公司定制化开发，支持复杂MQ业务场景	提供超高的吞吐量，极高的可靠性和可用性，分布式支持任意扩展
缺点	1. 有较低的概率丢失数据 2. 官方社区对ActiveMQ维护越来越少	1. 吞吐量较低 2. 基于erlang开发，国内缺乏对erlang源码级别的研究和定制的能力，依赖开源社区的维护和修复bug 2. 集群动态扩展会很麻烦	1. 社区活跃一般，阿里出台的技术，有可能这个技术被抛弃 2. 接口没有按照标准的JMS规范，有些系统迁移需要修改大量代码	1. 功能较为简单，只支持主要的MQ功能 2. 有可能消息重复消费，会对数据准确性造成影响
功能特性	主要用于解藕和异步来用，较少在大规模吞吐的场景中使用	基于erlang开发，并发能力强，性能极好，延时很低，管理界面较丰富	MQ功能较为完善，分布式扩展性好	天然适合大数据领域的实时计算以及日志收集

2、RabbitMQ

RabbitMQ 是 AMQP(高级消息队列协议) 协议的一个开源实现。

2.1、RabbitMQ如何保证消息不被重复消费

正常情况下，消费者在消费消息后，会给消息队列发送一个确认，消息队列接收后就知道消息已经被成功消费了，然后就从队列中删除该消息，也就不会将该消息再发送给其他消费者了。不同消息队列发出的确认消息形式不同，RabbitMQ是通过发送一个ACK确认消息。但是因为网络故障，消费者发出的确认并没有传到消息队列，导致消息队列不知道该消息已经被消费，然后就再次消息发送给了其他消费者，从而造成重复消费的情况。
重复消费问题的解决思路是：保证消息幂等性。

① 通过数据库：比如处理订单时，记录订单ID，在消费前，去数据库中进行查询该记录是否存在，如果存在则直接返回。
② 使用全局唯一ID，再配合第三组主键做消费记录，比如使用 redis 的 set 结构，生产者发送消息时给消息分配一个全局ID，在每次消费者开始消费前，先去redis中查询有没有消费记录，如果消费过则不进行处理，如果没消费过，则进行处理，消费完之后，就将这个ID以k-v的形式存入redis中(过期时间根据具体情况设置)。

2.2、RabbitMQ如何保证消息不丢失

对于消息的可靠性传输，每种MQ都要从三个角度来分析：生产者丢数据、消息队列丢数据、消费者丢数据。

2.2.1 生产者丢数据

RabbitMQ提供事务机制（transaction）和确认机制（confirm）两种模式来确保生产者不丢消息。

（1）事务机制：
发送消息前，开启事务（channel.txSelect()），然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()），如果发送成功则提交事务（channel.txCommit()）

该方式的缺点是生产者发送消息会同步阻塞等待发送结果是成功还是失败，导致生产者发送消息的吞吐量降下降。

（2）确认机制：
生产环境常用的是confirm模式。生产者将信道 channel 设置成 confirm 模式，一旦 channel 进入 confirm 模式，所有在该信道上发布的消息都将会被指派一个唯一的ID，一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个确认给生产者（包含消息的唯一ID），这样生产者就知道消息已经正确到达目的队列了。如果rabbitMQ没能处理该消息，也会发送一个Nack消息给你，这时就可以进行重试操作。

Confirm模式最大的好处在于它是异步的，一旦发布消息，生产者就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者便可以通过回调方法来处理该确认消息。

2.2.2 消息队列丢数据

处理消息队列丢数据的情况，一般是开启持久化磁盘。持久化配置可以和生产者的 confirm 机制配合使用，在消息持久化磁盘后，再给生产者发送一个Ack信号。这样的话，如果消息持久化磁盘之前，即使 RabbitMQ 挂掉了，生产者也会因为收不到Ack信号而再次重发消息。

持久化设置如下（必须同时设置以下 2 个配置）：
（1）创建queue的时候，将queue的持久化标志durable在设置为true，代表是一个持久的队列，这样就可以保证 rabbitmq 持久化 queue 的元数据，但是不会持久化queue里的数据；
（2）发送消息的时候将 deliveryMode 设置为 2，将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。

2.2.3 消费者丢数据

消费者丢数据一般是因为采用了自动确认消息模式。该模式下，虽然消息还在处理中，但是消费中者会自动发送一个确认，通知 RabbitMQ 已经收到消息了，这时 RabbitMQ 就会立即将消息删除。这种情况下，如果消费者出现异常而未能处理消息，那就会丢失该消息。

解决方案就是采用手动确认消息，设置 autoAck = False，等到消息被真正消费之后，再手动发送一个确认信号，即使中途消息没处理完，但是服务器宕机了，那 RabbitMQ 就收不到发的ack，然后 RabbitMQ 就会将这条消息重新分配给其他的消费者去处理。

但是 RabbitMQ 并没有使用超时机制，RabbitMQ 仅通过与消费者的连接来确认是否需要重新发送消息，也就是说，只要连接不中断，RabbitMQ 会给消费者足够长的时间来处理消息。另外，采用手动确认消息的方式，我们也需要考虑一下几种特殊情况:

• 如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ
  会认为消息没有被消费，然后重新分发给下一个订阅的消费者，所以存在消息重复消费的隐患
• 如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。

2、当设置 autoAck = False 时，如果忘记手动 ack，那么将会导致大量任务都处于 Unacked 状态，造成队列堆积，直至消费者断开才会重新回到队列。解决方法是及时 ack，确保异常时 ack 或者拒绝消息。
3、启用消息拒绝或者发送 nack 后导致死循环的问题：如果在消息处理异常时，直接拒绝消息，消息会重新进入队列。这时候如果消息再次被处理时又被拒绝 。这样就会形成死循环。

2.3、RabbitMQ如何保证消息有序

针对保证消息有序性的问题，解决方法就是保证生产者入队的顺序是有序的，出队后的顺序消费则交给消费者去保证。
（1）方法一：拆分queue，使得一个queue只对应一个消费者。由于MQ一般都能保证内部队列是先进先出的，所以把需要保持先后顺序的一组消息使用某种算法都分配到同一个消息队列中。然后只用一个消费者单线程去消费该队列，这样就能保证消费者是按照顺序进行消费的了。但是消费者的吞吐量会出现瓶颈。如果多个消费者同时消费一个队列，还是可能会出现顺序错乱的情况，这就相当于是多线程消费了
（2）方法二：对于多线程的消费同一个队列的情况，可以使用重试机制。

2.4、RabbitMQ如何处理消息堆积情况

2.4.1 原因

消息堆积往往是生产者的生产速度与消费者的消费速度不匹配导致的。有可能就是消费者消费能力弱，渐渐地消息就积压了，也有可能是因为消息消费失败反复复重试造成的，也有可能是消费端出了问题，导致不消费了或者消费极其慢。

2.4.2 临时扩容，快速处理积压的消息

（1）先修复 consumer 的问题，确保其恢复消费速度，然后将现有的 consumer 都停掉；
（2）临时创建原先 N 倍数量的 queue ，然后写一个临时分发数据的消费者程序，将该程序部署上去消费队列中积压的数据，消费之后不做任何耗时处理，直接均匀轮询写入临时建立好的 N 倍数量的 queue 中；
（3）接着，临时征用 N 倍的机器来部署 consumer，每个 consumer 消费一个临时 queue 的数据
（4）等快速消费完积压数据之后，恢复原先部署架构 ，重新用原先的 consumer 机器消费消息。

2.4.3 恢复队列中丢失的数据

如果使用的是 rabbitMQ，并且设置了过期时间，消息在 queue 里积压超过一定的时间会被 rabbitmq 清理掉，导致数据丢失。这种情况下，实际上队列中没有什么消息挤压，而是丢了大量的消息。所以就不能说增加 consumer 消费积压的数据了，这种情况可以采取 “批量重导” 的方案来进行解决。在流量低峰期，写一个程序，手动去查询丢失的那部分数据，然后将消息重新发送到mq里面，把丢失的数据重新补回来。

2.4.4 MQ长时间未处理导致MQ写满的情况如何处理

如果消息积压在MQ里，并且长时间都没处理掉，导致MQ都快写满了，这种情况肯定是临时扩容方案执行太慢，这种时候只好采用 “丢弃+批量重导” 的方式来解决了。首先，临时写个程序，连接到mq里面消费数据，消费一个丢弃一个，快速消费掉积压的消息，降低MQ的压力，然后在流量低峰期时去手动查询重导丢失的这部分数据。

2.5、RabbitMQ如何保证消息队列的高可用

RabbitMQ 是基于主从（非分布式）做高可用性的，RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。

2.5.1 单机模式

一般没人生产用单机模式

2.5.2 普通集群模式

普通集群模式用于提高系统的吞吐量，通过添加节点来线性扩展消息队列的吞吐量。也就是在多台机器上启动多个 RabbitMQ 实例，而队列 queue 的消息只会存放在其中一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。消费的时候，如果连接到了另外的实例，那么该实例就会从数据实际所在的实例上的queue拉取消息过来，就是说让集群中多个节点来服务某个 queue 的读写操作。

缺点：无高可用性，queue所在的节点宕机了，其他实例就无法从那个实例拉取数据；RabbitMQ 内部也会产生大量的数据传输。

2.5.3 镜像集群模式

镜像队列集群是RabbitMQ 真正的高可用模式，集群中一般会包含一个主节点master和若干个从节点slave，如果master由于某种原因失效，那么按照slave加入的时间排序，"资历最老"的slave会被提升为新的master。
镜像队列下，所有的消息只会向master发送，再由master将命令的执行结果广播给slave，所以master与slave节点的状态是相同的。

（1）缺点：
① 性能开销大，消息需要同步到所有机器上，导致网络带宽压力和消耗很重
② 非分布式，没有扩展性，如果 queue 的数据量大到这个机器上的容量无法容纳了，此时该方案就会出现问题了

3、Kafka

kafka是拉取模式的消息队列，是消费者控制什么时候拉取消息的；每条消息都有一个偏移量，每个消费者都会跟踪最近消费消息的偏移量。

3.1、Kafka如何保证消息不丢失

3.2、Kafka如何保证消息有序

3.3、Kafka如何实现幂等

kafka实现幂等的关键就是要实现broker的去重。为了实现消息发送的幂等性，kafka引入了两个概念：

• pid。每个新的producer在初始化的时候会被分配一个唯一的PID，这个PID对于用户是不可见的。
• Sequence Number。对于每个PID，该Producer发送数据的每个<Topic，Partition>都对应一个从0开始单调递增的Sequence Number。而borker端会对<PID，Topic，Partition>做缓存，当具有相同主键的消息提交的时，broker只会持久化一条。

3.4、Kafka消费重试机制