鄭昀 基於朱傳志的設計文件 最後更新於2014/11/11
非同步訊息
、訂閱者集群、可伸縮、push模式、pull模式
電商系統為什麼需要 notifyserver？
如子柳所說，電商系統『
需要兩種中介軟體系統，一種是實時呼叫的中介軟體（**的hsf，高效能服務框架）、一種是非同步訊息通知的中介軟體（**的notify）』。那麼用傳統的 activemq/rabbitmq 來實現 非同步訊息發布和訂閱 不行嗎？
2023年之前我們確實用的是 activemq，當然主要是訂閱者 pull 模式，選 mysql 做訊息持久化儲存，sa 還為此反覆測試了各種高可用方案，如下圖所示，activemq 5.8，mq主從+mysql互為主從+mmm。
圖1 mq 高可用
它有三個問題。
第一，它對上游發布者要求可能不是那麼高，但要求下游實現訊息訂閱時要健壯，比如訂閱者把訊息讀走了後它掛了也得不丟棄訊息繼續處理，比如非常重要的訊息不能只有乙個單點訂閱者，必須有訂閱者集群，但又不能重複處理訊息。我在《#研發中介軟體介紹#jobcenter》中說過，對每一位開發者維護者提出高要求，這不是我們的解題思路。我在《職場培訓第五期：職場的真相》中給出了解題思路：『要摒棄單純依靠員工之間互相提醒、依靠個人認真細緻來規避相同錯誤的固有思路，鐵打營盤流水兵，靠人終歸是靠不住的，最好靠遵循規則的機器』。是的，非同步訊息的可靠推送（push），應該是訊息中介軟體的職責。
第二，activemq 的高可用方案在可伸縮上不那麼靈活，不適合電商業務。譬如說，我一開始用一組 [(mq1+mysql1(master角色)),(mq2+mysql2)] 來支撐所有業務的非同步訊息，但突然七夕節乙個銷售驗證高峰即將到來，需要盡量平滑地把某些訊息佇列轉移出去，用另一組支撐；或者我看某個訊息佇列的訊息量比較大，想追加乙個 mysql 節點單獨儲存它的訊息。總之就是線上盡量平滑地擴容 mq server和 database，這事兒還得咱們自己從頭搞才順手。
最後乙個問題是所有開源系統的典型問題，伴隨著開源系統以及各種 driver 的版本公升級，我們會一路踏入它埋下的每乙個大大小小的坑。當然，不是說我們自己寫的中介軟體就沒有 bug，但 activemq 確實讓人攤手，如下面的 rca 案例所示。
最終我們還是選擇自己來面對如下場景，採用 push 模式（notifyserver 主動向下游 push 訊息）：
圖2 乙個非同步訊息需要很多訂閱者集群分頭處理
**是怎麼考慮這些問題的？
因此，訊息有可能在三個地方丟失
穩定性
控制
限制
它內部兩個訊息中介軟體產品的區別為：
圖3 訊息中介軟體對比
以上資料出自於《訊息中介軟體-notify的概念和原理.pdf》。
窩窩如何實現 notifyserver 的？
2023年2月，經過幾輪的討論，技術選型初步確定，研發2部傳志開始構建 notifyserver。
他設計了如下概念：
圖4 notifyserver 的幾個角色概念
技術模型可以描述為：
模組監控
訊息跟蹤
那麼最簡單的訊息消費泳道圖如下所示：
圖5 訊息消費
分配中心主導的慢速/重試push，它會盡量從快取（redis）中拿訊息體，儘量減少對 db 的訪問，尤其是訊息體特別大的時候，效果會比較明顯，如下圖所示。
圖6 重試的泳道圖
對於可伸縮、高可用，他是這麼考慮的：
擴充套件性
可用性
一致性
等冪性
與 jobcenter 一樣，notifyserver 也納入在我們的 idcenter 體系下，這樣可以共用一套帳號體系（ldap），共用乙個統一的許可權分配：
圖7 notifyserver 的入口
圖8 notifyserver 的主介面
圖9 notifyserver 系統佇列（主要是配置資訊）介面
圖10 notifyserver 監控佇列（主要是執行時狀況）介面
2023年中旬，經過積分業務的試用後，傳志的 notifyserver 開始在內部推廣，各種非同步訊息發布和訂閱一點一點地搬進來，activemq 方案下線。
-over-
窩窩的解決方案介紹列表：
#研發解決方案#基於statsd+graphite的智慧型監控解決方案
#研發中介軟體介紹#定時任務排程與管理jobcenter
#研發解決方案介紹#recsys-evaluate（推薦評測）
#研發解決方案介紹#tracing（鷹眼）
#研發解決方案介紹#基於持久化配置中心的業務降級
#研發中介軟體介紹#非同步訊息可靠推送notify
#研發解決方案介紹#idcenter（內部統一認證系統）
#研發解決方案介紹#基於es的搜尋+篩選+排序解決方案
#資料技術選型#即席查詢shib+presto，集群任務排程hue+oozie
訊息中介軟體
1.訊息的優先順序 2.訊息排序 3.訊息過濾 4.訊息持久化 5.訊息重試 6.事務的支援 7.broker滿 生產者，佇列，消費者 訊息佇列的優點 1 解耦2 非同步訊息，系統響應 在jms中，有兩種訊息模型 點對點模式和發布訂閱模式。1.在點對點模式中 有三種角色 1 訊息佇列，傳送者，接受者...
訊息中介軟體
如何理解訊息中介軟體？訊息中介軟體是儲存訊息的乙個容器，與資料庫不同的是資料庫儲存的資料是可以被修改的，而訊息中介軟體一般不會被修改 訊息中介軟體在消費的生產者與消費者產生，相當於乙個中間人的角色，提供了路由保證訊息的傳遞，如果消費者不能及時接收，訊息會保留下來，知道消費者上線 保證在存活期內 訊息...
訊息中介軟體
訊息中介軟體是在訊息的傳輸過程中儲存訊息 訊息傳遞過程中不能更改 的容器。訊息中介軟體再將訊息從它的原中繼到它的目標時充當中間人的作用。訊息中介軟體的主要目的是提供路由並保證訊息的傳遞 如果傳送訊息時接收者不可用，訊息佇列會保留訊息，知道可以成功傳遞為止，當然，訊息佇列儲存訊息也是有期限的。訊息傳送...