消息队列高手课
李玥
美团高级技术专家
52199 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
进阶篇 (21讲)
消息队列高手课
15
15
1.0x
00:00/00:00
登录|注册

02 | 该如何选择消息队列?

不适合在线业务场景
异步批量设计
高性能
与周边生态系统兼容性高
国际流行度较低
响应时延优化
活跃的中文社区
性能、稳定性和可靠性
使用Erlang语言
性能较差
对消息堆积支持不佳
多语言客户端支持
灵活的路由配置
支持AMQP协议
轻量级
适用于处理海量消息
适用于在线业务场景
适用于一般场景
存储和计算分离设计
多线程网络库
老牌但功能、性能落后
问题
特点
问题
特点
问题
特点
当前选择的消息队列产品是否最佳
系统对消息队列的需求
Kafka
RocketMQ
RabbitMQ
Pulsar
ZeroMQ
ActiveMQ
Kafka
RocketMQ
RabbitMQ
思考题
选择建议
第二梯队的消息队列
常见消息队列
消息队列产品选择

该思维导图由 AI 生成,仅供参考

你好,我是李玥。这节课我们来聊一下几个比较常见的开源的消息队列中间件。如果你正在做消息队列技术选型,不知道该选择哪款消息队列,你一定要先听一下这节课的内容。
作为一个程序员,相信你一定听过“没有银弹”这个说法,这里面的银弹是指能轻松杀死狼人、用白银做的子弹,什么意思呢?我对这句话的理解是说,在软件工程中,不存在像“银弹”这样可以解决一切问题的设计、架构或软件,每一个软件系统,它都是独一无二的,你不可能用一套方法去解决所有的问题。
在消息队列的技术选型这个问题上,也是同样的道理。并不存在说,哪个消息队列就是“最好的”。常用的这几个消息队列,每一个产品都有自己的优势和劣势,你需要根据现有系统的情况,选择最适合你的那款产品。

选择消息队列产品的基本标准

虽然这些消息队列产品在功能和特性方面各有优劣,但我们在选择的时候要有一个最低标准,保证入选的产品至少是及格的。
接下来我们先说一下这及格的标准是什么样的。
首先,必须是开源的产品,这个非常重要。开源意味着,如果有一天你使用的消息队列遇到了一个影响你系统业务的 Bug,你至少还有机会通过修改源代码来迅速修复或规避这个 Bug,解决你的系统火烧眉毛的问题,而不是束手无策地等待开发者不一定什么时候发布的下一个版本来解决。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

选择消息队列产品时,需要综合考虑开源性、流行度、性能、可靠性和适用场景。常见的开源消息队列产品包括RabbitMQ、RocketMQ和Kafka,它们各有优势和劣势。RabbitMQ适合开箱即用易于维护的场景,RocketMQ适用于处理在线业务,而Kafka则适合处理海量消息和大数据场景。除了这些产品,还有一些第二梯队的消息队列产品,如ActiveMQ、ZeroMQ和Pulsar,它们也具有各自的特点。综上所述,选择消息队列产品需要根据具体需求来进行综合考量,以找到最适合自身需求的产品。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《消息队列高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(155)

  • 最新
  • 精选
  • WL
    请问一下老师rocketMQ是怎么做到低延时的?

    作者回复: 主要是设计上的选择问题,Kafka中到处都是“批量和异步”设计,它更关注的是整体的吞吐量,而RocketMQ的设计选择更多的是尽量及时处理请求。 比如发消息,同样是用户调用了send()方法,RockMQ它会直接把这个消息发出去,而Kafka会把这个消息放到本地缓存里面,然后择机异步批量发送。 所以,RocketMQ它的时延更小一些,而Kafka的吞吐量更高。

    2019-07-25
    7
    111
  • leslie
    一套架构中是否可能存在多套中间件?在线的生产业务使用rockmq,运维/监控方面使用kafka。

    作者回复: 当然可以,架构无所谓好坏,关键是适合。用多套MQ好处是发挥各自的长处,代价是维护成本比较高。具体是不是适合,还是要架构师根据各种实际情况来权衡。

    2019-07-25
    6
    42
  • Goal
    听得我激动的喊了一句:“湖人总冠军”

    作者回复: 你咋知道我是詹密呢?

    2019-07-30
    9
    31
  • 猿人谷
    我所在公司用rabbitmq也遇到消息的有序性无法保证的问题,通过在业务层面去弥补,终究不是种好方案。 请问老师在保证有序性消费上有什么好的方案?

    作者回复: 正确的使用RabbitMQ是可以保证严格有序的,你在学习完“03 消息模型:主题和队列有什么区别?”之后,再看一下RabbitMQ的配置应该就会知道该如何解决你的问题了。

    2019-07-25
    2
    24
  • 吴青
    老师 exchange是rabbitmq独有的么?exchange好像属于amqp协议,看了看amqp似乎说到了。

    作者回复: exchange确实是AMQP协议中定义的,RabbitMQ是AMQP的一个实现。

    2019-07-28
    18
  • wmg
    “因为当客户端发送一条消息的时候,Kafka 并不会立即发送出去,而是要等一会儿攒一批再发送,在它的 Broker 中,很多地方都会使用这种“先攒一波再一起处理”的设计。当你的业务场景中,每秒钟消息数量没有那么多的时候,Kafka 的时延反而会比较高。所以,Kafka 不太适合在线业务场景。”,老师,批次的大小是可配置的,在我们的使用场景中,如果消息没有积压的情况下,延迟基本上小于10ms,我想问一下rocketmq的延迟一般是多少?

    作者回复: 配置得当的情况下,可以做到2-3ms。

    2019-07-26
    2
    18
  • Geek_d6623f
    想问下老师,关于MQ丢消息是怎么看的。我在用MQ的时候一直没有办法放心,如果在每个发MQ的场景都加一个补偿任务来保证最终一致性,又觉得MQ本身解耦的特性就浪费了。 消息丢失主要有这么几个场景: 1.客户端在发MQ消息的时候,网络抖动timeout导致没有发出去。 2.客户端发MQ消息成功后,MQ本身有可能会丢消息。(虽然我看RocketMQ官方说不会丢,有持久化) 3.业务处理完后,准备发MQ消息的时候,系统崩溃或者重启,导致消息没有发出去。

    作者回复: 2 这种情况你不用担心,无论从理论上,还是很多生产系统的实际验证,都不会丢消息的。 1、3 二种情况是一样的,就是没发消息或者发失败了,这种情况其实和你把数据往数据库里写失败了是类似的,具体怎么处理还是得看业务。 比如说,重要的业务可以用一主一备二个主题。

    2020-03-06
    14
  • angel😇txy🤓
    老师好,rocket mq为何号称金融级的稳定性呢

    作者回复: 金融级只是一种说法,并没有什么标准。但确实有很多涉及金融类的系统选择使用RocketMQ。

    2019-08-20
    12
  • yan
    kafka如果凑不够一批,那等什么时候发送?

    作者回复: 建议看一下batch.size和linger.ms这两个参数的含义

    2019-09-25
    11
  • 👻 小二
    老师, 能稍微讲下emq跟nsq 的优缺点跟性能吗?

    作者回复: emq是专注于MQTT场景的一个消息队列,如果你的使用场景是连接海量的IoT设备,可以考虑。 nsq使用Go语言开发,如果团队的技术栈是基于Go语言搭建的,nsq是一个很好的选择。 这两个消息队列我都没有深入的使用和测试过,所以没办法跟你分享它们的优缺点和性能。

    2019-08-17
    4
    11
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部