先叠个甲这篇文主打一个主观锐评虽然参考了吞吐量、高可用这些硬指标但更多的是聊聊后端老兵在实际生产环境里的“血泪史”。消息队列MQ这东西面试的时候全在造火箭削峰填谷、异步解耦、最终一致性真到了线上往往是谁吞了我的消息消息怎么又重复了卧槽队列怎么又堆积了简单说“夯”就是稳如老狗半夜不用起夜“拉”就是坑有点多运维起来像伺候大爷。当然了没有最废的MQ只有最不合适的业务场景求生欲再次拉满。咋评的不整那些跑分对比了主要看这几点稳不稳丢不丢消息高并发打过来会不会宕机快不快吞吐量到底行不行堆积几百万条消息后性能会不会断崖式下跌爽不爽高级特性延迟消息、顺序消息、死信队列是不是开箱即用坑不坑运维成本高不高报错信息像不像天书 夯顶流硬通货RocketMQ一句话评价阿里双十一抗压王金融级业务的“标准答案”。为什么夯如果你在做电商、支付、订单系统或者团队在纠结选啥闭眼选 RocketMQ。它是真刀真枪在极端并发下验证过的设计上极其偏向业务。强在哪原生支持延迟消息不用自己搞定时任务或者死信队列绕弯子、事务消息、顺序消息。而且用 Java 写的国内大厂后端改起源码来毫无压力。消息堆积能力极强堆个几亿条也不怎么影响读写性能。适合谁对消息可靠性要求极高、业务逻辑复杂的企业级应用尤其是电商和金融领域。 顶级吞吐巨兽数据之王Kafka一句话评价吞吐量天花板大数据的唯一真神。咋样如果说 RocketMQ 是个精细的账房先生Kafka 就是个狂暴的泥头车。它的吞吐量极其恐怖动辄百万级 TPS日志收集、流处理、数据同步领域它是绝对的统治者。注意点Kafka 追求的是极致的吞吐和速度所以牺牲了一部分业务灵活性比如不支持灵活的延迟消息Tag 过滤也比较弱。而且早年重度依赖 ZooKeeper现在慢慢剥离了 KRAFT运维门槛不低一旦集群出问题恢复起来让人头皮发麻。适合谁海量日志处理、用户行为轨迹埋点、大数据流计算。 小清新极简主义Go圈特供NSQ一句话评价我就想简单发个消息别给我整那些复杂的集群。咋样纯 Go 编写没有任何外部依赖不需要 ZooKeeper、Raft 啥的部署极其简单下载个二进制文件一跑就完事了。去中心化架构天生高可用。坑点它默认是内存存储可以配落盘而且不保证消息的强顺序性甚至在极端情况下可能会重复投递或者丢消息依赖客户端重试机制。适合谁Go 技术栈团队追求极简运维业务对消息丢失和乱序有一定容忍度或者做内部系统异步通知的。 NPC功能齐全但老态龙钟RabbitMQ一句话评价曾经的万金油现在的高并发软肋。咋样这货是基于 Erlang 写的AMQP协议路由机制Exchange极其灵活强大功能非常全面早年间中小公司几乎人手一个。后台管理界面做得也是最漂亮的。现状一旦并发量上去或者消息开始大量堆积RabbitMQ 的性能会断崖式下跌。而且 Erlang 这个语言太小众了国内能看懂源码甚至做二次开发的团队屈指可数出了底层 Bug 只能干瞪眼。适合谁并发量不大、对路由规则要求极高的传统企业级业务。新一代的高并发互联网项目很少首选了。 拉完了别闹了/时代的眼泪Redis Pub/Sub (或 List)一句话评价你是个缓存别来抢 MQ 的饭碗好吗咋拉很多人图省事直接拿 Redis 的 Pub/Sub 当消息队列用。但凡网络抖一下或者消费者下线一秒钟消息就永远消失了连个渣都不剩。用 List 做队列稍微好点但没有 ack 机制没有高级特性。虽然 Redis 后来出了 Stream但用它做正经 MQ 的人依然寥寥无几毕竟怕撑爆宝贵的内存。ActiveMQ真·时代的眼泪顺便鞭尸一下 ActiveMQ十年前的王者现在连 Apache 官方都懒得大力更新了吞吐量低、偶发丢消息。快跑。总结一下分层消息队列建议夯RocketMQ电商/金融闭眼选业务特性拉满稳。顶级Kafka大数据、日志处理、超高并发选它。小清新NSQGo圈极简选它部署一秒钟没有运维包袱。NPCRabbitMQ功能全、路由强但高并发容易拉胯老项目维持现状。拉完了Redis / ActiveMQ别拿缓存当正经 MQ 考验人性老古董快淘汰。END写在最后最近私信问我面试题的小伙伴实在太多了一个个回有点回不过来。我花了两个周末把星球里大家公认最容易挂的Go/Java/AI 面试坑点整理成了一份PDF 文档。里面不光有题还有解题思路和避坑指南。想要的同学直接关注并私信我【面试】我统一发给大家。wangzhongyang.com 也欢迎大家直接访问我的官网里面有Go / Java / AI 的资料免费学习
从夯到拉，锐评5大主流消息队列
先叠个甲这篇文主打一个主观锐评虽然参考了吞吐量、高可用这些硬指标但更多的是聊聊后端老兵在实际生产环境里的“血泪史”。消息队列MQ这东西面试的时候全在造火箭削峰填谷、异步解耦、最终一致性真到了线上往往是谁吞了我的消息消息怎么又重复了卧槽队列怎么又堆积了简单说“夯”就是稳如老狗半夜不用起夜“拉”就是坑有点多运维起来像伺候大爷。当然了没有最废的MQ只有最不合适的业务场景求生欲再次拉满。咋评的不整那些跑分对比了主要看这几点稳不稳丢不丢消息高并发打过来会不会宕机快不快吞吐量到底行不行堆积几百万条消息后性能会不会断崖式下跌爽不爽高级特性延迟消息、顺序消息、死信队列是不是开箱即用坑不坑运维成本高不高报错信息像不像天书 夯顶流硬通货RocketMQ一句话评价阿里双十一抗压王金融级业务的“标准答案”。为什么夯如果你在做电商、支付、订单系统或者团队在纠结选啥闭眼选 RocketMQ。它是真刀真枪在极端并发下验证过的设计上极其偏向业务。强在哪原生支持延迟消息不用自己搞定时任务或者死信队列绕弯子、事务消息、顺序消息。而且用 Java 写的国内大厂后端改起源码来毫无压力。消息堆积能力极强堆个几亿条也不怎么影响读写性能。适合谁对消息可靠性要求极高、业务逻辑复杂的企业级应用尤其是电商和金融领域。 顶级吞吐巨兽数据之王Kafka一句话评价吞吐量天花板大数据的唯一真神。咋样如果说 RocketMQ 是个精细的账房先生Kafka 就是个狂暴的泥头车。它的吞吐量极其恐怖动辄百万级 TPS日志收集、流处理、数据同步领域它是绝对的统治者。注意点Kafka 追求的是极致的吞吐和速度所以牺牲了一部分业务灵活性比如不支持灵活的延迟消息Tag 过滤也比较弱。而且早年重度依赖 ZooKeeper现在慢慢剥离了 KRAFT运维门槛不低一旦集群出问题恢复起来让人头皮发麻。适合谁海量日志处理、用户行为轨迹埋点、大数据流计算。 小清新极简主义Go圈特供NSQ一句话评价我就想简单发个消息别给我整那些复杂的集群。咋样纯 Go 编写没有任何外部依赖不需要 ZooKeeper、Raft 啥的部署极其简单下载个二进制文件一跑就完事了。去中心化架构天生高可用。坑点它默认是内存存储可以配落盘而且不保证消息的强顺序性甚至在极端情况下可能会重复投递或者丢消息依赖客户端重试机制。适合谁Go 技术栈团队追求极简运维业务对消息丢失和乱序有一定容忍度或者做内部系统异步通知的。 NPC功能齐全但老态龙钟RabbitMQ一句话评价曾经的万金油现在的高并发软肋。咋样这货是基于 Erlang 写的AMQP协议路由机制Exchange极其灵活强大功能非常全面早年间中小公司几乎人手一个。后台管理界面做得也是最漂亮的。现状一旦并发量上去或者消息开始大量堆积RabbitMQ 的性能会断崖式下跌。而且 Erlang 这个语言太小众了国内能看懂源码甚至做二次开发的团队屈指可数出了底层 Bug 只能干瞪眼。适合谁并发量不大、对路由规则要求极高的传统企业级业务。新一代的高并发互联网项目很少首选了。 拉完了别闹了/时代的眼泪Redis Pub/Sub (或 List)一句话评价你是个缓存别来抢 MQ 的饭碗好吗咋拉很多人图省事直接拿 Redis 的 Pub/Sub 当消息队列用。但凡网络抖一下或者消费者下线一秒钟消息就永远消失了连个渣都不剩。用 List 做队列稍微好点但没有 ack 机制没有高级特性。虽然 Redis 后来出了 Stream但用它做正经 MQ 的人依然寥寥无几毕竟怕撑爆宝贵的内存。ActiveMQ真·时代的眼泪顺便鞭尸一下 ActiveMQ十年前的王者现在连 Apache 官方都懒得大力更新了吞吐量低、偶发丢消息。快跑。总结一下分层消息队列建议夯RocketMQ电商/金融闭眼选业务特性拉满稳。顶级Kafka大数据、日志处理、超高并发选它。小清新NSQGo圈极简选它部署一秒钟没有运维包袱。NPCRabbitMQ功能全、路由强但高并发容易拉胯老项目维持现状。拉完了Redis / ActiveMQ别拿缓存当正经 MQ 考验人性老古董快淘汰。END写在最后最近私信问我面试题的小伙伴实在太多了一个个回有点回不过来。我花了两个周末把星球里大家公认最容易挂的Go/Java/AI 面试坑点整理成了一份PDF 文档。里面不光有题还有解题思路和避坑指南。想要的同学直接关注并私信我【面试】我统一发给大家。wangzhongyang.com 也欢迎大家直接访问我的官网里面有Go / Java / AI 的资料免费学习
