admin 管理员组文章数量: 1086019
2024年3月13日发(作者：全css实现各种样式)
C语言消息队列面试题及答案
1、为什么使用消息队列？
消息队列使用的场景和中间件有很多，但解决的核心问题主要是：异步、解耦、消峰
填谷。
2、消息队列的优缺点
异步、解耦、消峰填谷这是消息队列最大的优点，除了这些消息队列还可以会解决一
些我们特殊业务场景的问题。但是缺点主要在于系统的可用性、复杂性、一致性问题，引
入消息队列后，需要考虑MQ的可用性，万一MQ崩溃了岂不是要爆炸？而且复杂性明显
提高了，需要考虑一些消息队列的常见问题和解决方案，还有就是一致性问题，一条消息
由多个消费者消费，万一有一个消费者消费失败了，就会导致数据不一致。
3、如何保证消息队列的高可用？
由于笔者只使用和实践过RabbitMQ和Kafka，RocketMQ和ActiveMQ了解的不
深，所以分析一下RabbitMQ和Kafka的高可用。
(一)RabbitMQ
RabbitMQ有三种模式：单机模式，普通集群模式，镜像集群模式
(1)单机模式
单机模式平常使用在开发或者本地测试场景，一般就是测试是不是能够正确的处理消
息，生产上基本没人去用单机模式，风险很大。
(2)普通集群模式
普通集群模式就是启动多个RabbitMQ实例。在你创建的queue，只会放在一个
rabbtimq实例上，但是每个实例都同步queue的元数据。在消费的时候完了，上如果连
接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这
导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实
例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，
如果你开启了消息持久化，让RabbitMQ落地存储消息的话，消息不一定会丢，得等这个
实例恢复了，然后才可以继续从这个queue拉取数据。
这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
(3)镜像集群模式
镜像集群模式是所谓的RabbitMQ的高可用模式，跟普通集群模式不一样的是，你创
建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消
息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
优点在于你任何一个实例宕机了，没事儿，别的实例都可以用。缺点在于性能开销太
大和扩展性很低，同步所有实例，这会导致网络带宽和压力很重，而且扩展性很低，每增
加一个实例都会去包含已有的queue的所有数据，并没有办法线性扩展queue。
开启镜像集群模式可以去RabbitMQ的管理控制台去增加一个策略，指定要求数据同
步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，
应用这个策略，就会自动将数据同步到其他的节点上去了。
(二)Kafka
Kafka天生就是一个分布式的消息队列，它可以由多个broker组成，每个broker是
一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以
存在于不同的broker上，每个partition就放一部分数据。
kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上
的partition就废了，没法写也没法读，没有什么高可用性可言。
kafka 0.8以后，提供了HA机制，就是replica副本机制。kafka会均匀的将一个
partition的所有replica分布在不同的机器上，来提高容错性。每个partition的数据都会
同步到吉他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader
出来，那么生产和消费都去leader，其他replica就是follower，leader会同步数据给
follower。当leader挂了会自动去找replica，然后会再选举一个leader出来，这样就具
有高可用性了。
写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他
follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack
给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。(当
然，这只是其中一种模式，还可以适当调整这个行为)
消费的时候，只会从leader去读，但是只有一个消息已经被所有follower都同步成
功返回ack的时候，这个消息才会被消费者读到。
4、如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？
其实消息重复消费的主要原因在于回馈机制(RabbitMQ是ack，Kafka是offset)，在
某些场景中我们采用的回馈机制不同，原因也不同，例如消费者消费完消息后回复ack, 但
是刚消费完还没来得及提交系统就重启了，这时候上来就pull消息的时候由于没有提交
ack或者offset，消费的还是上条消息。
那么如何怎么来保证消息消费的幂等性呢？实际上我们只要保证多条相同的数据过来
的时候只处理一条或者说多条处理和处理一条造成的结果相同即可，但是具体怎么做要根
据业务需求来定，例如入库消息，先查一下消息是否已经入库啊或者说搞个唯一约束啊什
么的，还有一些是天生保证幂等性就根本不用去管，例如redis就是天然幂等性。
还有一个问题，消费者消费消息的时候在某些场景下要放过消费不了的消息，遇到消
费不了的消息通过日志记录一下或者搞个什么措施以后再来处理，但是一定要放过消息，
因为在某些场景下例如spring-rabbitmq的默认回馈策略是出现异常就没有提交ack，导
致了一直在重发那条消费异常的消息，而且一直还消费不了，这就尴尬了，后果你会懂的。
5、如何保证消息的顺序性？
版权声明：本文标题：C语言消息队列面试题及答案 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://roclinux.cn/p/1710280152a565870.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论