01 觀察者模式和發布訂閱模式的區別(觀察者模式和發布-訂閱模式的區別)

觀察者模式和發布-訂閱模式的區別

【1】定義

觀察者模式定義了對象間的一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴于它的對象都將得到通知，并自動更新。觀察者模式屬于行為型模式，行為型模式關注的是對象之間的通訊，觀察者模式就是觀察者和被觀察者之間的通訊。觀察者模式有一個別名叫“發布-訂閱模式”，或者說是“訂閱-發布模式”，訂閱者和訂閱目標是聯系在一起的，當訂閱目標發生改變時，逐個通知訂閱者。

【2】案例

【3】主要解決的問題

一個對象狀態改變給其他對象通知的問題，而且要考慮到易用和低耦合，保證高度的協作。

【4】優點

【5】缺點

【1】介紹

其實24種基本的設計模式中并沒有發布-訂閱模式，上面也說了，他只是觀察者模式的一個別稱。但是經過時間的沉淀，似乎他已經強大了起來，已經獨立于觀察者模式，成為另外一種不同的設計模式。在現在的發布訂閱模式中，稱為發布者的消息發送者不會將消息直接發送給訂閱者，這意味著發布者和訂閱者不知道彼此的存在。在發布者和訂閱者之間存在第三個組件，稱為消息代理或調度中心或中間件，它維持著發布者和訂閱者之間的聯系，過濾所有發布者傳入的消息并相應地分發它們給訂閱者。

【2】案例

【3】優點

【4】缺點

【5】主要解決問題

發布-訂閱模式是前端常用的一種設計模式，現在主流的MVVM框架，都大量使用了此設計模式，其主要作用有以下兩點：

前端的事件綁定有三要素：

從表面上看:

往更深層次講:

從使用層面上講

觀察者模式和發布/訂閱模式的區別

觀察者（Observer）模式又名發布-訂閱（Publish/Subscribe）模式。GOF給觀察者模式如下定義：定義對象間的一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴于它的對象都得到通知并被自動更新。

在這里先講一下面向對象設計的一個重要原則——單一職責原則。因此系統的每個對象應該將重點放在問題域中的離散抽象上。因此理想的情況下，一個對象只做一件事情。這樣在開發中也就帶來了諸多的好處：提供了重用性和維護性，也是進行重構的良好的基礎。

因此幾乎所有的設計模式都是基于這個基本的設計原則來的。觀察者模式的起源我覺得應該是在GUI和業務數據的處理上，因為現在絕大多數講解觀察者模式的例子都是這一題材。但是觀察者模式的應用決不僅限于此一方面。

下面我們就來看看觀察者模式的組成部分。

1) 抽象目標角色（Subject）：目標角色知道它的觀察者，可以有任意多個觀察者觀察同一個目標。并且提供注冊和刪除觀察者對象的接口。目標角色往往由抽象類或者接口來實現。

2) 抽象觀察者角色（Observer）：為那些在目標發生改變時需要獲得通知的對象定義一個更新接口。抽象觀察者角色主要由抽象類或者接口來實現。

3) 具體目標角色（Concrete Subject）：將有關狀態存入各個Concrete Observer對象。當它的狀態發生改變時, 向它的各個觀察者發出通知。

4) 具體觀察者角色（Concrete Observer）：存儲有關狀態，這些狀態應與目標的狀態保持一致。實現Observer的更新接口以使自身狀態與目標的狀態保持一致。在本角色內也可以維護一個指向Concrete Subject對象的引用。

觀察者模式和發布訂閱模式區別

2019-03-06-12:31 午飯吃完啦～

觀察者模式和發布訂閱模式最大的區別就是發布訂閱模式有個事件 調度中心 ！！！

觀察者模式中觀察者和目標直接進行交互，而發布訂閱模式中統一由 調度中心 進行處理，訂閱者和發布者 互不干擾 。這樣一方面實現了 解耦 ，還有就是可以實現更細粒度的一些控制。比如發布者發布了很多消息，但是不想所有的訂閱者都接收到，就可以在 調度中心 做一些處理，類似于 權限控制之類的。

為方便記憶，關鍵字：調度中心、解耦（發布/訂閱者互不干擾）

觀察者模式 vs 發布-訂閱模式

差異總結：

1. 在觀察者模式中，觀察者 （Observer） 是知道Subject的，Subject一直保持對觀察者進行記錄。然而，在發布訂閱模式中，發布者 （Publisher） 和訂閱者 （Subscriber） 不知道對方的存在。它們只有通過消息代理 （ 信息中介 ） 進行通信。

2. 在發布訂閱模式中，組件是松散耦合的，正好和觀察者模式相反。

3. 觀察者模式大多數時候是同步的，比如當事件觸發，Subject就會去調用觀察者的方法。而發布-訂閱模式大多數時候是異步的（使用消息隊列）。

4. 在觀察者模式中依賴于Subject 對象的一系列 Observer 對象在被通知之后只能執行同一個特定的更新方法，而在發布訂閱模式中則可以基于不同的主題去執行不同的自定義事件。

模型闡述：

觀察者模式里，觀察者（Observer）直接訂閱（subscribe）主題（Subject），而當主題被激活的時候，會觸發（fire）觀察者里的事件。

訂閱發布模式里，訂閱者（Subscriber）通過監聽（on）事件總線（Event Bus）里的事件，當事件總線里的事件被觸發（emit）的時候，訂閱者將會執行相應的操作。而這里需要注意的是，事件總線里的事件是通過發布者（Publisher）進行發布（publish）和 通知事件總線 觸發 的。

從發布-訂閱模式到消息隊列

發布-訂閱模式又稱為觀察者模式（網上也有很多說這兩種模式區別，個人覺得區別不大），在發布-訂閱模式中，主要是兩大塊。就是發布和訂閱，那么發布（publish）和訂閱(subscribe)之前的關聯點就是主題(topic).

舉個生活的例子，午餐定外賣，燕姐（broker）在外賣群里發布了兩個可以點的餐館，都城和輝記（這個可以稱為主題），小明(Consumer)點了輝記的，文哥(Consumer)點了都城的（這個可以稱為訂閱），都城餐館（procer）和輝記餐館（procer）做好了飯菜就回給外賣小哥送過來（消息協議），飯菜到了燕姐那里之后，那么小明和文哥就能去燕姐那里去拿（pull），也可以燕姐送過來（push）。這就是我們生活中最常見的發布-訂閱模式。

從上文中可以得到，外賣群是一個載體(MQ)，承載消息的存儲和傳送，從這里可以引出消息隊列的這個概念，下面，繼續說下消息隊列。

MQ (Message Queue) 又稱消息隊列. 隊列我們都知道，那什么是消息呢？消息指的是同一臺機器的進程之間，或不同機器之間傳輸的數據。最簡單的說，我們一個Rpc 請求，所帶的數據就是一個消息。這就是傳統的通信模式。但是這種模式有很多缺陷，例如當網絡不好的時候，這種調用可能會丟失。

隊列提供了一種一步通信協議，這意味著消息的發送者和接收者不需要同時于消息保持聯系，發送者的消息會存儲在隊列中，直到接收者拿到它。 一般我們把消息的發送者稱為生產者，消息的接收者稱為消費者。由于生產者和消費者之間是不透明的，他們靠中間的紐帶-隊列來聯系，那么在隊列中，是消費者占主動還是生產者占主動呢，其實根據不同的獲取消息的方式可以分為 pull or push 著兩種。按字面上的理解，就是pull 是消費者需要自己控制去隊列拉取消息，而push則是生產者占主動位置，將產生的消息push 給消費者，而這種push 可以點對點，也可以是一對多，而這種一對多的模式就是我們常說的廣播模式

在分布式系統中，消息中間件是非常重要的組件，主要解決應用耦合，異步消息，流量削峰等問題。

常用的消息隊列中間件有 activeMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ

(可參考 買粉絲s://mp.weixin.qq.買粉絲/s/ad7jibTb5nTzh3nDQYKFeg ? 覺得這篇文章寫得很不錯也很詳細)

這次我主要寫的是kafka 這個消息中間件，kafka 是采用pull 這種模式來消費信息的，生產者將消息放入隊列中，而消費者可以通過epull 方法獲取消息來消費，下面還是先說下kafka 的幾個關鍵概念吧

Kafka是最初由Linkedin公司開發，是一個分布式、分區的、多副本的、多訂閱者，基于zookeeper協調的分布式日志系統（也可以當做MQ系統），常見可以用于web/nginx日志、訪問日志，消息服務等等，Linkedin于2010年貢獻給了Apache基金會并成為頂級開源項目

主要應用場景是：日志收集系統和消息系統。

Kafka主要設計目標如下：

同時支持離線數據處理和實時數據處理。

一個典型的kafka集群中包含若干procer，若干broker，若干買粉絲nsumer，以及一個Zookeeper集群。Kafka通過Zookeeper管理集群配置，選舉leader，以及在買粉絲nsumer group發生變化時進行rebalance。procer使用push模式將消息發布到broker，買粉絲nsumer使用pull模式從broker訂閱并消費消息。

Topic & Partition

一個topic可以認為一個一類消息，每個topic將被分成多個partition，每個partition在存儲層面是append log文件。

在Kafka文件存儲中，同一個topic下有多個不同partition，每個partition為一個目錄，partiton命名規則為topic名稱+有序序號，第一個partiton序號從0開始，序號最大值為partitions數量減1

每個partion（目錄）相當于一個巨型文件被平均分配到多個大小相等segment（段）數據文件中。但每個段segment file消息數量不一定相等，這種特性方便old segment file快速被刪除。

每個partiton只需要支持順序讀寫就行了，segment文件生命周期由服務端配置參數決定。

這樣做的好處就是能快速刪除無用文件，有效提高磁盤利用率。

segment file組成：由2大部分組成，分別為index file和data file，此2個文件一一對應，成對出現，后綴".index"和“.log”分別表示為segment索引文件、數據文件.

segment文件命名規則：partion全局的第一個segment從0開始，后續每個segment文件名為上一個segment文件最后一條消息的o

很赞哦!（63648）