常见消息队列对比

消息队列使用场景

• 异步

正常链路流程越长耗时越久越慢；那链路长了就慢了，但是其实有些流程其实可以同时做的，支付成功后，去校验优惠券的同时可以去增减积分，还可以同时发个短信。

用线程池或者多线程不是也可以么？解耦：

一个订单流程，扣积分，扣优惠券，发短信，扣库存。。。等等这么多业务要调用这么多的接口，每次加一个你要调用一个接口然后还要重新发布系统，写一次两次还好，写多了你就烦了。真的全部都写在一起的话，不单单是耦合这一个问题，出问题排查也麻烦，流程里面随便一个地方出问题搞不好会影响到其他的点，每个流程都try catch不就行了，相信我别这么做，这样的代码就像个定时炸弹💣。用了消息队列，耦合这个问题就迎刃而解了。

• 削峰

把请求放到队列里面，然后至于每秒消费多少请求，就看自己的服务器处理能力，能处理5000QPS你就消费这么多，可能会比正常的慢一点，但是不至于打挂服务器，等流量高峰下去了，服务也就没压力了。

• 解耦

使用消息队列的问题

技术是把双刃剑！没错用他是因为他带给我们很多好处，但是使用之后问题也是接踵而至。

系统复杂性

单独一个系统随便写，加入消息队列中间件后，要考虑维护。使用过程中还有其他的各种问题：消息重复消费、消息丢失、消息的顺序消费等等，反正用了之后就是贼烦。

数据一致性

是分布式服务本身就存在的一个问题，不仅仅是消息队列的问题，但是放在这里说是因为用了消息队列这个问题会暴露得比较严重一点。分布式事务：把下单，优惠券，积分。。。都放在一个事务里面一样，要成功一起成功，要失败一起失败。

可用性

引入一个中间件后，要保证高可用。万一挂了怎么办？https://www.cnblogs.com/mlyflow/p/10486558.html

如果有人问到你MQ的知识，高可用是必问的，因为MQ的缺点，我刚才已经说过了，有好多，导致系统可用性降低，等等。所以只要你用了MQ，接下来问的一些要点肯定就是围绕着MQ的那些缺点怎么来解决了。要是你傻乎乎的就干用了一个MQ，各种问题从来没考虑过，那你就悲剧了，面试官对你的印象就是，只会简单实用一些技术，没任何思考，马上对你的印象就不太好了。这样的同学招进来要是做个20k薪资以内的普通小弟还凑合。如果招进来做薪资20多k的高工，那就惨了，让你设计个系统，里面肯定一堆坑，出了事故公司受损失，团队一起背锅。	rabbitmq的高可用保证：镜像集群模式：这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue。 那么怎么开启这个镜像集群模式呢？rabbitmq有很好的管理控制台，在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
这个问题这么问是很好的，因为不能问你kafka的高可用性怎么保证啊？ActiveMQ的高可用性怎么保证啊？一个面试官要是这么问就显得很没水平，人家可能用的就是RabbitMQ，没用过Kafka，你上来问人家kafka干什么？这不是摆明了刁难人么。所以有水平的面试官，问的是MQ的高可用性怎么保证？这样就是你用过哪个MQ，你就说说你对那个MQ的高可用性的理解。

各大消息中间件对比

感谢：https://www.cnblogs.com/mlyflow/category/1412305.html