文章目录
  1. 1. 七、如何保证消息的顺序性?
    1. 1.1. rabbitmq
    2. 1.2. kafka
  2. 2. 八、该如何处理消息队列中的消息积压问题?
    1. 2.1. 1、为什么会发生消息积压?
    2. 2.2. 2、踩坑分析
      1. 2.2.1. (1)大量消息在mq里积压了几个小时了还没解决
      2. 2.2.2. (2)数据积压超时被mq清理掉
      3. 2.2.3. (3)mq直接快被写满
  3. 3. 九、如果让你写一个消息队列,该如何进行架构设计?

接上文,本文主要讨论MQ消息的顺序性保证、消息队列消息积压的处理、以及消息队列中间件的简单架构设计。


七、如何保证消息的顺序性?

MQ的顺序性是很重要的事情,对于消费顺序敏感的业务必须要保证生产端写入消息的顺序就是消费端消费的顺序。

什么情况下会乱呢?该如何规避?

rabbitmq

一个queue,多个consumer,会导致消息乱掉。

写入数据库的顺序应该是数据1、数据2、数据3,结果由于不同消费者写数据库的速度不同,可能变成了数据2、数据1、数据3。

解决方法很简单:拆分多个queue,每个queue一个consumer,需要顺序消费的消息只发送到某个特定的queue里,消费者消费的时候自然是顺序拉去,再顺序写入数据库。

kafka

一个topic,一个partition,一个consumer,内部多线程处理,这样会出问题。

解决方法:一个topic,一个partition,一个consumer,内部单线程消费,写N个内存queue,然后N个线程分别消费一个内存queue即可

八、该如何处理消息队列中的消息积压问题?

1、为什么会发生消息积压?

本质针对的场景,都是说,可能你的消费端出了问题,不消费了,或者消费的极其极其慢。

2、踩坑分析

(1)大量消息在mq里积压了几个小时了还没解决

几千万条数据在MQ里积压了七八个小时,从下午4点多,积压到了晚上很晚,10点多,11点多。

一般这个时候,只能操作临时紧急扩容了,具体操作步骤和思路如下:

1)先修复consumer的问题,确保其恢复消费速度,然后将现有cnosumer都停掉

2)新建一个topic,partition是原来的10倍,临时建立好原先10倍或者20倍的queue数量

3)然后写一个临时的分发数据的consumer程序,这个程序部署上去消费积压的数据,消费之后不做耗时的处理,直接均匀轮询写入临时建立好的10倍数量的queue

4)接着临时征用10倍的机器来部署consumer,每一批consumer消费一个临时queue的数据

5)这种做法相当于是临时将queue资源和consumer资源扩大10倍,以正常的10倍速度来消费数据

6)等快速消费完积压数据之后,得恢复原先部署架构,重新用原先的consumer机器来消费消息

(2)数据积压超时被mq清理掉

假设你用的是rabbitmq,rabbitmq是可以设置过期时间的,就是TTL,如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉,这个数据就没了。这就不是说数据会大量积压在mq里,而是大量的数据会直接搞丢。

我们可以采取一个方案,就是批量重导,等过了高峰期以后,如半夜,写程序,将丢失的那批数据,写个临时程序,一点一点的查出来,然后重新灌入mq里面去,把白天丢的数据给他补回来。

(3)mq直接快被写满

如果走的方式是消息积压在mq里,那么如果你很长时间都没处理掉,此时导致mq都快写满了。这个时候为了防止mq被直接打死,只能采取丢车保帅的策略,临时写程序,接入数据来消费,消费一个丢弃一个,都不要了,快速消费掉所有的消息。然后走第二个方案,到了晚上再补数据吧


九、如果让你写一个消息队列,该如何进行架构设计?

主要还是一些设计的思想吧,我们可以从以下几个角度来考虑。

(1)首先这个mq得支持可伸缩性吧,就是需要的时候快速扩容,就可以增加吞吐量和容量,那怎么搞?设计个分布式的系统呗,参照一下kafka的设计理念,broker -> topic -> partition,每个partition放一个机器,就存一部分数据。如果现在资源不够了,简单啊,给topic增加partition,然后做数据迁移,增加机器,不就可以存放更多数据,提供更高的吞吐量了?

(2)其次你得考虑一下这个mq的数据要不要落地磁盘吧?那肯定要了,落磁盘,才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊?顺序写,这样就没有磁盘随机读写的寻址开销,磁盘顺序读写的性能是很高的,这就是kafka的思路。

(3)其次你考虑一下你的mq的可用性啊?这个事儿,具体参考我们之前可用性那个环节讲解的kafka的高可用保障机制。多副本 -> leader & follower -> broker挂了重新选举leader即可对外服务。

(4)能不能支持数据0丢失啊?可以的,参考我们之前说的那个kafka数据零丢失方案

文章目录
  1. 1. 七、如何保证消息的顺序性?
    1. 1.1. rabbitmq
    2. 1.2. kafka
  2. 2. 八、该如何处理消息队列中的消息积压问题?
    1. 2.1. 1、为什么会发生消息积压?
    2. 2.2. 2、踩坑分析
      1. 2.2.1. (1)大量消息在mq里积压了几个小时了还没解决
      2. 2.2.2. (2)数据积压超时被mq清理掉
      3. 2.2.3. (3)mq直接快被写满
  3. 3. 九、如果让你写一个消息队列,该如何进行架构设计?