面试系列：消息队列（2）

继续脑补关于消息队列的面试，若是想了解基础篇，请看我的上一篇文章：面试系列：消息队列（1）。

（秃头面试官再一次拨通候选人小超子的电话）

面试官：上次我们聊了聊消息队列的基础，现在我们深入聊一下。

小超子：好的。

面试官：你遇到过消息队列挂了的情况么？你想想，要是MQ挂，消费者没有可消费的消息，可能会导致系统崩溃，那么如何保证MQ高可用？

小超子：就以我了解的RabbitMQ来说吧，它有一个镜像集群模式，每个RabbitMQ节点上的queue都有数据，消费者可以到任意节点上获取数据，即使某个节点宕机，在其他节点也能获取数据。

Tip:RabbitMQ怎么开启镜像集群模式?在Rabbitmq的管理控制台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，然后再次创建queue时，应用这个策略，就会自动将数据同步到其他的节点上了。（镜像集群模式存在一个问题，数据量很多时，可能导致部署MQ机器无法容纳，此时怎么解决？ 后续待解决。）

面试官：嗯，你遇到过消费者重复消费的问题么，如何保证不重复消费（或如何保证消费端的幂等性的）？

小超子：（内心嘀咕着，真没有）没有遇到过，但是了解一点，消费者重复消费可以理解为消费者将相同的数据处理重复插入到了数据库，那么消费者可以将消费过的数据记录下保存下来，比如保存在redis中，下一次消费的时候去判断下，防止多次消费。也可以基于数据库的唯一键，要是出现重复，会报异常。（具体的解决方案基于自己的业务场景）

面试官：消息队列的会不会出现数据丢失啊？

小超子：还是以我了解的RabbitMQ来说吧，它基本上是不会出现数据丢失的。

面试官：那它是怎么保证数据不会丢失的？

小超子：数据丢失可能发生在三个方面：（1）生产者将消息写到mq时，由于网络传输等问题搞丢数据了。RabbitMQ有一个事务重试机制和Confirm机制。事务重试就是生产者发送数据之前开启事务再发送数据，只要消息没有被RabbitMQ收到，那么生产者就会收到异常报错，就会回滚事务，然后重试发送消息，RabbitMQ收到消息之后就可以提交事务了。重试一个同步阻塞的过程，比较耗时。Confirm机制就是MQ接收到消息之后调用生产者提供的回调接口告诉生产者已收到消息,是一个异步的过程。（2）数据被MQ接收了，但消费者还没消费，MQ就挂了。这时需要rabbitmq开启持久化机制，步骤是1.创建queue时将其设置为持久化的，可以保证Rabbitmq持久化queue的元数据，2.发送消息时将消息的deliveryMode设置为2，将数据设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去，注意必须要同时设置这两个持久化才可以，那么在RabbitMQ回复服务之后就可以恢复数据了。（3）RabbitMQ有一个ack机制,是消费者在消费MQ的数据时会自动向MQ发送已处理的信息，但是有一个情况就是消费者已经自动ACK了，但消费者突然挂了，还没处理消息，但是MQ误以为这消息已经处理了。这就需要关闭消费者的自动Ack机制，应该由消费者在将消息消费完毕之后再将Ack确认已处理的标识发给MQ。

面试官：嗯，了解Rabbitmq如何保证消息的顺序性的么？

小超子：MQ里面的数据被多个消费者使用时，无法保证哪个消费者先消费，这就可能导致消费顺序错乱的问题。解决这个问题的方法就是将需要保证顺序性的数据放到一个固定的queue里面，只允许某个消费者单独去消费，那么就能保证消息的有序性了。

面试官：消费者挂了，消息队列堆积了很多数据怎么处理，甚至消息队列满了怎么办？

小超子：若是在堆积了大量数据后，消费者即使恢复了，也还需要一段时间才能将数据消费完毕。那么可以紧急扩容，临时增加消费者的数量，快点解决这个消息堆积的问题。队列满了的话，需要再增加MQ，避免再次出现数据，消息队列崩了，然后再快速消费堆积的数据。

面试官：看来你对消息队列掌握的还行，消息队列的问题就先问到这里了，后面我们再聊聊其他的。

小超子：好的。

（挂了电话，小超子内心还有点小窃喜，幸好问的问题都了解过）