歡迎訪問我的GitHub
https://github.com/zq2599/blog_demos
內容：所有原創文章分類彙總及配套源碼，涉及Java、Docker、Kubernetes、DevOPS等；
《disruptor筆記》系列鏈接
關於獨立消費和共同消費
-
本篇是《disruptor筆記》的第四篇，前面章節寫了不少代碼，搞得讀者和作者都辛苦，本篇稍微放鬆一下，熟悉一個重要概念：disruptor事件的消費模式，包括獨立消費和共同消費兩種；
-
舉個例子，假設在電商場景中，每產生一個訂單都要發郵件和短信通知買家，如果產生了十個訂單，就有以下兩種情況要考慮：
第一種：要發十封郵件和十條短信，此時，郵件系統和短信系統是各自獨立的，他們各自消費這十個訂單的事件，也就是說十個事件被消費二十次，所以郵件系統和短信系統各自<font color="red">獨立消費</font>，彼此沒有關係，如下圖，一個原點代表一個事件：
第二種：假設郵件系統處理能力差，爲了提升處理能力，部署了兩臺郵件服務器，因此是這兩臺郵件服務器共同處理十個訂單事件，合起來一共發送了十封郵件，如下圖，一號郵件服務器和二號郵件服務器是<font color="red">共同消費</font>，某個訂單事件只會在一個郵件服務器被消費：
獨立消費的核心知識點
- 使用的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世界... https://github.com/zq2599/blog_demos