分布式技术原理与算法解析
聂鹏程
智载云帆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 | 答疑篇:如何判断并解决网络分区问题?
分布式技术原理与算法解析
登录|注册

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

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

什么是发布订阅?

其实,发布订阅的思想在我们的生活中随处可见。
比如,学术届电子论文的订阅方式。通常,各个会议方或出版社会将学术论文发布到论文网站(或平台上,比如 ACM、知网等),然后学生或老师向论文网站订阅自己感兴趣的论文,比如分布式相关的、AI 相关的等。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式技术原理与算法解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

  • 阿星
    Kafka的partition和replica搞混了吧? 副本才是实现备份机制的吧,分区是实现了负载均衡和水平扩展
    2019-11-13
    1
    5
  • Eternal
    发布订阅的时候,如果是消费者主动拉去消息,是拉模式,如果是消息中心推送消息给消费者就是推模式。

    推模式:消息中心需要考虑消费者的消费能力,不能把消费者压垮了,站着消息中心的角度,这个样消息中心能控制消费的速度,也能主动调控消息消费的积压,对消息中心是有利的,对消费者是有风险的;

    拉模式:由消费者自己控制自己的消费速度,不用担心自己压力;站在消费者的角度,自己控制消费速度,有多到能力干多大事,自己的风险自己掌控,这样消息中心的消息积压就会存在风险,因为消息消费的速度自己不能控制,很容易造成消息积压,然后消息丢失,或消息中心不可用。

    消息中心是两头都有风险,生产者的生产速度变化,消费者的消费速度变化都会造成消息积压风险,因为消息中心的消息存储能力,通信能力都是由限制的,消息中心是发布订阅模式中最复杂的一部分

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

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

    2019-11-16
    1
    2
  • 修愿三秋
    Broker的数据存储是否溢出和Consumer 消费数据的能力没有什么关系的,俩组件是独立的,互不影响
    2019-11-20
    1
    1
  • Jackey
    Kafka的消费者组有点像思考题提到的订阅者负载均衡,不过应该是分区数大于消费者数才会进行多个消费者消费吧。所以是否可以考虑订阅时不仅仅是指定主题,而是需要指定到具体的分区?
    2019-11-06
    1
  • 易儿易
    Topic模式消息中心存储的消息何时被销毁呢?是消费量=(通过zk确定保持连接的)订阅者数量后自动销毁吗?如果订阅者出现问题消息中心也会超期自动销毁吧?
    2019-11-29
  • 没有昵称
    思考题: 负载均衡 不能解决消息堆积的问题 多个节点部署相同的代码 都在一个消费者组下 只会有一个节点消费到消息
    解决方法: 创建多个消费者组 通过消费方的业务代码 来控制
    2019-11-23
  • _______Harvey凝枫😗
    消费组与Broker存储溢出的关系是什么?

    一个消费组中的消费者共同消费主题消息,每个消息只由组内的某个消费者消费;
    那么单个消费者消费能力有限时,难道强制推送给组内的其它消费者?这样不合理吧;
    如果说时不强制推送给组内的其它消费者,那么这个和Broke溢出有什么关系?
    2019-11-20
  • 光业
    思考题,使用消费者组,分布在不同的节点上
    2019-11-10
  • Eternal
    Kafka订阅的时候,客户端不需要考虑订阅哪个分区
    当一个消费者组的消费者数量小于分区数量的时候是消费能力不足,该组中的一个消费者会超负载消费,存在挂掉风险
    当一个消费者组的消费者数量大于分区数量的时候是分区的数量不足,该组中的一个消费者会存在空负载的情况,消费资源浪费

    因此,一般一个消费者组的消费者数量和该组订阅的topic的分区数量一致,或者是成倍数。

    成倍数是:
    如果一个topic有3个分区,那么消费者组的消费者可以是,3个,6个,9个,这样一个组中的每个消费者就会均衡
    如果一个消费者组的消费者数量是3个,那么他们订阅的topic的分区数量可以是是,3个,6个,9个,这样一个组中每个消费者消费的分区会均衡

    如果一个消费者组中的消费者数量和组订阅的topic中的分区数量不成倍数,会存在问题:
    当消费者挂掉,或者新的消费者加入组的时候,当分区数量新增或减少的时候,都会触发重平衡,即消费者和分区数量映射的重平衡
    重平衡如果不均衡就会导致消费者负载过高,消费慢,也会造成topic消息积压,所有关键的问题说就是要使消费者和分区怎么均衡映射
    2019-11-09
  • 信xin_n
    实现消息的备份,从而保证系统的高可靠。比如,Topic 1 包含两个分区 Partiton-0、Partiton-1,每个分区内容一致,分别存储在 Broker 0 和 Broker 1 上,借此实现了数据备份。
    这个地方图片画错了,两个都是 Partiton-0。老师,请问下,分区是用来负载均衡还是备份,是在配置文件配置具体模式吗?
    2019-11-09
  • 开心小毛
    每个消费者组才是一份订阅:每个消息会被发放到每一个消费组,每个消费组被不同的应用程序消费互不影响。
    负载均衡是通过在一个主题下创建多个分区实现的,生产者在同一主题下只能选择一个分区投放消息。
    消息备份是通过分区下的replica实现的,所有replica servers都与领导者处于同一数据中心且不分担读写,只起到消息备份的作用。
    2019-11-07
  • Geek_e986e3
    我的理解是。同一个消费组增加消费者是不是可以认为是消费者的负载均衡
    2019-11-06
  • 随心而至
    用过Kafka,可以在同一个消费者组下设置多个消费者来解决这个问题。当然这里面会涉及到多个消费者协同的问题,我记得Kafka有个协调器(coordinator)来做这个。
    2019-11-06
  • xingoo
    消费者负载均衡可以通过消息的多分区实现,比如一个主题有多个分区,那么可以通过创建多个消费者进行并行消费
    2019-11-06
  • leslie
    不知道为何老师选择kafka:Coding的易读性和易操作以及排错性考虑还是?Kafka其特性是收之后打包,解包是在Cilent端。
         老师今天的问题"单个订阅者的处理能力是有限的,那么能否实现订阅者负载均衡消费呢?又该如何实现呢?"其实老师今天的问题最合适的MQ应当是rocketMQ:阿里共享给开源社区的这款产品,Kafka在高并发的性能上其实还是相对偏弱。
          可能不同的MQ在分布式环节中适用的场景应当是不同的,这就像DB这块-RMDB和NOSQL DB承担的是软件过程中不同的场景而已;kafka和rocket我都学过都简单研究过,自己后续准备用在不同场景下。
    2019-11-06
收起评论
16
返回
顶部