系统为什么要用MQ？一定要在分布式系统中使用吗？MQ有哪些中间件？他们有什么特点？MQ在给系统带来好处的同时，有没有带来什么问题？如何解决？在阿里的面试中，面试官问了几个关于MQ的问题：MQ在你项目中的作用？为什么选择这个MQ作为消息中间件？重复消费怎么办？如何保证消息被消费？是不是遇到了其他问题？然后带着问题先想一想。如果你有好的想法，可以在评论区留言，分享给大家。系统中消息中间件的使用MQ在系统中的作用是什么？抛开基本的消息发布和订阅，还有以下几点：分布式系统解耦，不需要立即返回。谷，不直接访问服务，缓解服务压力，增加性能日志分布式系统解耦在分布式系统中，要么通过rest调用，要么通过dubbo等RPC调用，但有些场景需要解耦设计，不能直接调用。例如在消息驱动的系统中，消息发送端完成本地业务并发送消息，多平台消息消费者服务需要接收推送的消息，然后继续处理其他业务。看这两张架构图，第一类BC直接依赖于A的服务，所以修改了A中的接口，BC也要相应修改，耦合度很高。第二种是使用MQ作为中间件来收发消息，而BC只依赖接收到的消息，而不依赖具体的接口，这样即使A服务修改或增加其他服务，也只需要订阅MQ即可。实时业务不需要异步处理以用户注册业务流程为例：用户注册、存储、用户验证邮件、用户验证短信发送，原来的系统设计，这样一个服务流程会串行处理，即,1-2-3先；但是这里大家可以想一想，如果在单服务单机的情况下有那么多注册用户，系统能抗得住吗？这里假设每个阶段的时间为1=50ms，2=50ms，3=50ms，那么一个请求就是all=150ms；这里再次假设本台服务器CPU=1，只能处理单线程，则根据本台单台服务器单线程的QPS计算；QPS=1000/150≈7现在我想把这个QPS*3增加三，这时候引入MQ服务作为中间件，如图。A服务用户注册完成后，直接返回。此时使用MQ发送异步处理消息，B、C服务分别处理。A不需要等待B和C的返回结果，所以用户体验只有50ms的等待时间。在邮件和短信阶段，由于网络延迟，用户可以接受一定时间的等待。对于一般的削峰填谷服务，我们接入系统的请求都是直接请求。这种模式在用户访问量不大的情况下问题不大。但是如果用户请求到了一定的瓶颈或者出现了一些问题，我们就需要考虑优化我们的架构设计，MQ中间件就是其中一种解决方案。下面以秒杀系统为例来分析一下问题。秒杀系统瞬间百万级并发。如何处理？一般秒杀系统会对请求进行过滤，无效的和重复的会被过滤掉，剩下的实际进入秒杀服务和订单服务。但是即便如此，并发度还是很高的。如果网关把所有的请求都转发给下游的订单服务，也会造成下游系统不堪重负，导致服务不可用甚至雪崩。真正的秒杀系统比较复杂，包括Nginx、网关、注册中心、redis缓存、mysql集群、消息队列集群。结束。如果秒杀服务处理请求数：1000/s，下游订单服务处理请求：10/s，为了不给下游订单服务造成压力，秒杀后的信息发送到队列，订单服务每秒可以从容处理十个请求。而不是不管人愿不愿意，直接塞1000个请求。至此，我们可以总结出秒杀系统的过滤方式：点击页面按钮一次，将每秒的请求限制置灰，比如100/s，可以使用Nginx和sentinel来过滤同一用户的重复请求，并使用唯一的用户ID和商品信息，将秒杀成功信息存入消息队列，由下游订单系统处理日志。所有服务都会将日志发送到MQ服务进行日志存储。MQ作为中间件来持久化日志，转发大数据服务，读取MQ，进行日志分析。MQ怎么选是性能比较，然后说RabbitMQ是世界上最好的MQ。。。你把选MQ比作选老婆，一上来就需要全套，白皙，美肌，前凸后翘和背翘，性感火辣，勤劳干练。..真是缺乏社会教育，兄弟，你受得了吗？能不能动不动就养一套保养包，1W/月？隔壁老王经常来你家吃饭，疯狂脑补。..食用安全吗？红枣+枸杞+肾宝片，恐怕是你气血足、气足了。让我们言归正传。其实我觉得这是一个需要思考的问题。我们首先要看的是条件是什么？1.用途？日志，解耦，还是异步处理2.公司情况？是否有充足的人员，目前人员技术栈情况，人员技术栈实力3.项目情况？项目周期、人员、用户量、架构设计、是否是老项目4、主流MQ现状？稳定性和可靠性、社区活动、全面的文档和云服务支持。上图中的示例日志消息是Kafka。为什么是卡夫卡？Kafka是LinkedIn开源的分布式发布订阅消息系统，属于Apache。拥有活跃社区的顶级项目。Kafka的主要特点是基于pull方式处理消息消费，追求高吞吐量。它最初的目的是收集和传输日志。之后的版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格的要求，适用于产生大量数据的互联网服务的数据采集业务。但是kafka比较重，需要依赖zookeeper。在大公司使用是没有问题的，维修时也少不了它。RocketMQ是阿里开源的可靠消息系统，并捐赠给Apache成为顶级项目。一开始它定位于非日志的可靠消息传输，但其实它在日志处理上的表现也不错。目前支持的客户端有java、c++、GO，社区比较活跃，文档也比较全面。但是要修改内核还是有难度的。毕竟阿里云是靠卖这个服务赚钱的。因此，如果企业对自己的实力没有信心，还是慎重选择为好。如果实在不行，可以直接购买云服务，省心省力。同样，这取决于实际情况。主流MQ的特点下图为图片来源网络。部分描述过时了，但基本上还不错。仅供参考：如何保证消息不被重复消费。大致是由于网络原因、服务重启等一些特殊原因导致消息消费没有被记录，造成重复消费的可能。一般的处理方式是保证接口设计的幂等性，目的是通过唯一标识来判断是否存在。1、使用redis缓存，将唯一的token保存在redis中，每次消费后删除token2。唯一主键判断，数据库判断主键记录是否存在，存在则更新，不存在则插入
