3.1、Notify
Notify是淘寶自主研發的一套消息服務引擎，是支撐雙11最為核心的系統之一，在淘寶和支付寶的核心交易場景中都有大量使用。消息系統的核心作用就是三點：解耦，異步和并行。下面讓我以一個實際的例子來說明一下解耦異步和并行分别所代表的具體意義吧：
假設我們有這麼一個應用場景，為了完成一個使用者注冊淘寶的操作，可能需要将使用者資訊寫入到使用者庫中，然後通知給紅包中心給使用者發新手紅包，然後還需要通知支付寶給使用者準備對應的支付寶賬号，進行合法性驗證，告知sns系統給使用者導入新的使用者等10步操作。
那麼針對這個場景，一個最簡單的設計方法就是串行的執行整個流程，如圖3-1所示：
圖3-1-使用者注冊流程
這種方式的最大問題是，随着後端流程越來越多，每步流程都需要額外的耗費很多時間，進而會導緻使用者更長的等待延遲。自然的，我們可以采用并行的方式來完成業務，能夠極大的減少延遲，如圖3-2所示。
圖3-2-使用者注冊流程-并行方式
但并行以後又會有一個新的問題出現了，在使用者注冊這一步，系統并行的發起了4個請求，那麼這四個請求中，如果通知SNS這一步需要的時間很長，比如需要10秒鐘的話，那麼就算是發新手包，準備支付寶賬号，進行合法性驗證這幾個步驟的速度再快，使用者也仍然需要等待10秒以後才能完成使用者注冊過程。因為隻有當所有的後續操作全部完成的時候，使用者的注冊過程才算真正的“完成”了。使用者的資訊狀态才是完整的。而如果這時候發生了更嚴重的事故，比如發新手紅包的所有伺服器因為業務邏輯bug導緻down機，那麼因為使用者的注冊過程還沒有完全完成，業務流程也就是失敗的了。這樣明顯是不符合實際的需要的，随着下遊步驟的逐漸增多，那麼使用者等待的時間就會越來越長，并且更加嚴重的是，随着下遊系統越來越多，整個系統出錯的機率也就越來越大。
通過業務分析我們能夠得知，使用者的實際的核心流程其實隻有一個，就是使用者注冊。而後續的準備支付寶，通知sns等操作雖然必須要完成，但卻是不需要讓使用者等待的。
這種模式有個專業的名詞，就叫最終一緻。為了達到最終一緻，我們引入了MQ系統。業務流程如下：
主流程如圖3-3所示：
圖3-3-使用者注冊流程-引入MQ系統-主流程
異步流程如圖3-4所示：
圖3-4-使用者注冊流程-引入MQ系統-異步流程
核心原理
Notify在設計思路上與傳統的MQ有一定的不同，他的核心設計理念是
1. 為了消息堆積而設計系統
2. 無單點，可自由擴充的設計
下面就請随我一起，進入到我們的消息系統内部來看看他設計的核心原理
-
為了消息堆積而設計系統在市面上的大部分MQ産品，大部分的核心場景就是點對點的消息傳輸通道，然後非常激進的使用記憶體來提升整體的系統性能，這樣做雖然标稱的tps都能達到很高，但這種設計的思路是很難符合大規模分布式場景的實際需要的。
在實際的分布式場景中，這樣的系統會存在着較大的應用場景瓶頸，在後端有大量消費者的前提下，消費者出現問題是個非常常見的情況，而消息系統則必須能夠在後端消費不穩定的情況下，仍然能夠保證使用者寫入的正常并且TPS不降，是個非常考驗消息系統能力的實際場景。
也因為如此，在Notify的整體設計中，我們最優先考慮的就是消息堆積問題，在目前的設計中我們使用了持久化磁盤的方式，在每次使用者發消息到Notify的時候都将消息先落盤，然後再異步的進行消息投遞，而沒有采用激進的使用記憶體的方案來加快投遞速度。
這種方式，雖然系統性能在峰值時比目前市面的MQ效率要差一些，但是作為整個業務邏輯的核心單元，穩定，安全可靠是系統的核心訴求。
- 無單點，可自由擴充的設計
圖3-5-Notify系統組成結構
圖3-5展示了組成Notify整個生态體系的有五個核心的部分。
- 發送消息的叢集這主要是業務方的機器，這些APP的機器上是沒有任何狀态資訊的，可以随着使用者請求量的增加而随時增加或減少業務發送方的機器數量，進而擴大或縮小叢集能力。
- 配置伺服器叢集(Config server)這個叢集的主要目的是動态的感覺應用叢集，消息叢集機器上線與下線的過程，并及時廣播給其他叢集。如當業務接受消息的機器下線時，config server會感覺到機器下線，進而将該機器從目标使用者組内踢出，并通知給notify server，notify server 在擷取通知後，就可以将已經下線的機器從自己的投遞目标清單中删除，這樣就可以實作機器的自動上下線擴容了。
- 消息伺服器(Notify Server)消息伺服器，也就是真正承載消息發送與消息接收的伺服器，也是一個叢集，應用發送消息時可以随機選擇一台機器進行消息發送，任意一台server 挂掉，系統都可以正常運作。當需要增加處理能力時，隻需要簡單地增加notify Server就可以了
- 存儲(Storage)Notify的存儲叢集有多種不同的實作方式，以滿足不同應用的實際存儲需求。針對消息安全性要求高的應用，我們會選擇使用多份落盤的方式存儲消息資料，而對于要求吞吐量而不要求消息安全的場景，我們則可以使用記憶體存儲模型的存儲。自然的，所有存儲也被設計成了随機無狀态寫入存儲模型以保障可以自由擴充。
- 消息接收叢集業務方用于處理消息的伺服器組，上下線機器時候也能夠動态的由config server 感覺機器上下線的時機，進而可以實作機器自動擴充。
3.3、MetaQ
METAQ是一款完全的隊列模型消息中間件，伺服器使用Java語言編寫，可在多種軟硬體平台上部署。用戶端支援Java、C++程式設計語言，已于2012年3月對外開源，開源位址是：http://metaq.taobao.org/。MetaQ大約經曆了下面3個階段
- 在2011年1月份釋出了MetaQ 1.0版本，從Apache Kafka衍生而來，在内部主要用于日志傳輸。
- 在2012年9月份釋出了MetaQ 2.0版本，解決了分區數受限問題，在資料庫binlog同步方面得到了廣泛的應用。
- 在2013年7月份釋出了MetaQ 3.0版本，MetaQ開始廣泛應用于訂單處理，cache同步、流計算、IM實時消息、binlog同步等領域。MetaQ3.0版本已經開源，參見這裡
綜上，MetaQ借鑒了Kafka的思想，并結合網際網路應用場景對性能的要求，對資料的存儲結構進行了全新設計。在功能層面，增加了更适合大型網際網路特色的功能點。
MetaQ簡介
圖3-6-MetaQ整體結構
如圖3-6所示，MetaQ對外提供的是一個隊列服務，内部實作也是完全的隊列模型，這裡的隊列是持久化的磁盤隊列，具有非常高的可靠性，并且充分利用了作業系統cache來提高性能。
- 是一個隊列模型的消息中間件，具有高性能、高可靠、高實時、分布式特點。
- Producer、Consumer、隊列都可以分布式。
- Producer向一些隊列輪流發送消息，隊列集合稱為Topic，Consumer如果做廣播消費，則一個consumer執行個體消費這個Topic對應的所有隊列，如果做叢集消費，則多個Consumer執行個體平均消費這個topic對應的隊列集合。
- 能夠保證嚴格的消息順序
- 提供豐富的消息拉取模式
- 高效的訂閱者水準擴充能力
- 實時的消息訂閱機制
- 億級消息堆積能力
MetaQ存儲結構
MetaQ的存儲結構是根據阿裡大規模網際網路應用需求，完全重新設計的一套存儲結構，使用這套存儲結構可以支援上萬的隊列模型，并且可以支援消息查詢、分布式事務、定時隊列等功能，如圖3-7所示。
圖3-7-MetaQ存儲體系
MetaQ單機上萬隊列
MetaQ内部大部分功能都靠隊列來驅動，那麼必須支援足夠多的隊列，才能更好的滿足業務需求，如圖所示，MetaQ可以在單機支援上萬隊列，這裡的隊列全部為持久化磁盤方式，進而對IO性能提出了挑戰。MetaQ是這樣解決的
- Message全部寫入到一個獨立的隊列，完全的順序寫
- Message在檔案的位置資訊寫入到另外的檔案，串行方式寫。
通過以上方式，既做到資料可靠，又可以支援更多的隊列，如圖3-8所示。
圖3-8-MetaQ單機上萬隊列
MetaQ與Notify差別
- Notify側重于交易消息，分布式事務消息方面。
- MetaQ側重于順序消息場景，例如binlog同步。以及主動拉消息場景，例如流計算等。