消息队列面试题

1、主流消息队列和选型

引入队列的优缺点

• 优点：解耦系统、异步化、削峰。
• 缺点：系统可用性降低、复杂度增高、维护成本增高。

主流消息队列

主流消息队列Apache ActiveMQ、Kafka、RabbitMQ、RocketMQ

• ActiveMQ ：http://activemq.apache.org/
  • Apache出品，历史悠久，支持多种语言的客户端和协议，支持多种语言(Java, .NET, C++等)，基于JMS Provider的实现。
  • 缺点：吞吐量不高，多队列的时候性能下降，存在消息丢失的情况，比较少大规模使用。
• Kafka：http://kafka.apache.org/
  • 是由Apache软件基金会开发的⼀个开源流处理平台，由Scala和Java编写。
  • Kafka是⼀种高吞吐量的分布式发布订阅消息系统，它可以处理大规模的网站中的所有动作流数据(网页浏览，搜索和其他用户的行动)，副本集机制，实现数据冗余，保障数据尽量不丢失；支持多个生产者和消费者。
  • 缺点：不支持批量和⼴播消息，运维难度大，文档较少, 需要掌握Scala。
• RabbitMQ：http://www.rabbitmq.com/
  • 是⼀个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如：
    Python、Ruby、.NET、Java、JMS、C、用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不错。
  • 缺点：使用Erlang开发，阅读和修改源码难度大。
• RocketMQ：http://rocketmq.apache.org/
  • 阿里开源的⼀款的消息中间件, 纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点, 性能强劲(零拷贝技术)，支持海量堆积, 支持指定次数和时间间隔的失败消息重发,支持consumer端tag过滤、延迟消息等，在阿里内部进大规模使用，适合在电商，互联网金融等领域使用。
  • 缺点：成熟的资料相对不多，社区处于新生状态但是热度高。

2、消息队列的使用

消息队列的发送方式有哪几种？使用场景分别是怎样？

发送方式一般有三种：

• SYNC 同步发送：
  • 应用场景：重要通知邮件、报名短信通知、营销短信系统等。
• ASYNC 异步发送：
  • 应用场景：对RT时间敏感,可以支持更高的并发，回调成功触发相对应的业务，如注册成功后通知积分系统发放优惠券。
• ONEWAY 无需要等待响应：
  • 应用场景：主要是日志收集，适用于某些耗时非常短，但对可靠性要求并不高的场景, 也就是LogServer, 只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求不等待应答。

发送方式对比

什么是延迟消息？使用场景是怎样的？

延迟消息：

• Producer 将消息发送到消息队列 broker服务端，但并不期望这条消息立马投递，而是推迟到在当前时间点之后的某⼀个时间投递到 Consumer 进行消费。

使用场景：

• 通过消息触发⼀些定时任务，比如在某⼀固定时间点向用户发送提醒消息。
• 消息生产和消费有时间窗口要求，比如在天猫电商交易中超时未⽀付关闭订单的场景，在订单创建时会发送⼀条 延时消息。这条消息将会在 30 分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。 如支付未完成，则关闭订单。如已完成支付则忽略。

3、消息的顺序投递与消费

如何实现顺序消息？

什么是顺序消息：消息的生产和消费顺序一致。

• 全局顺序：topic下全部消息都要有序(少用)，性能要求不高，所有的消息严格按照 FIFO原则进行消息发布和消费的场景，并行度成为消息系统的瓶颈, 吞吐量不够。
  使用场景：在证券处理中，以人民币兑换美元为例子，在价格相同的情况下，先出价者优先处理，则可以通过全局顺序的方式按照 FIFO 的方式进行发布和消费。
• 局部顺序：只要保证⼀组消息被顺序消费即可，性能要求高。
  使用场景：电商的订单创建，同⼀个订单相关的创建订单消息、订单支付消息、订单退款消息、订单物流消息、订单交易成功消息 都会按照先后顺序来发布和消费。（阿里巴巴集团内部电商系统均使用局部顺序消息，既保证业务的顺序，同时又能保证业务的高性能）

以RocketMQ为例：（kafka或rabbitmq类似）
⼀个topic下有多个queue

• 顺序发布：对于指定的一个 Topic，客户端将按照一定的先后顺序发送消息。
  举例：订单的顺序流程是：创建、付款、物流、完成，订单号相同的消息会被先后发送到同⼀个队列中，根据MessageQueueSelector里面自定义策略，根据同个业务id放置到同个queue里面，如订单号取模运算再放到selector中，同⼀个模的值都会投递到同⼀条queue。
• 顺序消费：对于指定的⼀个 Topic，按照⼀定的先后顺序接收消息，即先发送的消息⼀定会先被客户端接收到。
  举例：消费端要在保证消费同个topic里的同个队列，不应该用MessageListenerConcurrently， 应该使用MessageListenerOrderly，自带单线程消费消息，不能再Consumer端再使用多线程去消费，消费端分配到的queue数量是固定的，集群消费会锁住当前正在消费的队列集合的消息，所以会保证顺序消费。

注意：

• 顺序消息暂不支持⼴播模式。
• 顺序消息不支持异步发送方式，否则将无法严格保证顺序。
• 不能再Consumer端再使⽤多线程去消费。

4、消息队列如何避免重复消费

幂等性：⼀个请求，不管重复来多少次，结果是不会改变的。
RabbitMQ、RocketMQ、Kafka等任何队列不保证消息不重复，如果业务需要消息不重复消费，则需要消费端处理业务消息要保持幂等性。

• 1）Redis的setNX() , 做消息id去重 java版本目前不支持设置过期时间。

//Redis中操作，判断是否已经操作过 TODO
boolean flag = jedis.setNX(key);
if(flag){
 //消费
}else{
 //忽略，重复消费
}

• 2）redis的 Incr 原子操作：key自增，大于0 返回值大于0则说明消费过，(key可以
  是消息的md5取值, 或者如果消息id设计合理直接用id做key)。

int num = jedis.incr(key);
if(num == 1){
 //消费
}else{
 //忽略，重复消费
}

• 3）数据库去重表：设计⼀个去重表，某个字段使用Message的key做唯⼀索引，因为存在唯⼀索引，所以重复消费会失败。

5、如何保证消息的可靠性传输

消息可靠性传输，是非常重要，消息如果丢失，可能带来严重后果，⼀般从是个角度去分析。

producer端：

• 不采⽤oneway发送，使用同步或者异步方式发送，做好重试，但是重试的Message key必须唯⼀。
• 投递的日志需要保存，关键字段，投递时间、投递状态、重试次数、请求体、响应体。

broker端：

• 多主多从架构，需要多机房。
• 同步双写、异步刷盘 (同步刷盘则可靠性更高，但是性能差点，根据业务选择)。
• 机器断电重启：异步刷盘，消息丢失；同步刷盘消息不丢失。
• 硬件故障：可能存在丢失，看队列架构

consumer端：

• 消息队列⼀般都提供的ack机制，发送者为了保证消息肯定消费成功，只有消费者明确表示消费成功，队列才会认为消息消费成功。中途断电、抛出异常等都不会认为成功，即都会重新投递，每次在确保处理完这个消息之后，在代码里调用ack，告诉消息队列消费成功。
• 消费端务必做好幂等性处理。
• 消息消费务必保留日志，即消息的元数据和消息体。

6、消息发送大量堆积应怎么处理

消息堆积了10小时，有几千万条消息待处理，现在怎么办?
修复consumer, 然后慢慢消费？也需要几小时才可以消费完成，新的消息怎么办？

核心思想：紧急临时扩容，更快的速度去消费数据

• 修复Consumer不消费问题，使其恢复正常消费，根据业务需要看是否要暂停。
• 临时topic队列扩容，并提高消费者力，但是如果增加Consumer数量，但是堆积的topic内的message queue数量固定，过多的consumer不能分配到message queue。
• 编写临时处理分发程序，从旧topic快速读取到临时新topic中，新topic的queue数量扩容多倍，然后再启动更多consumer进行在临时新的topic里消费。
• 直到堆积的消息处理完成，再还原到正常的机器数量。