分布式技术原理与算法解析
聂鹏程
智载云帆CTO,前华为分布式Lab资深技术专家
立即订阅
5969 人已学习
课程目录
已更新 36 讲 / 共 34 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 四纵四横,带你透彻理解分布式技术
免费
01 | 分布式缘何而起:从单兵,到游击队,到集团军
02 | 分布式系统的指标:啥是分布式的三围
第一站:分布式协调与同步 (6讲)
03 | 分布式互斥:有你没我,有我没你
04 | 分布式选举:国不可一日无君
05 | 分布式共识:存异求同
06 | 分布式事务:All or nothing
07 | 分布式锁:关键重地,非请勿入
08 | 分布式技术是如何引爆人工智能的?
第二站:分布式资源管理与负载调度 (6讲)
09 | 分布式体系结构之集中式结构:一人在上,万人在下
10 | 分布式体系结构之非集中式结构:众生平等
11 | 分布式调度架构之单体调度:物质文明、精神文明一手抓
12 | 分布式调度架构之两层调度:物质文明、精神文明两手抓
13 | 分布式调度架构之共享状态调度:物质文明、精神文明多手协商抓
14 | 答疑篇:分布式事务与分布式锁相关问题
第三站:分布式计算技术 (4讲)
15 | 分布式计算模式之MR:一门同流合污的艺术
16 | 分布式计算模式之Stream:一门背锅的艺术
17 | 分布式计算模式之Actor:一门甩锅的艺术
18 | 分布式计算模式之流水线:你方唱罢我登场
第四站:分布式通信技术 (4讲)
19 | 分布式通信之远程调用:我是你的千里眼
20 | 分布式通信之发布订阅:送货上门
21 | 分布式通信之消息队列:货物自取
22 | 答疑篇:分布式体系架构与分布式计算相关问题
第五站:分布式数据存储 (5讲)
23 | CAP理论:这顶帽子我不想要
24 | 分布式数据存储系统之三要素:顾客、导购与货架
25 | 数据分布方式之哈希与一致性哈希:“掐指一算”与“掐指两算”的事
26 | 分布式数据复制技术:分身有术
27 | 分布式数据之缓存技术:“身手钥钱”随身带
特别放送 (3讲)
特别放送 | 分布式下的一致性杂谈
特别放送 | 徐志强:学习这件事儿,不到长城非好汉
特别放送 | 那些你不能错过的分布式系统论文
第六站:分布式高可靠 (5讲)
28 | 分布式高可靠之负载均衡:不患寡,而患不均
29 | 分布式高可靠之流量控制:大禹治水,在疏不在堵
30 | 分布式高可用之故障隔离:当断不断,反受其乱
31 | 分布式高可用之故障恢复:知错能改,善莫大焉
32 | 答疑篇:如何判断并解决网络分区问题?
分布式技术原理与算法解析
登录|注册

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

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

什么是消息队列?

回想一下,在上一篇学术电子论文订阅的例子中,出版社或会议方将论文发布到论文网站(或平台)上,然后论文网站再将论文推送给订阅相关论文的老师或学生。这里的论文网站就是消息中心,负责根据订阅信息将论文送货上门,角色非常关键。
但其实,除了将论文送货上门外,我们还能想到另外一种模式,也就是出版社或会议方将论文发布到论文网站进行存储,老师或学生根据需要到论文网站按需购买文章。
这种思想,在分布式通信领域中称为消息队列模式,论文网站充当的就是消息队列的角色,也非常关键。接下来,我再通过一个具体的应用案例来帮助你更加深入地理解什么是消息队列吧
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式技术原理与算法解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • 忆水寒
    这个问题其实问的是幂等性问题,在目前流行的几种MQ中都可能存在。比如Kafka,在kafka实际上有个offset的概念,就是每个消息写进去,都有一个offset,代表他的序号,然后consumer消费了数据之后,每隔一段时间,会把自己消费过的消息的offset提交一下,代表我已经消费过了,下次我要是重启啥的,你就让我继续从上次消费到的offset来继续消费吧。但是凡事总有意外,比如我们之前生产经常遇到的,就是你有时候重启系统,看你怎么重启了,有时候直接kill进程再重启。这会导致consumer有些消息处理了,但是没来得及提交offset,尴尬了。重启之后,少数消息会再次消费一次。其实重复消费不可怕,可怕的是你没考虑到重复消费之后,怎么保证幂等性。
    2019-11-11
    1
    8
  • 信xin_n
    好像有点明白了,发布订阅模式是 push 模式,消息队列是 pull 模式。
    2019-11-12
    3
  • 随心而至
    分布式数据存储,好像都是利用某种hash算法将数据存在不同的机器上。Kafka: hash(消息的键)来确定分区;Redis:hash(key)来确定slot;ES:hash(docId)来确定shard。
    2019-11-11
    2
  • 观弈道人
    感觉这个有点问题吧,不管是订阅还是队列模式,都是broker“送货上门”给消费端的,希望聂老师能再解释下,谢谢!
    2019-11-22
    1
  • 阿卡牛
    我理解的消息队列模型,同一份消息只能被消费一次吧?
    2019-11-11
    2
    1
  • 小明
    听下来感觉一个是push一个是pull,可是我用消息队列也是push啊,学完有点晕了
    2019-12-12
  • 一毛钱
    kafka的offset就是解决多消费者的问题的
    2019-11-30
  • 易儿易
    思考题:不是可以使用线程安全的队列吗?数据结构里是支持的,产品型的消息队列中间件不支持吗?
    2019-11-29
  • kylexy_0817
    在消费端作幂等处理,如在缓存上记录消息是否有被消费过,或在数据库的层面加上唯一索引约束数据只能被插入一次
    2019-11-28
  • 青莲
    每个消费者都有维护一个自己消费消息的偏移量,可以存储在本地,或类似zookeepr的协同服务上,每次重启都去协同服务上拉取上一次消费的偏移量,从上一次记录开始消息;当然这种情况,由于各种异常原因还是有可能消息至少被消费一次,如常见的消息重放等,所以需要在业务方消费时进行业务上的幂等处理
    2019-11-23
  • 行下一首歌
    可以在也许层面做防止重复消费的逻辑
    2019-11-11
  • tracy
    1.消息端实现幂等性,比如支付消息,以订单号为唯一标识,消息时候可以根据状态判断是否处理过,数据库加上唯一索引
    2.消费时候可以再内存中加set去重
    3.应该需要根据不同的业务分析处理
    2019-11-11
  • Jackey
    这里想到可以考虑从consumer端控制,consumer消费消息时,broker可以返回一个偏移量,由consumer记录这个偏移量。下次消费时直接从偏移位置处开始消费。
    或者由broker来记录消费者和对应偏移量,消费者要重复消费时直接不返回数据。但broker之间的数据同步应该会使系统更加复杂
    2019-11-11
  • 啦啦啦
    打卡
    2019-11-11
收起评论
14
返回
顶部