liuerchong的博客

首先来看看一线大厂的 架构图 一线大厂的 架构图 如上图所示，中间是我们的 MQ 集群架构， 在上层利用 keepalived 和 HA-Proxy， 最下面是 两个大的 MQ 集群 做一个高可用。当然了，在实际大厂里面 可能就不止 两个集群了，可以是很多个集群，然后集群之间利用 federration 插件进行数据同步 。 上面的生产端组件：这里面可能就有很多的架构设计，比如生产端怎么对一个容器进行缓存，举个例子，我们生产端发送消息，都是利用 RabbitTemplate 进行，...

如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？ 这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了，或者消费的极其极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是整个这就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，导致比如rabbitmq设置了消息过期时间后就没了怎么办？ 所以就这事儿，其实线上挺常见的，一般不出，一出就是大case，一般常见于...

如何保证消息的可靠性传输（如何处理消息丢失的问题）？ 这个是肯定的，用mq有个基本原则，就是数据不能多一条，也不能少一条，不能多，就是刚才说的重复消费和幂等性问题。不能少，就是说这数据别搞丢了。那这个问题你必须得考虑一下。 如果说你这个是用mq来传递非常核心的消息，比如说计费，扣费的一些消息，计费系统是很重的一个业务，操作是很耗时的。所以说广告系统整体的架构里面，实际上是将计费做成异步化的，然后中间就是加了一个MQ。 我们当时为了确保说这个MQ传递过程中绝对不会把计费消息给弄丢，花了...

如何保证消息只被消费一次 为了避免消息丢失，比方说某一条消息在处理之后，消费者恰好宕机了，那么因为没有更新消费进度，所以当这个消费者重启之后，还会重复地消费这条消息。为避免消息丢失可能造成消息重复消费。 rabbitmq、rocketmq、kafka，都有可能会出现消费重复消费的问题，正常。因为这问题通常不是mq自己保证的，是给你保证的。一般业务系统只有在写请求时才会有发送消息队列的操作，而一般系统的写请求的量级并不高，但是消息一旦被重复消费，就会造成业务逻辑处理的错误。那么我们要如何避免消息的重复.

1、 为什么使用消息队列啊？消息队列有什么优点和缺点啊？kafka、activemq、rabbitmq、rocketmq都有什么区别以及适合哪些场景？ （1）第一，你知道不知道你们系统里为什么要用消息队列这个东西？ 项目里用了redis、mq，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾没思考过。 没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。 （2）第二，你既然用了消息队列这个...

为什么需要保证消息队列的高可用? 虽然消息队列有着异步,解耦,削峰的优点,但是消息队列实际却是一种非常复杂的架构,它在解决一些技术方案难题的同时,也给系统的复杂度提升了一个数量级。 引入消息队列不仅提升了系统的复杂度,还大大降低了系统的可靠性,因为消息队列是外部中间件,系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？ 如果有人问到你MQ