系列博客目录
1.引言
目前的项目中比较常见,第一个是他提供了系统之间的异步调用,让服务与服务之间解耦,第二个是还可以做到削峰填谷。目前市面上消息中间件很多,主要讲下面两个。
简单的在文稿中,不在视频中讲解。
2.RabbitMQ
2.1 RabbitMQ如何保证消息不丢失?
RabbitMQ的作用如下:
上面都有可能导致消息丢失。第一个是消息未到达交换机或者队列,第二个是MQ宕机导致,第三个是消费者宕机导致(未接收到消息或者未处理消息)。
一下是针对这三种情况。
第一种:消息未到达交换机或者队列
那如果再失败呢?一般消息发送失败都是publisher宕机,一般不会一直宕机,如果一直宕机或者失败,只能交给人工。
第二种:如果MQ可能会宕机的话,如下
第三种:消费者宕机导致
面试文稿
- RabbitMQ如何保证消息不丢失?
候选人:
我们使用RabbitMQ来确保MySQL和Redis间数据双写的一致性,这要求我们实现消息的高可用性,具体措施包括:- 开启生产者确认机制,确保消息能被送达队列,如有错误则记录日志并修复数据。
- 启用持久化功能,保证消息在未消费前不会在队列中丢失,需要对交换机、队列和消息本身都进行持久化。
- 对消费者开启自动确认机制,并设置重试次数。例如,我们设置了3次重试,若失败则将消息发送至异常交换机,由人工处理。
2.2 RabbitMQ消息的重复消费问题如何解决?
在消费者进行自动确认时,发生网络抖动或者消费者挂了。那如果一条消息已经被消费者处理,但是没有被确认,他还是会再次被处理。
解决方案如下:
第一个方案是,在处理消息时,查看业务id是否存在,如果已经存在,说明数据库中已经有了消息所包含的内容,防止重复处理。
这两个方法,适用于任何MQ。
面试文稿
-
RabbitMQ消息的重复消费问题如何解决?
候选人:
我们遇到过消息重复消费的问题,处理方法是:- 设置消费者为自动确认模式,如果服务在确认前宕机,重启后可能会再次消费同一消息。
- 通过业务唯一标识检查数据库中数据是否存在,若不存在则处理消息,若存在则忽略,避免重复消费。
-
那你还知道其他的解决方案吗?
候选人:
是的,这属于幂等性问题,可以通过以下方法解决:- 使用Redis分布式锁或数据库锁来确保操作的幂等性。
2.3 RabbitMQ中死信交换机?(RabbitMQ延迟队列有了解过嘛)
延迟队列:进入队列的消息会被延迟消费的队列
场景:超时订单、限时优惠、定时发布
延迟队列=死信交换机+TTL(生存时间)
上面两种时间哪种短,就以哪种为主。
面试文稿
- RabbitMQ中死信交换机了解吗?(RabbitMQ延迟队列有了解过吗?)
候选人:
了解。我们项目中使用RabbitMQ实现延迟队列,主要通过死信交换机和TTL(消息存活时间)来实现。- 消息若超时未消费则变为死信,队列可绑定死信交换机,实现延迟功能。
- 另一种方法是安装RabbitMQ的死信插件,简化配置,在声明交换机时指定为死信交换机,并设置消息超时时间。
2.4 RabbitMQ如果有100万消息堆积在MQ,如何解决(消息堆积怎么解决)
面试文稿
- 如果有100万消息堆积在MQ,如何解决?
候选人:
若出现消息堆积,可采取以下措施:- 提高消费者消费能力,如使用多线程。
- 增加消费者数量,采用工作队列模式,让多个消费者并行消费同一队列。
- 扩大队列容量,使用RabbitMQ的惰性队列,支持数百万条消息存储,直接存盘而非内存。
2.5 RabbitMQ的高可用机制有了解过嘛
在生产环境下,使用集群来保证高可用性(其实很多技术都可以使用集群)
普通集群、镜像集群、仲裁队列
因为上面第三点,所以这种集群并不好用。
上面的节点表述的是一个橘色块中的队列。
还是存在一个问题,如果主节点的队列还没来得及给镜像节点同步数据,这时候主节点就宕机了,那是不是说数据还没有同步完成,就有可能丢失数据,虽然发生概率低。可以用仲裁队列来解决。
面试文稿
-
RabbitMQ的高可用机制了解吗?
候选人:
我们项目在生产环境使用RabbitMQ集群,采用镜像队列模式,一主多从结构。
- 主节点处理所有操作并同步给从节点,若主节点宕机,从节点可接替为主节点,但需注意数据同步的完整性。 -
那出现丢数据怎么解决呢?
候选人:
使用仲裁队列,主从模式,基于Raft协议实现强一致性数据同步,简化配置,提高数据安全性。
3 Kafka
3.1 Kafka是如何保证消息不丢失
面试文稿
- Kafka是如何保证消息不丢失?
候选人:
Kafka保证消息不丢失的措施包括:- 生产者使用异步回调发送消息,设置重试机制应对网络问题。
- 在Broker中通过复制机制,设置acks参数为all,确保消息在所有副本中都得到确认。
- 消费者手动提交消费成功的offset,避免自动提交可能导致的数据丢失或重复消费。
- Kafka中消息的重复消费问题如何解决?
候选人:
通过以下方法解决Kafka中的重复消费问题:- 禁用自动提交offset,手动控制offset提交时机。
- 确保消息消费的幂等性,例如通过唯一主键或分布式锁。
3.2 Kafka是如何保证消费的顺序性
面试文稿
- Kafka是如何保证消费的顺序性?
候选人:
Kafka默认不保证消息顺序性,但可以通过以下方法实现:- 将消息存储在同一个分区,通过指定分区号或相同的业务key来实现。
3.3 Kafka的高可用机制有了解过嘛
面试文稿
-
Kafka的高可用机制了解吗?
候选人:
Kafka的高可用性主要通过以下机制实现:- 集群部署,多broker实例,单点故障不影响整体服务。
- 复制机制,每个分区有多个副本,leader和follower,leader故障时从follower中选举新leader。
-
解释一下复制机制中的ISR?
候选人:
ISR(In-Sync Replicas)指与leader保持同步的follower副本。- 当leader故障时,优先从ISR中选举新leader,因为它们数据一致性更高。
3.4 Kafka数据清理机制了解过嘛
其中的文件名都是按照偏移量来存储的,方便使用。
面试文稿
- Kafka数据清理机制了解吗?
候选人:
Kafka的数据清理包括:- 基于消息保留时间的清理。
- 基于topic数据大小的清理,可配置删除最旧消息。
3.5 Kafka中实现高性能的设计有了解过嘛
面试文稿
- Kafka中实现高性能的设计有了解过吗?
候选人:
Kafka高性能设计包括:- 消息分区,提升数据处理能力。
- 顺序读写,提高磁盘操作效率。
- 页缓存,减少磁盘访问。
- 零拷贝,减少数据拷贝和上下文切换。
- 消息压缩,减少IO负载。
- 分批发送,降低网络开销。