发布/订阅模式:流处理架构中的瑞士军刀

发布/订阅模式,又可以称为生产者/消费者模式,(Publish/Sbuscribe Pattern ) 或者(Pub/Sbu)
首先介绍几个概念:消息和消息队列

消息

在分布式架构中,架构中的每个组件(Componet)需要相互联系沟通.组件可以是后台的数据库,可以是前端浏览器,也可以是公司内部不同的服务器端(Service Endpoint),各个组件之间是通过依靠发送消息互相通讯的
Componet A ———————-send messsage—————————> ComponetB 
Componet B ————————send Message —————————->Componet A
其中,发送的消息,其格式可以是任意的,比如:json,xml 或者自定义的格式

消息队列

消息队列在发布/订阅模式中,起到的是一个持久化缓冲(Durable Buffer )的作用.
消息的发送方可以发送任意消息到这个消息队列中,消息队列在接受到消息以后,会讲消息存储好,一直到消息的接收方确认已经从这个消息队列中拿到了这个消息,才会将消息从消息队列中删除.
有的消息系统平台,比如Apache Kafka 它能够让用户自定义消息队列对消息的保留时间.
有了消息队列以后,整个消息的流程就变成了下图:
message_quere.jpg

发布/订阅模式

发布/订阅模式:消息的发送方可以讲消息异步地发送给一个系统中不同的组件,而无需知道接收方是谁. 再发布/订阅模式中,发送方被称为发布者(Publisher),接收方则被称为订阅者(Subscriber).
发布者只需要将消息发送到消息队列中,订阅者可以取出自己感兴趣的消息.
在发布/订阅模式中,可以有任意多个发布者,也可以有任意多个订阅者,它们是多对多的关系,如下图:
multi_sender_and_multi_subscribe.jpg
采用这种数据处理模式,作为消息的发送者不需要考虑以后后期有多少新增需要同样数据的团队,只需要设计好自己提供的数据的内容和格式,在每一次需要发送消息的时候,发送到消息队列中就可以了.任何对这个感兴趣的团队,经过授权都可以从消息队列中自行读取.

优点和缺点:

优点

1)松耦合性(Loose Coupling ):消息的发布者和消息的订阅者在开发的时候,完全不需要知道对方的存在,可以进行独立的开发,只需要定义好数据的格式即可
2) 高伸缩性(High Scalability ):发布/订阅模式的消息队列可以独立的作为一个数据存储中心存在.在分布式的环境中,更是消息队列可以扩展至上千个服务器中.Linkedin 公司在2016年维护和开发了将近1400个消息队列
3)系统组件间通信更加的简洁:发布者不需要为每一个新订阅者准备消息格式,只要知道了消息队列中保存消息的格式,发布者就可以按照这个格式发送数据,订阅者只需要按照这个数据格式接受消息即可.

缺点

1)整个数据模式中,我们不能保证发布者发送的数据一定发送到订阅者.如果要保证数据一定送达的话,需要开发者实现自己的响应机制.
使用发布/订阅模式的一些公司:
google -> CLoud Pub/Sub
AWS -> Amazon Simple Notifiation Service (SNS)
linkedin ,Uber -> Apache Kafka
Redis也有消息发布订阅功能
下面着重介绍Apache Kafka

介绍:

在Apache Kafka中,消息的发送发被称为生产者(Producer)
消息的的接收方被称为消费者(Consumer)而,消息直接被称为Topic .

Aapche Kafka有一个响应机制,判断消息的接收方是否接受了消息采用的Log offset 机制.
Log offset 机制的介绍:
假设发送方连续发送了 5 条数据到消息队列 Topics 中,这 5 条消息被编号为 10000、10001、10002、10003 和 10004。
如果接收方读取数据之后回应消息队列它接收的 Log offset 是 10000、10001 和 10003,那么消息队列就会认为接收方最多只接收了消息 10000 和 10001,剩下的消息 10002、10003 和 10004 则会继续发送给接收方,直到接收方回应接收了消息 10002、10003 和 10004。

发布/订阅模式的使用场景:

1)消息的发送方需要向大量的接收方广播消息
2)系统中某一个组件需要与多个独立开发的组件或者服务进行通信,而这些独立开发的组件或者服务可以使用不同的变成语言和通信协议
3)系统的发送方在向接收方发送消息以后,无需接收方进行实时响应
4)系统中对数据一致性的要求只需要支持数据的最终一致性(Eventual COnsistency)模型.
Tips:如果系统的发送方在向接收方发送消息以后,需要接收方进行实时的响应的话,那么绝大多少情况下,都不需要考虑使用这种模型

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值