对线面试官 - MQ之如何保证消息的顺序性及消息积压问题

书接上文。这次继续聊一聊MQ

对线面试官-为什么要使用MQ

对线面试官 - MQ经典面试题之高可用性及幂等性

面试官：如何保证消息的顺序性，可以简单聊聊什么场景需要避免这种问题的发生以及如何解决吗？

派大星：当然可以。其实就MySQL而言来说，比如需要依赖MySQL 的binlog做一个同步系统。用户在MySQL中增删改一条数据，对应出来增删改3条binlog，接着将这3条binlog同步到MQ里面。然后到消费出来一次执行，此时就需要保证消息的顺序性，不然就会出现问题。

面试官：嗯，不错那你简单说说不同MQ消息错乱的一个场景吗？

派大星：可以的。

• 首先来说RabbitMQ：一个queue，多个consumer，这就会出现问题；因为多个消费者是同步一起执行的，无法保证顺序性，并且也无法保证消费者消费到了哪条数据。简单如图所示：

解决方案：每个消费者建立对应的queue，并且让保持顺序的消息只发送到一个queue上，这样消费者消费数据处理的时候就不会出现顺序错乱。

• 其次说一下Kafka：

首先来说Kafka是可以保证生产者写入一个partition的数据一定是有顺序的。

在Kafka使用中，只要Kafka内部不涉及多个线程并发处理的情况下，其实我们只需要在生产者写入数据的时候可以指定一个key，比如指定某个订单id作为key，这个订单相关的数据就会被分发到一个partition。这里我们要知道一个原则是Kafka一个partition只能被一个消费者消费，这样消费者从partition中取出来的数据一定是有顺序的。

面试官：什么情况下Kafka会出现消息顺序不一致的情况呢？

派大星：当消费者内部搞多个线程并发处理的时候，则可能会出现顺序不一致的问题。如图所示：

面试官：那如何解决Kafka多线程处理导致的消息错乱问题呢？

派大星：其解决方案可以是采用hash算法进行hash分发。相同的订单key的数据分发到同一个内存queue里面去。如图所示：

面试官：嗯，不错。那你在实际使用过程中有遇到过消息积压的问题吗？能说说遇到这种问题的时候你的解决思路是什么样的？

派大星：好的。其实在面对消息有积压的情况。多数都是消费者故障导致的。简单的解决思路如下：可以当做是一个临时紧急扩容的一个方案：

1. 如果consumer有问题，先修复consumer的问题，确保其恢复消费速度。然后将现有的consumer都停掉。
2. 临时建立好原先10倍或20倍的queue的数量。(Kafka-新建一个topic，partition是原来的十倍)
3. 写一个临时分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时处理，直接均匀轮询写入已经建立好10/20倍数量的queue中。
4. 接着临时征用10倍的机器来部署consumer，每一批consumer来消费一个临时queue的数据。
5. 最后等快速消费完积压的数据之后，得恢复原来部署架构，重新使用原来的consumer机器来消费。

面试官：不错。思路不错。突然有个问题，如何解决RabbitMQ中消息延时过期失效的问题？

派大星：RabbitMQ有一个TTL过期时间，关掉不要开启TTL。