mq中间件

1、说说你们项目里是怎么用消息队列的？

         答案：比如我们有一个A系统，发送一个请求的时候要把系统B也更新，就会发送一条消息到MQ里面去，然后B系统从系统MQ获取消息，然后更新到B系统。

 

2、为什么使用消息队列？

答：使用消息队列的主要作用是：异步、解耦、削峰

　　(1)解耦

　　传统模式的缺点：系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！

　　中间件模式：将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。

　　(2)异步

　　传统模式缺点：一些非必要的业务逻辑以同步的方式运行，太耗时间。

　　中间件模式：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，以加快响应速度

　　(3)削峰

　　传统模式缺点：并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常

　　中间件模式：系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。

 

3、使用了消息队列会有什么缺点？

　　分析：一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好防御。

　　系统的可用性降低：如果消息队列挂了，那么系统也会受到影响

　　系统的复杂性增加：要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证消息可靠传输。因此，需要考虑的东更多，系统的复杂性增大。

 

4、如何保证消息队列的高可用？

　　剖析
　　这个问题用的很好，不会具体到某个MQ，而是问一个整体，然后通过你使用的MQ，来具体谈谈该MQ的可用性的理解。

　　RabbitMQ高可用性
　　RabbitMQ是比较有代表性的，因为是基于主从做高可用性的。

　　RabbitMQ 三种模式：单机模式，普通集群模式，镜像集群模式

 

5、如果保证消息的重复消费？

　　

　　首先是比尔RabbitMQ、RocketMQ、Kafka都会出现消息重复消费的问题，因为这个问题通常不是MQ自己保证的，而是保证消息的不丢失，我们首先从Kafka上来说：

　　kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，代表他的序号，然后consumer消费了数据之后，每隔一段时间，会把自己消费过的消息offset提交一下，代表我已经消费过了，下次我要是重启啥的，你就让我从上次消费到的offset来继续消费。

但是凡事总有以外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启，如果碰到着急的，直接kill杀死进程，然后重启，这就会导致consumer有些消息处理了没来得及提交offset，然后重启后，就会造成少数消息重复消费的问题。

消费者如果在准备提交offset，但是还没有提交的时候，消费者进程被重启，那么此时已经消费过数据的offset并没有提交，kafka也就不知道你已经消费了，那么消费者再次上线进行消费的时候，会把已经消费的数据，重新在传递过来，这就是消息重复消费的问题。

重复消费不可怕，重要的是有没有考虑过重复消费之后，怎么保证幂等性？

例如：有个系统，消费一条数据往数据库插入一条，要是消息重复消费了两次，那么就插入两条数据了，这个数据也就出错了。

 

6、幂等性是什么？

　　通俗点说：幂等性就是一个数据，或者一个请求，给你执行多次，得保证对应的数据不会改变，并且不能出错，这就是幂等性。

 

7、怎么保证消息队列消费的幂等性？

　　一条数据重复出现两次，但是数据库里只有一条数据，这就保证了系统的幂等性。

解决思路
比如那个数据要写库，首先根据主键查一下，如果这个数据已经有了，那就别插入了，执行update即可
如果用的是redis，那就没问题了，因为每次都是set操作，天然的幂等性
如果不是上面的两个场景，那就做的稍微复杂一点，需要让生产者发送每条消息的时候，需要加一个全局唯一的id，类似于订单id之后的东西，然后你这里消费到了之后，先根据这个id去redis中查找，之前消费过了么，如果没有消费过，那就进行处理，然后把这个id写入到redis中，如果消费过了，那就别处理了，保证别重复消费相同的消息即可。
还有比如基于数据库唯一键来保证重复数据不会重复插入多条，我们之前线上系统就有这个问题，就是拿到数据的时候，每次重启可能会重复，因为Kafka消费者还没来得及提交offset，重复数据拿到了以后，我们进行插入的时候，因为有了唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据。

 

7、如何保证消息传输不丢失？

　　

剖析
消息队列有三个重要原则：消息不能多，不能少

不能多，指的就是刚刚提到的重复消费和幂等性问题，不能少，指的是数据在传输过程中，不会丢失。

如果说使用MQ用来传递非常核心的消息，比如说计费，扣费的一些消息，比如设计和研发一套核心的广告平台，计费系统是一个很重的业务，操作是很耗时的，所以说广告系统整体的架构里面，实际是将计费做成异步化的，然后中间就是加了一个MQ。例如在广告主投放了一个广告，约定的是每次用户点击一次就扣费一次，结果是用户动不动就点击了一次，扣费的时候搞的消息丢了，公司就会不断的少几块钱。这样积少成多，这就是造成了公司的巨大损失。

为什么会丢数据
丢数据，一般分为两种，要么是MQ自己弄丢了，要么是我们消费的时候弄丢了。我们可以从RabbitMQ和Kafka分别来进行分析。

RabbitMQ一般来说都是承载公司的核心业务的，数据是绝对不能弄丢的。

 

8、百万消息积压在队列中如何处理？如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有百万消息积压接小时，说说解决思路？

剖析
MQ大幅度积压这件事挺常见的，一般不出，出了的话就是大型生产事故，例如：消费端每次消费之后要写MySQL，结果MySQL挂了，消费端就不动了，或者一直出错，导致消息消费速度极其慢。

场景1：积压大量消息
几千万的消息积压在MQ中七八个小时，这也是一个真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复consumer，让他恢复消费速度，然后傻傻的等待几个小时消费完毕，但是很显然这是一种比较不机智的做法。

假设1个消费者1秒消费1000条，1秒3个消费者能消费3000条，一分钟就是18万条，1000万条也需要花费1小时才能够把消息处理掉，这个时候在设备允许的情况下，如何才能够快速处理积压的消息呢？

一般这个时候，只能够做紧急的扩容操作了，具体操作步骤和思路如下所示：

先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停止
临时建立好原先10倍或者20倍的queue数量
然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
接着临时征用10倍机器来部署consumer，每一批consumer消费一个临时queue的数据
这种做法相当于临时将queue资源和consumer资源扩大了10倍，以正常的10倍速度

也就是让消费者把消息，重新写入MQ中，然后在用 10倍的消费者来进行消费。

 

场景2：大量消息积压，并且设置了过期时间
假设你用的是RabbitMQ，RabbitMQ是可以设置过期时间的，就是TTL，如果消息在queue中积压超过一定的时间，就会被RabbitMQ给清理掉，这个数据就没了。这个时候就不是数据被大量积压的问题，而是大量的数据被直接搞丢了。

这种情况下，就不是说要增加consumer消费积压的消息，因为实际上没有啥积压的，而是丢了大量的消息，我们可以采取的一个方案就是，批量重导，这个之前线上也有遇到类似的场景，就是大量的消息积压的时候，然后就直接丢弃了数据，然后等高峰期过了之后，例如在晚上12点以后，就开始写程序，将丢失的那批数据，写个临时程序，一点点查询出来，然后重新 添加MQ里面，把白天丢的数据，全部补回来。

假设1万个订单积压在MQ里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单查询出来，然后手动发到MQ里面去再补一次。

场景3：大量消息积压，导致MQ磁盘满了
如果走的方式是消息积压在MQ里，那么如果你很长时间都没有处理掉，此时导致MQ都快写满了，咋办？

这个时候，也是因为方案一执行的太慢了，只能写一个临时程序，接入数据来消费，然后消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到凌晨的时候，在把消息填入MQ中进行消费。

如何设计一个消息中间件架构？
如果让你写一个消息队列，该如何进行架构设计？说下你的思路

这种问题，说白了，起码不求你看过那些技术的源码，但是你应该大概知道那些技术的基本原理，核心组成部分，基本架构个构成，然后参照一些开源技术把一个系统设计出来的思路说一下就好了。

思路
首先MQ得支持可伸缩性，那就需要快速扩容，就可以增加吞吐量和容量，可以设计一个分布式的系统，参考kafka的设计理念，broker - > topic -> partition，每个partition放一台机器，那就存一部分数据，如果现在资源不够了，可以给topic增加partition，然后做数据迁移，增加机器，不就可以存放更多的数据，提高更高的吞吐量。
其次得考虑一下这个MQ的数据要不要落地磁盘？也就是需不需要保证消息持久化，因为这样可以保证数据的不丢失，那落地盘的时候怎么落？顺序写，这样没有磁盘随机读写的寻址开销，磁盘顺序读的性能是很高的，这就是kafka的思路。
其次需要考虑MQ的可用性？这个可以具体到我们上面提到的消息队列保证高可用，提出了多副本 ，leader 和follower模式，当一个leader宕机的时候，马上选取一个follower作为新的leader对外提供服务。
需不需要支持数据0丢失？可以参考kafka零丢失方案
其实一个MQ肯定是很复杂的，问这个问题其实是一个开放性问题，主要是想看看有没有从架构的角度整体构思和设计的思维以及能力