面试官问的问题不是发散的，而是从点、铺开，比如先聊一聊高并发的话题，就这个话题里面继续聊聊缓存、MQ等等东西。对于每个小话题，比如说MQ，就会从浅入深。
首先明白为什么系统中要使用到消息队列这种东西？
因为之前面试的大量候选人，说自己项目中使用了Redis，MQ，但是其实他们并不清楚为什么要用这个东西，说白了就是为了用而用，或者是别人设计的架构，从头到尾就没有思考过。
没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常不好。
其实就是问问你消息队列有哪些场景，然后你项目里面的具体是什么场景，说说你在这个场景里用什么消息队列是什么？
消息队列的场景使用场景很多，主要是三个：解耦、异步、和削峰
A系统发送数据到B、C、D系统，但没有使用消息队列时候的耦合场景
当后面系统不断增加，比如 E，F系统的加入，以及D系统的移除
因为A系统和其它各种系统耦合起来，那么需要处理的事情会给出多
系统A发送一条消息，到消息队列中，哪个系统需要获取到哪里，那么从MQ中消费数据，如果新系统E加入的话，那么只需要编写代码，然后也直接从MQ中消费即可，当系统D不需要这个数据时，那么只需要不对该消息进行消费即可。系统A不需要考虑给谁发送数据，也不需要维护这个代码，不需要考虑人家是否调用成功、失败、超时等等情况
总结：通过一个MQ，发布和订阅模型，Pub/Sub模型，系统A就和其它系统彻底解耦。
需要考虑一下负责的系统中，是否有类似的场景，就是一个系统或者一个模块，调用了多个系统，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要同步调用接口的，如果用MQ给他异步化解耦，也是可以的，这个时候可以考虑在自己的项目中，是不是可以运用这个MQ来进行系统的解耦。
下面的一个场景就是系统A，调用了其它三个系统的服务，我们发现用户在执行一个请求后，需要花费很长的时间
我们发现，用户执行一个接口，就需要花费350毫秒，假设我们将每个接口的耗时增加，可能会将近花费1秒，这个时候一般用户几乎不能接受，因为一般互联网类的企业，对用户的直接操作，一般要求是每个请求都必须在200ms以内完成，因为这个是对用户是无感知的
系统A只需要发送消息到MQ中就直接返回了，然后其它系统各自在MQ中进行消费。用户在执行系统A的时候，就会感觉非常快就得到响应了。
一般的MySQL，抗到QPS=2000的时候就已经达到了瓶颈，如果每秒请求达到了5000的话，可能直接就把MySQL打死了。如果MySQL被打死，然后整个系统就崩溃，然后系统就没法使用。
但是中午的高峰期过了之后，到下午的时候，就成了低峰期，可能也就一万用户同时在网站上操作，每秒的请求数量可能就50个请求，对整个系统几乎没有任何压力。
削峰就是大量的请求过来，然后MQ将其消化掉了，然后通过其它系统从MQ中取消息，在逐步进行消费，保证系统的有序运行。一般高峰期不会持续太长，在一段时间后，就会被下游系统消化掉。
优点上面已经说了：解耦、异步、削峰，缺点呢？显而易见的
主流MQ包括：kafka、ActiveMQ、RabbitMQ和RocketMQ
常见的MQ其实就上面的四种
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，吞吐量比RocketMQ和Kafka要低一个数量级 | 万级，吞吐量比RocketMQ和Kafka要低一个数量级 | 10万级，RocketMQ也是可以支撑高吞吐的一种MQ | 10万级1这是kafka最大的优点，就是吞吐量高。一般配置和数据类的系统进行实时数据计算、日志采集等场景 |
| 时效性 | ms级 | 微妙级，这是RabbitMQ的一大特点，就是延迟最低 | ms级 | 延迟在ms级内 |
| 可用性 | 基于主从架构实现高可用 | 高，基于主从架构实现高可用 | 非常高，分布式架构 | 非常高，kafka是分布式的，一个数据多个副本，少数机器宕机后，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 消息不丢失 | 经过参数优化配置，可以做到0丢失 | 经过参数优化配置可以做到0丢失 |
| 核心特点 | MQ领域的功能及其完备 | 基于Erlang开发，所以并发能力强，性能及其好，延时很低 | MQ功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是实时上的标准。 |
| 非常成熟，功能强大，在业内大量公司以及项目都有应用。 但是偶尔消息丢失的概率，并且现在社区以及国内应用都越来越少，官方社区对ActiveMQ5.X维护越来越少，而且确实主要是基于解耦和异步来用的，较少在大规模吞吐场景中使用 | erlang语言开发的，性能及其好，延时很低。而且开源的版本，就提供的管理界面非常棒，在国内一些互联网公司近几年用RabbitMQ也是比较多一些，特别适用于中小型的公司 缺点显而易见，就是吞吐量会低一些，这是因为它做的实现机制比较中，因为使用erlang开发，目前没有多少公司使用其开发。所以针对源码界别的定制，非常困难，因此公司的掌控非常弱，只能依赖于开源社区的维护。 | 接口简单易用，毕竟在阿里大规模应用过，有阿里平台保障，日处理消息上 百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是OK的，还可以支撑大规模的topic数量，支持复杂MQ业务场景。 | 仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级别的延迟，极高的可用性以及可靠性，分布式可以任意扩展。 同时kafka最好是支撑较少的topic数量即可，保证其超高的吞吐量。 |
综上所述：
如果中小型企业技术实力一般，技术挑战不是很高，可以推荐，RabbitMQ。如果公司的基础研发能力很强，想精确到源码级别的掌握，那么推荐使用RocketMQ。同时如果项目是聚焦于大数据领域的实时计算，日志采集等场景，那么Kafka是业内标准。
这个问题用的很好，不会具体到某个MQ，而是问一个整体，然后通过你使用的MQ，来具体谈谈该MQ的可用性的理解。
RabbitMQ是比较有代表性的，因为是基于主从做高可用性的。
RabbitMQ 三种模式：单机模式，普通集群模式，镜像集群模式
就是demo级别的，一般就是本地启动后玩一玩，没有人生产环境中使用。
这里没有什么所谓的高可用性可言，这个方案主要就是为了解决吐吞量，就是集群中的多个节点来服务于某个queue的读写操作。
存在两个缺点
这种模式，才是RabbitMQ的高可用模式，和普通的集群模式不一样的是，你创建的queue无论元数据还是queue里的消息都会存在与多个实例中，然后每次你写消息到queu的时候，都会自动把消息推送到多个实例的queue中进行消息同步。
这样的好处在于，你任何一个机器宕机了，别的机器都可以用。坏处在于，性能开销提升，消息同步所有的机器，导致网络带宽压力和消耗增加，第二就是没有什么扩展性科研，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
那么如何开启集群镜像策略呢？就是在RabbitMQ的管理控制台，新增一个策略，这个策略就是镜像集群模式下的策略，指定的时候，可以要求数据同步到所有的节点，也可以要求就 同步到指定数量的节点，然后再次创建queue的时候，应用这个策略，就会自动将数据同步到其它节点上去了。
集群镜像模式下，任何一个节点宕机了都是没问题的，因为其他节点还包含了这个queue的完整的数据，别的consumer可以到其它活着的节点上消费数据。
但是这个模式还存在问题：就是不是分布式的，如果这个queue的数据量很大，大到这个机器上的容量无法容纳的时候，此时应该怎么办呢？
kafka一个最基本的架构认识：多个broker组件，每个broker是一个节点，你创建一个topic，这个topic可以划分成多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。
这就是天然的分布式消息队列，就是说一个topic的数据，是分散在多个机器上的，每个机器上就放一部分数据。
实际上RabbitMQ之类的，并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩，RabbitMQ一个queue的数据都放在一个节点里了，镜像集群下，也是每个节点都放这个queu的完整数据。
kafka0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法读也没办法写，没有什么高可用可言，而在0.8版本后，提供了HA机制，就是replica副本机制，每个partition的数据都会同步到其它机器上，形成自己的多个replica副本，然后所有的replica就是follower，写的时候，leader会负责数据都同步到所有的follower上，读的时候就直接读取leader上的数据即可。只能读写leader？很简单，要是你能随意读写每个follower，那么就需要保证数据一致性的问题，系统复杂度太高，很容易出问题，kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才能够提高容错性
每个副本不会存储节点的全部数据，而是数据可能分布在不同的机器上。
同时多个副本中，会选取一个作为leader，其它的副本是作为follower，并且只有leader能对外提供读写，同时leader在写入数据后，它还会把全部的数据同步到follower中，保证数据的备份。
此时，高可用的架构就出来了，假设现在某个机器宕机了，比如其中的一个leader宕机了，但是因为每个leader下还有多个follower，并且每个follower都进行了数据的备份，因此kafka会自动感知leader已经宕机，同时将其它的follower给选举出来，作为新的leader，并向外提供服务支持。
面试题：如何保证消息的重复消费？如何保证消息消费的幂等性？
其实这是一个常见的问题，既然是消费消息，那肯定是要考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？关于消息重复消费的问题，其实本质上就是问你使用消息队列如何保证幂等性，这个是你架构中要考虑的问题。
首先是比尔RabbitMQ、RocketMQ、Kafka都会出现消息重复消费的问题，因为这个问题通常不是MQ自己保证的，而是保证消息的不丢失，我们首先从Kafka上来说：
kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，代表他的序号，然后consumer消费了数据之后，每隔一段时间，会把自己消费过的消息offset提交一下，代表我已经消费过了，下次我要是重启啥的，你就让我从上次消费到的offset来继续消费。
但是凡事总有以外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启，如果碰到着急的，直接kill杀死进程，然后重启，这就会导致consumer有些消息处理了没来得及提交offset，然后重启后，就会造成少数消息重复消费的问题。
重复消费不可怕，重要的是有没有考虑过重复消费之后，怎么保证幂等性？
例如：有个系统，消费一条数据往数据库插入一条，要是消息重复消费了两次，那么就插入两条数据了，这个数据也就出错了。
消费者如果在准备提交offset，但是还没有提交的时候，消费者进程被重启，那么此时已经消费过数据的offset并没有提交，kafka也就不知道你已经消费了，那么消费者再次上线进行消费的时候，会把已经消费的数据，重新在传递过来，这就是消息重复消费的问题。
通俗点说：幂等性就是一个数据，或者一个请求，给你执行多次，得保证对应的数据不会改变，并且不能出错，这就是幂等性。
一条数据重复出现两次，但是数据库里只有一条数据，这就保证了系统的幂等性。
面试题：如何保证消息的可靠性传输（如何处理消息丢失的问题）？
消息队列有三个重要原则：消息不能多，不能少
不能多，指的就是刚刚提到的重复消费和幂等性问题，不能少，指的是数据在传输过程中，不会丢失。
如果说使用MQ用来传递非常核心的消息，比如说计费，扣费的一些消息，比如设计和研发一套核心的广告平台，计费系统是一个很重的业务，操作是很耗时的，所以说广告系统整体的架构里面，实际是将计费做成异步化的，然后中间就是加了一个MQ。例如在广告主投放了一个广告，约定的是每次用户点击一次就扣费一次，结果是用户动不动就点击了一次，扣费的时候搞的消息丢了，公司就会不断的少几块钱。这样积少成多，这就是造成了公司的巨大损失。
丢数据，一般分为两种，要么是MQ自己弄丢了，要么是我们消费的时候弄丢了。我们可以从RabbitMQ和Kafka分别来进行分析。
RabbitMQ一般来说都是承载公司的核心业务的，数据是绝对不能弄丢的。
生产者将数据发送到RabbitMQ的时候，可能数据就在半路给搞丢了，因为网络啥的问题，都有可能。
此时选择用RabbitMQ提供的事务功能，就是生产者发送数据之前，开启RabbitMQ事务（channel.txSelect），然后发送消息，此时就可以回滚事务（channel.txRollback），然后重试发送消息，如果收到了消息，那么可以提交事务，但是问题是，RabbitMQ事务机制一搞，基本上吞吐量会下来，因为太损耗性能。
所以一般来说，如果你要确保写RabbitMQ消息别丢，可以开启confirm模式，在生产者那里设置了开启confirm模式之后，RabbitMQ会给你回传一个ack消息，告诉你这个消息OK了，如果RabbitMQ没能处理这个消息，会给你回调一个接口，告诉你这个消息接收失败，你可以重试
// 开启事务
try {
// 发送消息
} catch(Exception e) {
// 重试发送消息
}
// 提交
但是，因为事务机制，是同步的
针对于上述事务造成性能下降的问题，下面的方法是开启confirm模式
首先把channel设置成confirm模式
然后发送一个消息
发送完消息之后，就不用管了
RabbitMQ如果接收到这个消息的话，就会回调你生产者本地的一个接口，通知你说这条消息我们已经收到了
RabbitMQ如果在接收消息的时候出错了，就会回调这个接口
一般生产者如果要保证消息不丢失，一般是用confirm机制，因为是异步的模式，在发送消息之后，不会阻塞，直接可以发送下一条消息，这样吞吐量会更高一些。
这个就是RabbitMQ自己丢失数据，这个时候就必须开启RabbitMQ的持久化，就是消息写入之后，同时需要持久化到磁盘中，哪怕是RabbitMQ自己宕机了，也能够从磁盘中读取之前存储的消息，这样数据一般就不会丢失了，但是存在一个极端的情况，就是RabbitMQ还没持久化的时候，就已经宕机了，那么可能会造成少量的数据丢失，但是这个概率是比较小的。
设置持久化的两个步骤，第一个是创建queue的时候，将其持久化的，这样就保证了RabbitMQ持久化queue的元数据，但是不会持久化queue中的数据，第二个就是发送消息的时候，将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时RabbitMQ将会将消息持久化到磁盘上，必须同时设置两个持久化才行，哪怕是Rabbit挂了，也会从磁盘中恢复queue 和 queue中的数据。
而且持久化可以跟生产者那边的confirm机制配置起来，只有消息被持久化到磁盘后，才会通知生产者ACK了，所以哪怕是在持久化磁盘之前，RabbitMQ挂了，数据丢了，生产者收不到ACK，你也是可以自己重发的。
消费者丢失数据，主要是因为打开了AutoAck的机制，消费者会自动通知RabbitMQ，表明自己已经消费完这条数据了，但是如果你消费到了一条消息，还在处理中，还没处理完，此时消费者就会自动AutoAck了，通知RabbitMQ说这条消息已经被消费了，此时不巧的是，消费者系统宕机了，这条消息就会丢失，因为RabbitMQ以为这条消息已经处理掉。
在消费者层面上，我们需要将AutoAck给关闭，然后每次自己确定已经处理完了一条消息后，你再发送ack给RabbitMQ，如果你还没处理完就宕机了，此时RabbitMQ没收到你发的Ack消息，然后RabbitMQ就会将这条消息分配给其它的消费者去处理。
以前做过一个MySQL binlog同步系统，压力还是非常大的，日同步数据要达到上亿。常见一点的在于 大数据项目中，就需要同步一个mysql库过来，然后对公司业务的系统做各种的复杂操作。
在mysql里增删改一条数据，对应出来的增删改3条binlog，接着这三条binlog发送到MQ里面，到消费出来依次执行，这个时候起码得保证能够顺序执行，不然本来是：增加、修改、删除，然后被换成了：删除、修改、增加，不全错了呢。
本来这个数据同步过来，应该是最后删除的，结果因为顺序搞错了，最后这个数据被保留了下来，数据同步就出错
在消息队列中，一个queue中的数据，一次只会被一个消费者消费掉
但因为不同消费者的执行速度不一致，在存入数据库后，造成顺序不一致的问题
RabbitMQ：拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦，或者就是一个queue，但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理。
下图为：一个consumer 对应 一个 queue，这样就保证了消息消费的顺序性。
一个topic，一个partition，一个consumer，内部单线程消费，写N个内存，然后N个线程分别消费一个内存queu即可。注意，kafka中，写入一个partition中的数据，一定是有顺序的，
但是在一个消费者的内部，假设有多个线程并发的进行数据的消费，那么这个消息又会乱掉
这样时候，我们需要引入内存队列，然后我们通过消息的key，然后我们通过hash算法，进行hash分发，将相同订单key的散列到我们的同一个内存队列中，然后每一个线程从这个Queue中拉数据，同一个内存Queue也是有顺序的。
如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有百万消息积压接小时，说说解决思路？
MQ大幅度积压这件事挺常见的，一般不出，出了的话就是大型生产事故，例如：消费端每次消费之后要写MySQL，结果MySQL挂了，消费端就不动了，或者一直出错，导致消息消费速度极其慢。
几千万的消息积压在MQ中七八个小时，这也是一个真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复consumer，让他恢复消费速度，然后傻傻的等待几个小时消费完毕，但是很显然这是一种比较不机智的做法。
假设1个消费者1秒消费1000条，1秒3个消费者能消费3000条，一分钟就是18万条，1000万条也需要花费1小时才能够把消息处理掉，这个时候在设备允许的情况下，如何才能够快速处理积压的消息呢？
一般这个时候，只能够做紧急的扩容操作了，具体操作步骤和思路如下所示：
也就是让消费者把消息，重新写入MQ中，然后在用 10倍的消费者来进行消费。
假设你用的是RabbitMQ，RabbitMQ是可以设置过期时间的，就是TTL，如果消息在queue中积压超过一定的时间，就会被RabbitMQ给清理掉，这个数据就没了。这个时候就不是数据被大量积压的问题，而是大量的数据被直接搞丢了。
这种情况下，就不是说要增加consumer消费积压的消息，因为实际上没有啥积压的，而是丢了大量的消息，我们可以采取的一个方案就是，批量重导，这个之前线上也有遇到类似的场景，就是大量的消息积压的时候，然后就直接丢弃了数据，然后等高峰期过了之后，例如在晚上12点以后，就开始写程序，将丢失的那批数据，写个临时程序，一点点查询出来，然后重新 添加MQ里面，把白天丢的数据，全部补回来。
假设1万个订单积压在MQ里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单查询出来，然后手动发到MQ里面去再补一次。
如果走的方式是消息积压在MQ里，那么如果你很长时间都没有处理掉，此时导致MQ都快写满了，咋办？
这个时候，也是因为方案一执行的太慢了，只能写一个临时程序，接入数据来消费，然后消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到凌晨的时候，在把消息填入MQ中进行消费。
如果让你写一个消息队列，该如何进行架构设计？说下你的思路
这种问题，说白了，起码不求你看过那些技术的源码，但是你应该大概知道那些技术的基本原理，核心组成部分，基本架构个构成，然后参照一些开源技术把一个系统设计出来的思路说一下就好了。
其实一个MQ肯定是很复杂的，问这个问题其实是一个开放性问题，主要是想看看有没有从架构的角度整体构思和设计的思维以及能力
一般而言，如果一个面试官水平还不错，会沿着从浅入深挖一个点，然后按着这个思路一直问下去，除了这里的七大问题之后，甚至还能挑着你熟悉的一个MQ一直问到源码级别，还可能结合项目来仔细问，先讲讲具体的业务细节，然后将业务跟这些MQ的问题场景结合起来，看看你的每个细节是如何处理和实现的。
原文：https://www.cnblogs.com/allenfortam/p/14700630.html