【RabbitMQ】如何保证消息的顺序性+解决消息积压+设计消息队列中间件_rabbitmq如何保证消息的顺序性

一、如何保证消息的顺序性

       啥？我该怎么保证从消息队列里拿到的数据按顺序执行。

       这是MQ面试必问的问题之一。第一看看你了解不了解顺序这个事，第二看看你有没有办法保证消息是有序的。这是生成环境中常见的问题。

       mysql的binlog同步。你再mysql里增删改3条binlog。接着这三条binlog发送到MQ里面。到消费出来依次执行。起码要保证人家是按照顺序来的吧。不然本来是增加、修改、删除。你愣是给更改了顺序，换成了删除、修改、增加。这就乱了。

       1、RabbitMQ可能出现数据错乱问题

                                    

        1个生产者，多个消费者。生成的顺序是数据1、数据2、数据3.消费的数据是数据2、数据1、数据3。没有按之前的顺序。

 

        2、如何保证消息的顺序性

                                  

       搞3个Queue，每个消费者就消费其中的一个Queue。把需要保证顺序的数据发到1个Queue里去。

二、如何解决消息积压

       如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百分消息持续积压几个小时，说说怎么解决。

       这些问法，本质上都是针对场景，都是说可能你的消息端出来问题，不消费了。或者消费的及其满。接着就坑爹了。可能你的消息队列集群的磁盘都快满了。都没人消费，这个时候怎么办？或者是积压了几个小时，怎么办？或者是积压时间太长了，导致比如RabbitMQ设置了过期时间后就没了。其实这事，线上挺常见的，一般不出，一出就是大case。举个例子，消费端每次消费之后要写mysql，结果mysql挂了，消费端不动了，或者是消费端出了什么叉子，导致消费速度灰常慢。

       1、快速处理积压的消息

       （1）大量消息在MQ里积压几个小时，还没解决

        几千万条数据在MQ里，积压了七八个小时。这个时候就是恢复consumer的问题。让它恢复消费速度，然后傻傻地等待几个小时消费完毕。这个肯定不能再面试的时候说。1个消费者1秒时1000条，1秒3个消费者是3000条。1分钟是18万条。1个小时是1000多万条。如果积压了上万条数据，即使消费者恢复了，也大概需要1个多小时才能恢复过来。

                         

        原来3个消费者1个小时。现在30个消费者，需要10分钟搞定。

        一般情况下，这个时候只能做临时扩容了。具体操作步骤和思路如下：

        ① 先修改consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。

        ② 新建1个topic，partition是原来的10倍，临时建立好原来10倍或者20倍的Queue。

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

        ④ 接着征用10倍的机器来部署consume。每一批consumer消费1个临时的queue。

        ⑤ 这种做法，相当于将queue资源和consume资源扩大10倍，以10倍的速度来消费数据。

        ⑥ 等快速消费完积压数据之后，恢复原来的部署架构，重新用原先的consumer来消费消息。

      （2）过期失效了怎么办

        过期失效就是TTL。如果消息在Queue中积压超过一定的时间就会被RabbitMQ给清理掉。这个数据就没了。这就不是数据积压MQ中了，而是大量的数据会直接搞丢。

        在这种情况下，增加consume消费积压就不起作用了。此时，只能将丢失的那批数据，写个临时的程序，一点一点查出来，然后再灌入MQ中，把白天丢失的数据补回来。

三、设计消息队列中间件

       如何让你来设计消息队列中间件，如何设计？

       主要考察两块。①是有没有对某个消息队列做过较为深入的原理的了解。或者从整体把握一个mq的架构原理。②是看看你的设计能力，给你一个常见的系统，就是消息队列系统，看能够从全局把握一下整体架构设计的关键点。

       比如说，这个消息队列，我们从以下几个方面来了解下：

       1、首先MQ得支持可伸缩性吧。就是需要的时候增加吞吐量和容量？

       2、其次，需要考虑一下MQ的数据是不是要持久化到磁盘

       3、再次，考虑一下MQ的可用性。

       4、最后，考虑一下能不能支持数据零丢失