企业官网建设流程全解析

泰安网站建设收费标准,网站主题有哪些内容,做pc端网站行业现状,旅游开发公司网站建设方案书你好#xff0c;我是程序员贵哥。 今天我想要与你分享的是在处理大规模数据中十分流行的一种设计模式#xff1a;发布/订阅模式#xff08;Publish/Subscribe Pattern#xff09;#xff0c;有些地方也称它为Pub/Sub。 在了解发布/订阅模式之前#xff0c;我想先简单介…你好我是程序员贵哥。今天我想要与你分享的是在处理大规模数据中十分流行的一种设计模式发布/订阅模式Publish/Subscribe Pattern有些地方也称它为Pub/Sub。在了解发布/订阅模式之前我想先简单介绍几个基础概念——消息Message和消息队列Message Queue。消息消息是什么呢在分布式架构里架构中的各个组件Component需要相互联系沟通。组件可以是后台的数据库可以是前端的浏览器也可以是公司内部不同的服务终端Service Endpoint。而各个组件间就是依靠通过发送消息互相通讯的。如下图所示。消息可以是任意格式的。例如我们可以利用JSON格式来传输一个消息也能利用XML格式来传输一个消息甚至可以使用一种自己定义的格式。消息队列知道了消息的含义后你知道消息队列有什么作用吗消息队列在发布/订阅模式中起的是一个持久化缓冲Durable Buffer的作用。消息的发送方可以发送任意消息至这个消息队列中消息队列在接收到消息之后会将消息保存好直到消息的接收方确认已经从这个队列拿到了这个消息才会将这条消息从消息队列中删除。有的消息系统平台如Apache Kafka它能够让用户自己定义消息队列对消息的保留时间我将会在介绍Apache Kafka的时候讲到。有了消息队列后整个发送消息的流程就变成下图所示。发布/订阅模式在了解了消息和消息队列后现在我想和你正式地介绍发布/订阅模式的概念。发布/订阅模式指的是消息的发送方可以将消息异步地发送给一个系统中不同组件而无需知道接收方是谁。在发布/订阅模式中发送方被称为发布者Publisher接收方则被称作订阅者Subscriber。发布者将消息发送到消息队列中订阅者可以从消息队列里取出自己感兴趣的消息。在发布/订阅模式里可以有任意多个发布者发送消息也可以有任意多个订阅者接收消息如下图所示。读到这里你可能会有一个疑问从概念上看发布/订阅模式只是简单地在消息发送方和消息接收方中间多加了一个消息队列为什么这种设计架构在实际应用会如此流行呢我来给你举个例子说明一下。现在假设你是一个移动支付App公司里支付团队的开发人员App里所有的支付操作都是由你的团队来开发的。而公司最近新成立了一个欺诈预防团队他们希望从你的支付团队里获取交易数据。也就是说每次有交易发生的时候你都需要通知他们交易的金额、地点、时间这些数据让他们能够实时分析这次的交易是否存在欺诈行为。按照传统的做法两个团队需要开会交流以确定数据消息传输的API和传输数据的格式。确定后两个团队系统的交流方式会如下图所示。欺诈预防团队将自己需要的数据格式定义在API中告诉支付团队每次有交易产生的时候支付系统就会通过调用欺诈预防系统API的方式通知他们。一段时间过后公司希望和商家一起合作推动一项优惠活动不同的商家会有不同的优惠。公司希望能够精准投放优惠活动的广告给感兴趣的用户所以又成立了一个新部门我们叫它广告推荐组吧。广告推荐组的同事也希望从你的支付团队里获取交易数据。这个时候你有两种选择一种是选择第六讲中说到的批处理方式另一种就是今天讲的发布/订阅模式。批处理方式会从数据库中一次性读取全部用户的交易数据来进行推荐分析。这种做法有几个不好的地方。它需要你开放自己数据库的权限给广告推荐组推荐组每次大量读取数据时可能也会造成你自己的数据库性能下降。同时还要考虑广告推荐组也想维护一份自己的数据库的需求。如果还是按照之前欺诈预防团队的做法让广告推荐组分享API给你每次有交易产生的时候再通知他们的话系统的运行模式会如文中图片所示。看到这里你应该明白了。每一次有一个新的系统想从支付团队里读取数据的话都要双方开会讨论定义一个新的API然后修改支付团队现有的系统将API加入系统中。而且这些API通常都是同步调用的过多的API调用会让系统的延迟越来越大。这样的设计模式被称作观察者模式Observer Pattern系统中的各个组件紧耦合Tightly Coupled在一起。如果是采用发布/订阅模式来重新设计呢整个系统就如下图所示采用这样的数据处理模式作为消息发布者的支付团队无需过多考虑以后有多少其它的团队需要读取交易数据只需要设计好自己提供的数据内容与格式在每次交易发生时发送消息进消息队列中就可以了。任何对这些数据感兴趣的团队只需要从消息队列中自行读取便可。发布/订阅模式的优缺点说到这里我们可以看到发布/订阅模式会有以下几个优点松耦合Loose Coupling消息的发布者和消息的订阅者在开发的时候完全不需要事先知道对方的存在可以独立地进行开发。高伸缩性High Scalability发布/订阅模式中的消息队列可以独立的作为一个数据存储中心存在。在分布式环境中更是消息队列更是可以扩展至上千个服务器中。我们从Linkedin公司的技术博客中可以得知光在2016年Linkedin公司就维护开发了将近1400个消息队列。系统组件间通信更加简洁因为不需要为每一个消息的订阅者准备专门的消息格式只要知道了消息队列中保存消息的格式发布者就可以按照这个格式发送消息订阅者也只需要按照这个格式接收消息。虽然发布/订阅模式的数据处理模式优点多多但是还是存在着自身的缺点的。例如在整个数据模式中我们不能保证发布者发送的数据一定会送达订阅者。如果要保证数据一定送达的话需要开发者自己实现响应机制。在硅谷很多大型云平台都是运用这个发布/订阅数据处理模式。例如Google的Cloud Pub/Sub平台AWS的Amazon Simple Notification ServiceSNS。被Linkedin、Uber等硅谷大厂所广泛使用的开源平台Apache Kafka也是搭建在发布/订阅数据处理模式之上的。甚至是连Redis也支持原生的发布/订阅模式。Apache Kafka作为一个被在硅谷大厂与独角兽广泛使用的开源平台如果你是在创业阶段的话说不定可以用得上所以在这里我想简单介绍一下Apache Kafka。在Apache Kafka中消息的发送方被称为Producer消息的接收方被称为Consumer而消息队列被称为Topic。Apache 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。发布/订阅模式的适用场景我们说回到发布/订阅模式来看看它能用在哪些场景。如果你在处理数据的时候碰到以下场景那么就可以考虑使用发布/订阅的数据处理模式。系统的发送方需要向大量的接收方广播消息。系统中某一个组件需要与多个独立开发的组件或服务进行通信而这些独立开发的组件或服务可以使用不同的编程语言和通信协议。系统的发送方在向接收方发送消息之后无需接收方进行实时响应。系统中对数据一致性的要求只需要支持数据的最终一致性Eventual Consistency模型。要提醒你注意的一点是如果系统的发送方在向接收方发送消息之后需要接收方进行实时响应的话那么绝大多数情况下都不要考虑使用发布/订阅的数据处理模式。小结今天我们一起学习了大规模数据处理中一种十分流行的设计模式——发布/订阅模式。它能够很好地解耦Decouple系统中不同的组件许多实时的流处理架构就是利用这个数据处理的设计模式搭建起来的。因为发布/订阅模式同时具有很好的伸缩性。如果你在开发的场景适合我所讲到的适应场景可以优先考虑使用发布/订阅模式。