disruptor筆記之四：事件消費知識點小結
- 2021 年 9 月 27 日
- 筆記
歡迎訪問我的GitHub
//github.com/zq2599/blog_demos
內容：所有原創文章分類匯總及配套源碼，涉及Java、Docker、Kubernetes、DevOPS等；
《disruptor筆記》系列鏈接
關於獨立消費和共同消費
-
本篇是《disruptor筆記》的第四篇，前面章節寫了不少程式碼，搞得讀者和作者都辛苦，本篇稍微放鬆一下，熟悉一個重要概念：disruptor事件的消費模式，包括獨立消費和共同消費兩種；
-
舉個例子，假設在電商場景中，每產生一個訂單都要發郵件和簡訊通知買家，如果產生了十個訂單，就有以下兩種情況要考慮：
第一種：要發十封郵件和十條簡訊，此時，郵件系統和簡訊系統是各自獨立的，他們各自消費這十個訂單的事件，也就是說十個事件被消費二十次，所以郵件系統和簡訊系統各自獨立消費，彼此沒有關係，如下圖，一個原點代表一個事件：
第二種：假設郵件系統處理能力差，為了提升處理能力，部署了兩台郵件伺服器，因此是這兩台郵件伺服器共同處理十個訂單事件，合起來一共發送了十封郵件，如下圖，一號郵件伺服器和二號郵件伺服器是共同消費，某個訂單事件只會在一個郵件伺服器被消費：
獨立消費的核心知識點
- 使用的API是handleEventsWith
- 業務處理邏輯放入EventHandler的實現類中
- 內部實現用BatchEventProcessor類，一個消費者對應一個BatchEventProcessor實例，任務是獲取事件再調用EventHandler的onEvent方法處理
- 一個消費者對應一個SequenceBarrier實例，用於等待可消費事件
- 一個消費者對應一個Sequence實例（BatchEventProcessor的成員變數），用於記錄消費進度
- 每個BatchEventProcessor實例都會被放入集合（consumerRepository.consumerInfos）
- Disruptor的start方法中，會將BatchEventProcessor放入執行緒池執行，也就是說每個消費者都在獨立執行緒中執行
共同消費的核心知識點
- 使用的API是handleEventsWithWorkerPool
- 業務處理邏輯放入WorkHandler的實現類中
- 內部實現用WorkerPool和WorkProcessor類合作完成的，WorkerPool實例只有一個，每個消費者對應一個WorkProcessor實例
- SequenceBarrier實例只有一個，用於等待可消費事件
- 每個消費者都有自己的Sequence實例，另外還有一個公共的Sequence實例（WorkerPool的成員變數），用於記錄消費進度
- WorkerPool實例會包裹成WorkerPoolInfo實例再放入集合（consumerRepository.consumerInfos）
- Disruptor的start方法中，會調用WorkerPool.start方法，這裡面會將每個WorkProcessor放入執行緒池執行，也就是說每個消費者都在獨立執行緒中執行
精簡的小結
- 上述核心知識點還是有點多，咱們用對比來精簡一下，以下是精華中的精華，真不能再省了，請重點關註：
- 獨立消費的每個消費者都有屬於自己獨有的SequenceBarrier實例，共同消費者是所有人共用同一個SequenceBarrier實例
- 獨立消費的每個消費者都有屬於自己獨有的Sequence實例，對於共同消費者，雖然他們也有屬於自己的Sequence實例，但這個Sequence實例的值是從一個公共Sequence實例（WorkerPool的成員變數workSequence）得來的
- 獨立消費和共同消費都有自己的取數據再消費的程式碼，放在一起對比看就一目了然了，如下圖，共同消費時，每個消費者的Sequence值其實來自公共Sequence實例，多執行緒之間用CAS競爭來搶佔事件用於消費：
用圖說話
- 最後放上自製圖一張，希望有一圖勝千言的效果吧：
- 至此，理論分析結束，接下來的文章會乘熱打鐵，基於上述知識點進行實戰，編碼實現三個場景：
- 100個訂單，簡訊和郵件系統獨立消費
- 100個訂單，郵件系統的兩個郵件伺服器共同消費；
- 100個訂單，簡訊系統獨立消費，與此同時，兩個郵件伺服器共同消費；
你不孤單，欣宸原創一路相伴
歡迎關注公眾號：程式設計師欣宸
微信搜索「程式設計師欣宸」，我是欣宸，期待與您一同暢遊Java世界…
//github.com/zq2599/blog_demos
