notify的介紹和應用場景

Notify是一款高可靠、高實時的消息中間件，是交易鏈路的核心節點。具有了如下的特性

分佈式事務特性-交易狀態最終一致性的保證

把應用的業務操做和消息發送組成一個分佈式事務，保證業務操做和消息發送是個原子操做。 案例：交易平臺本地操做建立訂單，而後發送訂單建立消息，須要讓處理訂單的系統最終看到的訂單狀態是一致的。若是訂單建立成功，可是消息發送失敗；或者消息發送成功，訂單建立失敗。就會致使處理訂單消息的相關係統所看到的訂單狀態是不一致的，業務會出大問題。基於notify分佈式事務的特性就能夠保證訂單建立和消息發送同時成功或者同時失敗，而notify自己提供了可靠的消息服務，這樣就保證相關係統所看到的訂單狀態保持最終一致性。

推送+無序-提供最高實時性的消息服務

許多場景都須要實時性的保證，而推送和無序的模型保證了高實時性，ms級別。無序模型，消息投遞的併發度最高，並且不會由於一個消息消費失敗，致使後面的消息消費不了；推送模型使得消息一旦到達服務器會立馬推送給客戶端，無間歇。 案例：淘金幣兌換商品，收到交易成功消息後，迅速扣除金幣。若是實時性太差就有可能出現業務漏洞。好比某個用戶總共只有10個金幣，用10個金幣兌換商品後，剩餘0個金幣。若是消息推送不實時，那麼用戶的金幣在必定的時間窗口以內沒有被扣除，這樣他就能夠繼續兌換其餘商品。

雙寫特性-消息存儲的高度可靠

數據若是隻寫一份的話，那麼當磁盤出現問題的時候，數據就會丟失。爲了解決單點故障問題，notify提供雙寫機制，大大提升了消息數據的可靠性。 案例：交易須要保證數據的絕對安全可靠，交易集羣開啓了雙寫機制。交易每發送一條消息都會同時寫入到兩個mysql實例，雙寫成功才表明消息發送成功。

header訂閱-消息細分業務訂閱

有些業務場景比較複雜，純粹的主題+消息類型二元組訂閱已經沒法知足需求。header訂閱支持消息屬性表達式過濾，提供更加動態靈活的訂閱機制。 案例：交易消息，某個業務訂閱主題爲交易，消息類型爲訂單建立的消息，可是他只關注類目A。按照傳統的訂閱方式，主題+消息類型二元組，notify會把這個主題+消息類型的消息所有投遞給訂閱者，訂閱者收到消息後只處理類目A的消息，其餘忽略。而採用header訂閱，他能夠在主題+消息類型之上，在加一個屬性過濾條件property.rootcat == A，這樣一來notify只會把類目A的消息投給訂閱者，訂閱者的處理邏輯簡化了。另外，當消息量大的時候，header訂閱能夠節約了服務器的帶寬成本，同時節約了訂閱者的資源消耗。

單元化-支持多單元機房部署

隨着業務的擴大，杭州的機房已經達到瓶頸，沒法容納更多的機器，須要進行多單元的部署。notify具有了單元化的特性，能夠支持消息在不一樣單元之間的路由，把消息投遞到準確的單元訂閱者。單元1發佈的消息，會被單元1的訂閱者收到，單元化的應用流量會被均衡分配到每一個單元。對於一些未單元化的訂閱者，經過中心機房的全量投遞，也能收到單元機房發送的消息。 單元路由規則詳見http://baike.corp.taobao.com/images/8/8b/Notify%E5%8D%95%E5%85%83%E5%8C%96%E6%95%B4%E7%90%86.pdf

運維體系-優化用戶體驗，提升運維效率

notify管控系統提供了消息發佈、訂閱申請、應用下線一條龍服務，提供完善的消息堆積報警體系，讓用戶及時發現系統異常進行處理。提供消息軌跡查詢，任何一條消息都能查到投遞去向。提供客戶端診斷工具，用戶能夠快速定位使用過程當中的問題。 管控平臺平常 http://ops.jm.taobao.net/notify-side/index 線上 http://ops.jm.taobao.org:9999/notify-side/index?spm=0.0.0.0.EyuYOj