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

20 | 分布式通信之发布订阅:送货上门

电商购物平台
ZooKeeper集群
消息中心
消费者
生产者
发布订阅模式
点对点模式
消息中心
消费者
生产者
思考题
观察者模式与发布订阅模式的区别
实践应用
Kafka发布订阅原理及工作机制
工作原理
基本原理
发布订阅模式

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

你好,我是聂鹏程。今天,我来继续带你打卡分布式核心技术。
在上一篇文章中,我带你一起学习了分布式通信中的远程调用。远程调用的核心是在网络服务层封装了通信协议、序列化、传输等操作,让用户调用远程服务如同进行本地调用一样。
其实,这种方式就是通过网络服务层的封装实现了不同机器上不同进程之间的直接通信,因为是直接通信,所以通过线程阻塞的方式实现同步调用比较容易,因此通常被用于同步调用。比如,机器 1 上的进程 A 调用机器 2 上的进程 B,进程 A 被挂起,进程 B 开始执行,当进程 B 将值返回给 A 时,A 继续执行。
虽然这种方式也可以用于异步通信,但因为进程之间是直接交互的,所以当进程比较多时,会导致进程维护通信的复杂度非常高,且一个进程通信接口改变,与其通信的进程都会受到影响。
随着业务和分布式计算规模的逐渐增大和复杂化,远程调用模型有点心有余力而不足了,为此出现了专门的异步通信模式,也就是消息发布订阅模式和消息队列模式。在接下来的两篇文章中,我将与你详细讲述这两种通信模式。
话不多说,今天,我就带你一起打卡分布式通信中的发布订阅模式吧。

什么是发布订阅?

其实,发布订阅的思想在我们的生活中随处可见。
比如,学术届电子论文的订阅方式。通常,各个会议方或出版社会将学术论文发布到论文网站(或平台上,比如 ACM、知网等),然后学生或老师向论文网站订阅自己感兴趣的论文,比如分布式相关的、AI 相关的等。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式通信技术中的发布订阅模式被比喻为“送货上门”,在分布式系统中非常常见。该模式通过消息中心将生产者产生的数据推送给订阅者,实现了一对多的消息传递。与点对点模式相比,发布订阅模式中一个消息可以被多个消费者进行消费,这也是和点对点模式的本质区别。在分布式系统中,通常会为多用户服务,而多个用户通常会关注相同类型的消息,因此发布订阅模式在分布式系统中非常常见。文章还结合了经典的分布式发布订阅消息系统Kafka的发布订阅原理及工作机制,帮助读者深入理解发布订阅模式的原理。 Kafka是一种典型的发布订阅消息系统,其系统架构包括生产者、消费者和消息中心三部分。生产者负责发布消息到消息中心,消费者向消息中心订阅自己感兴趣的消息,消息中心负责存储生产者发布的消息和管理消费者订阅信息,根据消费者订阅信息,将消息推送给消费者。Kafka的架构图展示了其集群结构,包括Producer、Broker、Consumer和ZooKeeper集群。ZooKeeper集群用来协调和管理Broker和Consumer,实现了Broker和Consumer的解耦,并为系统提供可靠性保证。 在Kafka中,为了解决消息存储的负载均衡和系统可靠性问题,引入了主题和分区的概念。主题是一个逻辑概念,指的是消息类型或数据类型,而分区则实现了负载均衡和消息备份。此外,Kafka中的消费组实现了多个消费者的集合,共同消费主题消息,避免了消费效率过低导致系统故障的问题。 发布订阅模式的关键特征包括实现了系统解耦、易于维护,以及实现了异步执行,避免高负载。与观察者模式相比,发布订阅模式采用了间接通信,引入了消息中心,实现了订阅者与发布者的解耦。观察者模式则采用了直接通信,通信时延会低一些,但依赖关系比较强。 总的来说,本文深入探讨了分布式发布订阅模式的原理和Kafka系统的工作机制,为读者提供了全面的技术视角和实践应用,帮助读者快速了解分布式通信技术中的发布订阅模式及其在实际系统中的应用。

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

全部留言(25)

  • 最新
  • 精选
  • Devin
    文章中 “实现消息的备份,从而保证系统的高可靠。比如,Topic 1 包含两个分区 Partiton-0、Partiton-1,每个分区内容一致实现消息的备份,从而保证系统的高可靠。比如,Topic 1 包含两个分区 Partiton-0、Partiton-1,每个分区内容一致”,这个说法应当是有误的,“实现消息的备份”应该是“副本机制”,假如Topic 1 分区数是 2 ,那么总消息是 Partiton-0 和 Partiton-1 的合集,不是文中说的“每个分区内容一致”

    作者回复: 这里介绍的是分区的功能或作用,不同分区存储不同数据子集,以及不同分区存储相同数据作为数据备份都可以看成是分区的作用

    2019-11-16
    4
    3
  • chen
    其实之所以能实现负载均衡,消费组也是个重要的因素,老师没有说啊

    作者回复: 这个问题非常好,确实消费组在一定程度上能实现负载均衡,本章留下的思考问题就是想大家在思考后在留言区能一起讨论起来。

    2020-05-08
    2
  • 88591
    增加消费者数量,可以提高处理速度

    作者回复: 一定程度上是可以的

    2020-04-03
    1
  • 阿星
    Kafka的partition和replica搞混了吧? 副本才是实现备份机制的吧,分区是实现了负载均衡和水平扩展
    2019-11-13
    9
    30
  • Eternal
    发布订阅的时候,如果是消费者主动拉去消息,是拉模式,如果是消息中心推送消息给消费者就是推模式。 推模式:消息中心需要考虑消费者的消费能力,不能把消费者压垮了,站着消息中心的角度,这个样消息中心能控制消费的速度,也能主动调控消息消费的积压,对消息中心是有利的,对消费者是有风险的; 拉模式:由消费者自己控制自己的消费速度,不用担心自己压力;站在消费者的角度,自己控制消费速度,有多到能力干多大事,自己的风险自己掌控,这样消息中心的消息积压就会存在风险,因为消息消费的速度自己不能控制,很容易造成消息积压,然后消息丢失,或消息中心不可用。 消息中心是两头都有风险,生产者的生产速度变化,消费者的消费速度变化都会造成消息积压风险,因为消息中心的消息存储能力,通信能力都是由限制的,消息中心是发布订阅模式中最复杂的一部分
    2019-11-09
    18
  • Eternal
    Kafka订阅的时候,客户端不需要考虑订阅哪个分区 当一个消费者组的消费者数量小于分区数量的时候是消费能力不足,该组中的一个消费者会超负载消费,存在挂掉风险 当一个消费者组的消费者数量大于分区数量的时候是分区的数量不足,该组中的一个消费者会存在空负载的情况,消费资源浪费 因此,一般一个消费者组的消费者数量和该组订阅的topic的分区数量一致,或者是成倍数。 成倍数是: 如果一个topic有3个分区,那么消费者组的消费者可以是,3个,6个,9个,这样一个组中的每个消费者就会均衡 如果一个消费者组的消费者数量是3个,那么他们订阅的topic的分区数量可以是是,3个,6个,9个,这样一个组中每个消费者消费的分区会均衡 如果一个消费者组中的消费者数量和组订阅的topic中的分区数量不成倍数,会存在问题: 当消费者挂掉,或者新的消费者加入组的时候,当分区数量新增或减少的时候,都会触发重平衡,即消费者和分区数量映射的重平衡 重平衡如果不均衡就会导致消费者负载过高,消费慢,也会造成topic消息积压,所有关键的问题说就是要使消费者和分区怎么均衡映射
    2019-11-09
    4
  • 阅过留痕 分布式系统三剑客:RPC、MQ、REDIS 上节是 是RPC这节是MQ,RPC核心是系统解藕,远程调度简易化,有返回值。MQ的核心也是解藕,而且更加的彻底,另外,就是削峰填谷。 关于RPC和MQ都需要一整个专栏来介绍,越来越感觉老师这里,有些科普的感受。不过比较集中和系统的介绍了一下,这方面的内容也挺好,定位问题吧! 为了加深理解,来个比喻: 点对点——类似一个母鸡在鸡窝里下了一个蛋,不论家里的谁,拿走了,就是拿走了就没有了 发布订阅——类似农村电线杆子上贴的一个广告,整村的人都可以看,都看到了,他的效果也就没有了 有关MQ的高频问题有如下几个: 消息少发?多发?怎么处理?顺序消息怎么实现?大量消息积压,且需要及时消费,怎么处理?
    2020-02-18
    2
  • Jackey
    Kafka的消费者组有点像思考题提到的订阅者负载均衡,不过应该是分区数大于消费者数才会进行多个消费者消费吧。所以是否可以考虑订阅时不仅仅是指定主题,而是需要指定到具体的分区?
    2019-11-06
    2
  • 趁早
    真的是太多的介绍性内容了,感觉干活真的好少哈
    2021-09-04
    1
  • 修愿三秋
    Broker的数据存储是否溢出和Consumer 消费数据的能力没有什么关系的,俩组件是独立的,互不影响
    2019-11-20
    2
    1
收起评论
显示
设置
留言
25
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部