mq 面试

老生常谈

顺序发送

   只用一个消费者去消费该队列
为了吞吐量的话，有多个消费者去消费怎么办？保证入队有序就行，出队以后的顺序交给消费者自己去保证，没有固定套路
   通过一定算法，将一组顺序消息发送到同一个broker下面的同一个队列，消费者进行顺序监听即可。
   例如：一条信息的唯一标识通过一定算法路由到同一个 broker 下到某一个队列下。通过业务层面处理。

   RocketMQ通过MessageQueueSelector中实现的算法来确定消息发送到哪一个队列上
   RocketMQ默认提供了两种MessageQueueSelector实现：随机/Hash
   当然你可以根据业务实现自己的MessageQueueSelector来决定消息按照何种策略发送到消息队列中。

丢失消息

   三个角度来分析：生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据。
   先持久化数据。
   生产端：可以指定发送次数，失败后异常处理
   消费端：重试-进行重新消费问题（注意幂等性问题，数据库或者分布式锁）。一般指定次数。超过限制则记录日志表进行人工补偿机制
   启用ack

重复消费消息

   如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念
   业务方面：
       1.消费端处理消息的业务逻辑保持幂等性
       2.保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现
       3.第三方介质,来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis。那消费者开始消费前，先去redis中查询有没消费记录即可。

消息积压问题

   解决办法
   1.对生产者发消息接口进行适当限流（不太推荐，影响用户体验）
   2.多部署几台消费者实例（推荐）
   3.适当增加 prefetch 的数量，让消费端一次多接受一些消息（推荐，可以和第二种方案一起用）
   4.增加消费者的多线程处理
   https://blog.csdn.net/hanguihb/article/details/123493103

原理及应用，原理和机制
消息中间件kafka，RabbitMQ等，掌握rocketMQ原理及集群布署

rocketmq
集群架构模型

       多Master模式：一个集群无Slave
           优点：配置简单，单个Master宕机或重启维护对应用无影响。
           缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响
       多 Master 多 Slave 模式 ，HA采用异步复制方式，主备有短暂消息延迟（毫秒级）
           优点：同时Master宕机后，消费者仍然可以从Slave消费
           缺点：Master宕机，磁盘损坏情况下会丢失少量消息。
       多 Master 多 Slave 模式，同HA采用同步双写方式，即只有主备都写成功，才向应用返回成功
           优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；
           缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。
       Dledger 模式
           采用 Master-Slave 架构来部署，能在一定程度上保证数据的不丢失，也能保证一定的可用性；
           缺陷很明显，最大的问题就是当 Master Broker 挂了之后，没办法让 Slave Broker 自动切换为新的 Master Broker
           ，需要手动更改配置将 Slave Broker 设置为 Master Broker，以及重启机器，这个非常麻烦。
           在手式运维的期间，可能会导致系统的不可用。
           使用 Dledger 技术要求至少由三个 Broker 组成，一个 Master 和两个 Slave，这样三个 Broker 就可以组成一个 Group ，也就是三个 Broker 可以分组来运行。
           一但 Master 宕机，Dledger 就可以从剩下的两个 Broker 中选举一个 Master 继续对外提供服务。
           三个 NameServer 极端情况下，确保集群的可用性，任何两个 NameServer 挂掉也不会影响信息的整体使用。