MQ消息学习笔记

MQ笔记整理

各个MQ之间的对比：

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	同 ActiveMQ	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响			topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	ms级	微秒级，这是RabbitMQ的一大特点，延迟最低	ms级	延迟在ms级以内
可用性	高，基于主从架构实现高可用	同ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢	经过参数优化配置，可以做到0丢失	经过参数优化配置，可以做到0丢失
功能支持	MQ领域的功能极其完备	基于erlang开发，并发能力很强，性能极好，延时很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用

1.使用MQ的优点：

解耦、异步、错峰

1.1 解耦：

系统A发出数据，同时有B/C/D三个系统需要接收，且后续还可能增加或者减少，此事使用MQ即可大幅度提高灵活性

1.2 异步：

A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。
        最终请求总延时是 3 + 300 + 450 + 200 = 953ms，但如果使用MQ，则写入本地库3ms，发送MQ7ms，总共 3 + 7 = 10ms

1.3 错峰

2. 使用MQ的缺点以及问题处理：

2.1 系统可用性降低

系统引入的外部依赖越多，越容易挂掉。

RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的

RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式
    单机模式：几乎可以忽略不记，只会在本地自己玩
    普通集群模式：（无高可用性）
       在多台机器上启动多个 RabbitMQ 实例，每台机器启动一个，创建的queue，只会放在一个RabbitMQ 实例上,但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）
    镜像集群模式：（高可用性）
       镜像集群模式下，创建的queue，无论是元数据还是queue里的消息都会存在于多个实例上，每个RabbitMQ节点都有这个queue的一个完整镜像，包含queue的全部数据。然后每次写消息到queue的时候，都会自动把消息同步到多个实例的queue上。
       a. 某台服务器宕机不影响，从而达到高可用
       b. 性能开销也太大，消息需要同步到所有机器上，导致网络带宽压力和消耗很重
       c. 不是分布式就没有扩展性可言

Kafka 的高可用性

由多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据
0.8版本之前没有HA机制，任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言
0.8版本之后有了HA机制，如果某个broker宕机，那个broker上面的partition在其他机器上都有副本。如果这个宕机的broker上面有某个partition 的leader，那么此时会从follower中重新选举一个新的leader出来，大家继续读写那个新的leader即可
写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据就会发送ack给leader，leader收到所有follower的ac 之后，就会返回写成功的消息给生产者。

2.2 系统复杂度提高

2.2.1怎么保证消息没有重复消费？本质上还是问使用消息队列如何保证幂等性

比如 RabbitMQ、RocketMQ、Kafka，都有可能会出现消息重复消费的问题，正常。因为这问题通常不是 MQ 自己保证的，是由我们开发来保证的。
Kafka 实际上有个 offset 的概念，就是每个消息写进去，都有一个 offset，代表消息的序号，然后 consumer 消费了数据之后，每隔一段时间（定时定期），会把自己消费过的消息的 offset 提交一下，表示“我已经消费过了，下次我要是重启啥的，你就让我继续从上次消费到的 offset 来继续消费吧”。
但是凡事总有意外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启了，如果碰到点着急的，直接 kill 进程了，再重启。这会导致 consumer 有些消息处理了，但是没来得及提交 offset，尴尬了。重启之后，少数消息会再次消费一次。
有这么个场景。数据 a/b/c 依次进入 Kafka，Kafka 会给这三条数据每条分配一个 offset，代表这条数据的序号，假设分配的 offset 依次是 1/2/3 Kafka 去消费的时候，也是按照这个顺序去消费。假如当消费者消费了 offset=3 的这条数据，刚准备去提交 offset 到 Zookeeper，此时消费者进程被重启了。那么此时消费过的数据 a/b 的 offset 并没有提交，Kafka 也就不知道你已经消费了 offset=3 这条数据。那么重启之后，消费者会找 Kafka 说，嘿，哥儿们，你给我接着把上次我消费到的那个地方后面的数据继续给我传递过来。由于之前的 offset 没有提交成功，那么数据 a/b 会再次传过来，如果此时消费者没有去重的话，那么就会导致重复消费。
如果消费者干的事儿是拿一条数据就往数据库里写一条，会导致说，你可能就把数据 a/b 在数据库里插入了 2 次，那么数据就出错。
其实重复消费不可怕，可怕的是没考虑到重复消费之后，怎么保证幂等性。
假设有个系统，消费一条消息就往数据库里插入一条数据，要是一个消息重复两次，不就插入了两条，这数据不就错了？但是要是消费到第二次的时候，自己判断一下是否已经消费过了，若是就直接扔了，这样不就保留了一条数据，从而保证了数据的正确性。
一条数据重复出现两次，数据库里就只有一条数据，这就保证了系统的幂等性。
	幂等性，通俗点说，就一个数据，或者一个请求，给重复来多次，得确保对应的数据是不会改变的，不能出错。
所以第二个问题来了，怎么保证消息队列消费的幂等性？

其实还是得结合业务来思考，这里给几个思路：
    比如拿个数据要写库，先根据主键查一下，如果这数据都有了，就别插入了，update一下。
    比如是写 Redis，那没问题了，反正每次都是 set，天然幂等性。
    比如不是上面两个场景，那做的稍微复杂一点，需要让生产者发送每条数据的时候，里面加一个全局唯一的id，然后这里消费到了之后，先根据这个id去比如Redis里查一下，如果没有消费过，就处理，然后这个 id 写 Redis。如果消费过了，那就别处理了，保证别重复处理相同的消息即可。
    比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。

2.2.2 处理消息丢失的情况以及MQ消息一致性问题

RabbitMQ

生产者弄丢了数据

生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题等问题都有可能。
此时可以选择用 RabbitMQ 提供的事务功能，就是生产者发送数据之前开启 RabbitMQ 事务 channel.txSelect() ，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务 channel.txRollback() ，然后重试发送消息；如果收到了消息，那么可以提交事务 channel.txCommit() 。

   		  try {
               // 通过工厂创建连接
               connection = factory.newConnection();
               // 获取通道
               channel = connection.createChannel();
               // 开启事务
               channel.txSelect();
               // 发送消息
               channel.basicPublish(exchange, routingKey, MessageProperties.PERSISTENT_TEXT_PLAIN, msg.getBytes());
               // 模拟出现异常
               int result = 1 / 0;
               // 提交事务
               channel.txCommit();
           } catch (IOException | TimeoutException e) {
               // 捕捉异常，回滚事务
               channel.txRollback();
           }

但是问题是，RabbitMQ事务机制（同步）一搞，基本上吞吐量会下来，因为太耗性能。
所以一般来说，如果要确保说写RabbitMQ的消息别丢，可以开启confirm模式，在生产者那里设置开启confirm模式之后，每次写的消息都会分配一个唯一的id，然后如果写入了RabbitMQ中，RabbitMQ会给回传一个ack消息。如果RabbitMQ没能处理这个消息，会回调的一个nack接口，告知这个消息接收失败，可以重试。而且可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么可以重发。
事务机制和confirm机制最大的不同在于，事务机制是同步的，提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，发送个消息之后就可以发送下一个消息，然后那个消息 RabbitMQ 接收了之后会异步回调的一个接口通知这个消息接收到了。
所以一般在生产者这块避免数据丢失，都是用 confirm 机制的。

客户端实现生产者confirm有3种方式：

a.普通confirm模式：每发送一条消息后，调用waitForConfirms()方法，等待服务器端confirm，如果服务端返回false或者在一段时间内都没返回，客户端可以进行消息重发。

channel.basicPublish(ConfirmConfig.exchangeName, ConfirmConfig.routingKey, MessageProperties.PERSISTENT_TEXT_PLAIN, ConfirmConfig.msg_10B.getBytes());
    if (!channel.waitForConfirms()) {
        // 消息发送失败
        // ...
    }

   b.批量confirm模式：每发送一批消息后，调用waitForConfirms()方法，等待服务端confirm。
   channel.confirmSelect();
   for (int i = 0; i < batchCount; ++i) {
       channel.basicPublish(ConfirmConfig.exchangeName, ConfirmConfig.routingKey, MessageProperties.PERSISTENT_TEXT_PLAIN, ConfirmConfig.msg_10B.getBytes());
   }
   if (!channel.waitForConfirms()) {
       // 消息发送失败
       // ...
   }

c.异步confirm模式：提供一个回调方法，服务端confirm了一条或者多条消息后客户端会回调这个方法。

channel.basicPublish(ConfirmConfig.exchangeName, ConfirmConfig.routingKey, MessageProperties.PERSISTENT_TEXT_PLAIN, ConfirmConfig.msg_10B.getBytes());
    if (!channel.waitForConfirms()) {
         // 消息发送失败
         // ...
     }

     b.批量confirm模式：每发送一批消息后，调用waitForConfirms()方法，等待服务端confirm。
     channel.confirmSelect();
     for (int i = 0; i < batchCount; ++i) {
         channel.basicPublish(ConfirmConfig.exchangeName, ConfirmConfig.routingKey, MessageProperties.PERSISTENT_TEXT_PLAIN, ConfirmConfig.msg_10B.getBytes());
     }
     if (!channel.waitForConfirms()) {
         // 消息发送失败
         // ...
     }

消费端弄丢了数据

RabbitMQ如果丢失了数据，主要是因为消费的时候，刚消费到还没处理结果进程挂了，比如重启，RabbitMQ 认为消过，数据就丢失。
这个时候得用 RabbitMQ 提供的 ack 机制，简单来说就是必须关闭 RabbitMQ 的自动 ack ，可以通过一个 api 来调用就行，然后每次自己代码里确保处理完的时候，再在程序里 ack 一把。这样的话如果还没处理完，就没有ack，那RabbitMQ就认为还没处理完，这个时候RabbitMQ会把这个消费分配给别的consumer去处理，消息是不会丢的。
为了保证消息从队列种可靠地到达消费者，RabbitMQ提供了消息确认机制。消费者在声明队列时，可以指定noAck参数，当noAck=false，RabbitMQ会等待消费者显式发回ack信号后，才从内存（和磁盘，如果是持久化消息）中移去消息。否则，一旦消息被消费者消费，RabbitMQ 会在队列中立即删除它。

RabbitMQ 弄丢了数据

就是 RabbitMQ 自身弄丢数据，这个必须开启 RabbitMQ 的持久化，就是消息写入之后会持久化到磁盘，哪怕是 RabbitMQ 自己挂了恢复之后会自动读取之前存储的数据，一般数据不会丢。除非极其罕见的是，RabbitMQ 还没持久化，自己就挂了，可能导致少量数据丢失，但是这个概率较小。
设置持久化有两个步骤：
创建 queue 的时候将其设置为持久化。这样就可以保证RabbitMQ持久化queue的元数据，但是它是不会持久化queue里的数据的。
第二个是发送消息的时候将消息的deliveryMode设置为2。就是将消息设置为持久化的，此时RabbitMQ就会将消息持久化到磁盘上去。
必须要同时设置这两个持久化才行，RabbitMQ哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。
注意，哪怕是给RabbitMQ开启了持久化机制，也有一种可能，就是这个消息写到RabbitMQ中但是还没来得及持久化到磁盘上，此时RabbitMQ挂了，就会导致内存里的一点点数据丢失。
所以，持久化可以跟生产者那边的confirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，RabbitMQ 挂了，数据丢了，生产者收不到ack ，你也是可以自己重发的。

Kafka

消费端弄丢了数据

唯一可能导致消费者弄丢数据的情况，消费到了这个消息，然后消费者那边自动提交了offset，让Kafka以为已经消费了这个消息，但其实你才刚准备处理这个消息但还没处理，自己就挂了，此时这条消息即丢失。
Kafka会自动提交offset，那么只要关闭自动提交offset，在处理完之后自己手动提交offset，就可以保证数据不会丢。但是此时确实还是可能会有重复消费，比如刚处理完还没提交 offset，结果自己挂了，此时肯定会重复消费一次，需要自己保证幂等性。
Kafka消费者消费到了数据之后是写到一个内存的queue里先缓冲一下，结果有的时候刚把消息写入内存queue，然后消费者会自动提交offset。然后此时重启了系统，就会导致内存queue里还没来得及处理的数据就丢失了。

生产者会不会弄丢数据

如果按照上述的思路设置了acks = all ，一定不会丢，要求是leader 接收到消息，所有的 follower 都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。

Kafka弄丢了数据

比较常见的一个场景，Kafka某个broker宕机，然后重新选举partition的leader。要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，就丢了一些数据。
所以此时一般是要求起码设置如下 4 个参数：
给topic设置replication.factor 参数：这个值必须大于 1，要求每个 partition 必须有至少 2 个副本。
在 Kafka 服务端设置 min.insync.replicas 参数：这个值必须大于 1，这个是要求一个 leader 至少感知到有至少一个 follower 还跟自己保持联系，没掉队，这样才能确保 leader 挂了还有一个 follower。
在 producer 端设置 acks=all ：这个是要求每条数据，必须是写入所有 replica 之后，才能认为是写成功了。
在 producer 端设置 retries=MAX （很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了。
这样配置之后，至少在 Kafka broker 端就可以保证在 leader 所在 broker 发生故障，进行 leader 切换时数据不会丢失。

2.2.3 怎么保证消息传递的顺序性

顺序错乱场景举

RabbitMQ：一个 queue，多个 consumer。比如，生产者向 RabbitMQ 里发送了三条数据，顺序依次是 data1/data2/data3，压入的是 RabbitMQ 的一个内存队列。有三个消费者分别从 MQ 中消费这三条数据中的一条，结果消费者 2 先执行完操作，把 data2 存入数据库，然后是 data1/data3。
Kafka：比如说建了一个 topic，有三个 partition。生产者在写的时候其实可以指定一个 key，指定了某个订单 id 作为 key，那么这个订单相关的数据，一定会被分发到同一个 partition 中去，而且这个 partition 中的数据一定是有顺序的。
消费者从 partition 中取出来数据的时候，也一定是有顺序的。到这里，顺序还是 ok 的，没有错乱。我们在消费者里可能会搞多个线程来并发处理消息。因为如果消费者是单线程消费处理，而处理比较耗时的话，比如处理一条消息耗时几十 ms，那么 1 秒钟只能处理几十条消息，这吞吐量太低了。而多个线程并发跑顺序可能就乱掉。

解决方案

RabbitMQ：
   拆分多个queue，每个queue一个consumer，就是多一些queue；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理。
Kafka：
   方案1：一个 topic，一个 partition，一个consumer，内部单线程消费，单线程吞吐量太低，一般不会用这个。
   方案2：写N个内存queue，具有相同key的数据都到同一个内存queue；然后对于N个线程，每个线程分别消费一个内存queue即可，这样就能保证顺序性。

2.3 解决消息队列的延时以及过期失效问题以及消息队列满了以后该怎么处理

2.3.1 场景举例

假设一个场景，现在消费端出故障了，然后大量消息在mq里积压，如何进行处理解决？
几千万条数据在 MQ 里积压了七八个小时，这个时候要不然就是修复consumer，让它恢复消费速度，然后等待几个小时消费完毕。
一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条，一分钟就是 18 万条。所以如果你积压了几百万到上千万的数据，即使消费者恢复了也需要大概1小时的时间才能恢复过来。

2.3.2 解决方案

一般这种时候只能临时紧急扩容，具体操作步骤和思路如下：
   先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。
   新建一个topic，partition是原来的10倍，临时建立好原先10倍的queue数量。
   然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue。
   接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据。这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据。
   等快速消费完积压数据之后恢复原先部署的架构，重新用原先的consumer机器来消费消息。

2.3.3 特殊问题

mq中的消息过期失效

假设用的是RabbitMQ，RabbtiMQ是可以设置过期时间的，也就是TTL。如果消息在queue中积压超过一定的时间就会被RabbitMQ清理掉。那这就是第二个坑了。不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。
这个情况下，不是要增加consumer消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。可以采取一个方案，就是批量重导。就是大量积压的时候，可以直接丢弃数据了，然后等过高峰期之后，开始写程序将丢失的那批数据，写个临时程序一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来。

PS:此处大佬们有更好的办法欢迎评论，感觉这是个笨法子但又想不出来好方法。

假设1万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。

MQ快写满了

如果消息积压在mq里，很长时间都没有处理掉，此时导致 mq 都快写满了，这个还有别的办法吗？没有，临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据。

2.3.4 RocketMQ，官方针对消息积压问题，提供了解决方案

a. 提高消费并行度

绝大部分消息消费行为都属于IO密集型，即可能是操作数据库，或者调用RPC，这类消费行为的消费速度在于后端数据库或者外系统的吞吐量，通过增加消费并行度，可以提高总的消费吞吐量，但是并行度增加到一定程度，反而会下降。所以，应用必须要设置合理的并行度。如下有几种修改消费并行度的方法：
  a.a 同一个ConsumerGroup下，通过增加Consumer实例数量来提高并行度（需要注意的是超过订阅队列数的 Consumer 实例无效）。
  a.b 可以通过加机器，或者在已有机器启动多个进程的方式。 提高单个Consumer的消费并行线程，通过修改参数consumeThreadMin、consumeThreadMax 实现。

b. 批量方式消费

某些业务流程如果支持批量方式消费，则可以很大程度上提高消费吞吐量，例如订单扣款类应用，一次处理一个订单耗时1s，一次处理10个订单可能也只耗时2s，这样即可大幅度提高消费的吞吐量，通过设置consumer的consumeMessageBatchMaxSize返个参数，默认是1，即一次只消费一条消息，例如设置为N，那么每次消费的消息数小于等于N。

c. 跳过非重要消息

发生消息堆积时，如果消费速度一直追不上发送速度，如果业务对数据要求不高的话，可以选择丢弃不重要的消息。例如，当某个队列的消息数堆积到100000条以上，则尝试丢弃部分或全部消息，这样就可以快速追上发送消息的速度。示例代码如下：

 public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
                long offset = msgs.get(0).getQueueOffset();
                String maxOffset = msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET);
                long diff = Long.parseLong(maxOffset) - offset;
                if (diff > 100000) {
                    // TODO 消息堆积情况的特殊处理
                    return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
                }
                // TODO 正常消费过程
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }

d. 优化每条消息消费过程

举例如下，某条消息的消费过程如下：
   根据消息从 DB 查询【数据 1】
   根据消息从 DB 查询【数据 2】
   经过复杂的业务逻辑
   向 DB 插入【数据 3】
   向 DB 插入【数据 4】
这条消息的消费过程中有4次与DB的交互，如果按照每次5ms计算，那么总共耗时20ms，假设业务计算耗时5ms，那么总过耗时25ms，所以如果能把4次DB交互优化为2次，那么总耗时就可以优化到15ms，即总体性能提高了40%。所以应用如果对时延敏感的话，可以把DB部署在SSD硬盘，相比于SCSI磁盘，前者的RT会小很多。

3. 设计一个消息队列：

设计大体思路

1. 首先这个 mq 得支持可伸缩性，就是需要的时候快速扩容，就可以增加吞吐量和容量，设计个分布式的系统呗，参照一下 kafka 的设计理念，broker -> topic -> partition，每个 partition 放一个机器，就存一部分数据。如果现在资源不够给 topic 增加 partition，然后做数据迁移，增加机器，就可以存放更多数据，提供更高的吞吐量了
2. 其次得考虑一下这个 mq 的数据要不要落地磁盘，落磁盘才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是 kafka 的思路。
3. 再次考虑一下 mq 的可用性，这个具体参考之前可用性那个环节讲解的 kafka 的高可用保障机制。多副本 -> leader & follower -> broker 挂了重新选举 leader 即可对外服务。
4. 能不能支持数据 0 丢失？可以的，参考之前说的那个 kafka 数据零丢失方案。

mq 肯定是很复杂的，其实这是个开放题，有没有从架构角度整体构思和设计的思维以及能力。

后记：这是学习大佬的文章所整理的笔记，属于站在巨人的肩膀上摘果子，其中有些东西还是无法理解透彻，理论固然重要，但更要结合实际项目情况。
学海无涯，诸君共勉！