分布式技术原理与算法解析
聂鹏程
智载云帆 CTO,前华为分布式 Lab 资深技术专家
39663 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 43 讲
分布式技术原理与算法解析
15
15
1.0x
00:00/00:00
登录|注册

21 | 分布式通信之消息队列:货物自取

思考题
总结
知识扩展:发布订阅和消息队列模式
消息队列的原理
什么是消息队列?
分布式通信之消息队列

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

你好,我是聂鹏程。今天,我来继续带你打卡分布式核心技术。
在上一篇文章,我带你学习了分布式通信技术中的发布订阅。总结来说,发布订阅就是发布者产生数据到消息中心,订阅者订阅自己感兴趣的消息,消息中心根据订阅者的订阅情况,将相关消息或数据发送给对应的订阅者。所以,我将其思想,概括为“送货上门”。
在实际使用场景中,还有一种常用的通信方式,就是将消息或数据放到一个队列里,谁需要谁就去队列里面取。在分布式领域中,这种模式叫“消息队列”。与发布订阅相比,消息队列技术的核心思想可以概括为“货物自取”。
接下来,我们就一起打卡分布式通信技术中的消息队列吧。

什么是消息队列?

回想一下,在上一篇学术电子论文订阅的例子中,出版社或会议方将论文发布到论文网站(或平台)上,然后论文网站再将论文推送给订阅相关论文的老师或学生。这里的论文网站就是消息中心,负责根据订阅信息将论文送货上门,角色非常关键。
但其实,除了将论文送货上门外,我们还能想到另外一种模式,也就是出版社或会议方将论文发布到论文网站进行存储,老师或学生根据需要到论文网站按需购买文章。
这种思想,在分布式通信领域中称为消息队列模式,论文网站充当的就是消息队列的角色,也非常关键。接下来,我再通过一个具体的应用案例来帮助你更加深入地理解什么是消息队列吧
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

RocketMQ是一种常用的消息队列系统,其架构包括NameServer Cluster、Producer Cluster、Broker Cluster和Consumer Cluster。NameServer Cluster负责管理Broker的信息,Producer Cluster接收用户数据并发布到Broker Cluster,Consumer Cluster从Broker中获取消息进行消费。Broker Cluster存储数据并实现主从设计,以提高系统可靠性。RocketMQ的工作流程包括启动NameServer和Broker、创建主题、消息的生产和消费。消息队列模式适用于消费者为临时用户的场景,如购物交易、充值、消息推送等。与发布订阅模式相比,消息队列模式采用队列结构进行存储,实现了生产者和消费者的解耦。消息队列模式适合消费者为临时用户的场景,而发布订阅模式适合消费者为长驻进程或服务的场景。通过RocketMQ的介绍,读者可以深入了解消息队列模式的工作原理和应用场景。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式技术原理与算法解析》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(21)

  • 最新
  • 精选
  • piboye
    订阅模式的核心是一个消息可以被多个人消费,消息队列是一个消息一个人消费。

    作者回复: 订阅模式除了一个消息可以被多个人消费,还有两点与消息队列不一样的地方,1)消费者需要提前订阅自己关注的消息;2)订阅发布中心根据订阅者订阅信息推送消息,在消息队列中是消费者主动获取消息。

    2020-05-06
    2
    2
  • 88591
    记录消费消息的对应关系。可以在客户端记录,也可以在服务端记录。,服务端记录更可靠,但是通信成本高。增加了服务器的开销。客户端记录简单,但是容易丢失。

    作者回复: 根据不同场景,对数据可靠性的要求不一样,选择在客户端还是服务端

    2020-04-03
    1
  • 忆水寒
    这个问题其实问的是幂等性问题,在目前流行的几种MQ中都可能存在。比如Kafka,在kafka实际上有个offset的概念,就是每个消息写进去,都有一个offset,代表他的序号,然后consumer消费了数据之后,每隔一段时间,会把自己消费过的消息的offset提交一下,代表我已经消费过了,下次我要是重启啥的,你就让我继续从上次消费到的offset来继续消费吧。但是凡事总有意外,比如我们之前生产经常遇到的,就是你有时候重启系统,看你怎么重启了,有时候直接kill进程再重启。这会导致consumer有些消息处理了,但是没来得及提交offset,尴尬了。重启之后,少数消息会再次消费一次。其实重复消费不可怕,可怕的是你没考虑到重复消费之后,怎么保证幂等性。
    2019-11-11
    3
    33
  • 信xin_n
    好像有点明白了,发布订阅模式是 push 模式,消息队列是 pull 模式。
    2019-11-12
    2
    12
  • 随心而至
    分布式数据存储,好像都是利用某种hash算法将数据存在不同的机器上。Kafka: hash(消息的键)来确定分区;Redis:hash(key)来确定slot;ES:hash(docId)来确定shard。
    2019-11-11
    8
  • 观弈道人
    感觉这个有点问题吧,不管是订阅还是队列模式,都是broker“送货上门”给消费端的,希望聂老师能再解释下,谢谢!
    2019-11-22
    6
  • 阿卡牛
    我理解的消息队列模型,同一份消息只能被消费一次吧?
    2019-11-11
    2
    3
  • 小李飞菜刀
    感觉上一课的发布订阅模式,举了Kafka的例子不好,因为Kafka是拉的模式,是消费者主动消费数据,不是被推送过来的。 kafka的生产者只负责生产数据,不管有没有消费者; kafka的消费者可以从头、上次消费点、最新的方式消费数据;
    2020-11-20
    2
  • 青莲
    每个消费者都有维护一个自己消费消息的偏移量,可以存储在本地,或类似zookeepr的协同服务上,每次重启都去协同服务上拉取上一次消费的偏移量,从上一次记录开始消息;当然这种情况,由于各种异常原因还是有可能消息至少被消费一次,如常见的消息重放等,所以需要在业务方消费时进行业务上的幂等处理
    2019-11-23
    2
  • 趁早
    规定一个queue or patition 在同一个消费组只能有一个消费者去消费
    2021-09-04
收起评论
显示
设置
留言
21
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部