Go最新消息队列这么多，用哪个哟？_消息队列一直用哪一种好，全球最火的程序员学习路线

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

1.异步

如果一个接口，处理时间很长，而且不能通过水平扩容来解决，就需要异步，那么，什么情况下不能通过水平扩容解决呢？

有很多，比如视频处理，涉及到视频下载，那受限于网络带宽等因素，扩容无用；比如区块链这种共识场景，只有单机才能出块，扩容也没有用；还有更常见的，比如一个业务流程，过了10多个微服务，单个也许不长，加起来就很难接受。

以上的情况下，用户很难通过同步接口长时间等待结果，那就应该做成异步，先扔进消息队列，后续再进行消费，响应时间可以从10s，降低到10ms。

2.消息分发

假设一个核心服务A，是用来发布某种信号的，发布之后，需要通知到下游服务B、C，这种模式在只有B、C两兄弟的时候，没啥问题。

但随着业务需要，可能会有D、E、F等更多的打工人出现，这时候A服务就需要更改代码，将消息也传递给这些新加入的兄弟，每次增加打工人，就需要更改一次代码。

而引入消息队列，则可以解决这个问题，实现能力复用，业务解耦。

3.削峰

业务有个概念叫峰值流量，也就说流量在一段时间远大于平时，从视图上看就像一个山峰。比如天猫双十一秒杀日，特别是0点的时候，流量起码是平常的千倍以上，如果不做好处理，一波就能彻底将服务打死。

如果常备1000倍流量的设备，那是极大的成本浪费，如果临时调配，进行服务扩容，很多时候又不如想象得简单。

之前有和Shopee的同学聊过，一到活动日他们就得紧锣密鼓去做扩容，扩容之后还得熬更守夜地做压测，不光劳命伤财、还容易出事故。

消息队列可以优雅地解决这个问题，将双十一的请求扔入消息队列，等待后续服务慢慢处理，如下图所示。

其实在架构上，削峰和上面的异步场景是相同的架构，都是将请求扔入队列中，再慢慢消费。

但要注意异步场景是单个请求，本身处理时间很长。削峰针对是单个请求ok，但是流量突发的场景。

消息队列能力对比

上面有提到几个知名的消息队列，其中ZeroMQ太过轻量，主要用于学习，实际是不会应用到生产，我们就Kafka、ActiveMQ、RabbitMQ、RocketMQ来进行不同维度对比。

特性ActiveMQRabbitMQRocketMQKafka

单机吞吐量	万级	万级	10 万级	10 万级
时效性	毫秒级	微秒级	毫秒级	毫秒级
可用性	高（主从）	高（主从）	非常高（分布式）	非常高（分布式）
消息重复	至少一次	至少一次	至少一次 最多一次	至少一次最多一次
消息顺序性	有序	有序	有序	分区有序
支持主题数	千级	百万级	千级	百级，多了性能严重下滑
消息回溯	不支持	不支持	支持（按时间回溯）	支持（按offset回溯）
管理界面	普通	普通	完善	普通

消息队列选型

选型的时候，我们需要根据业务场景，结合上述特性来进行选型。

比如你要支持天猫双十一类超大型的秒杀活动，这种一锤子买卖，那管理界面、消息回溯啥的不重要。

我们需要看什么？看吞吐量！

所以优先选Kafka和RocketMQ这种更高吞吐的。

比如做一个公司的中台，对外提供能力，那可能会有很多主题接入，这时候主题个数又是很重要的考量，像Kafka这样百级的，就不太符合要求，可以根据情况考虑千级的RocketMQ，甚至百万级的RabbitMQ。

又比如是一个金融类业务，那么重点考虑的就是稳定性、安全性，分布式部署的Kafka和Rocket就更有优势。

特别说一下时效性，RabbitMQ以微秒的时效作为招牌，但实际上毫秒和微秒，在绝大多数情况下，都没有感知的区别，加上网络带来的波动，这一点在生产过程中，反而不会作为重要的考量。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

topics/618658159)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！