阿里消息中間件ONS的應用場景（一）

消息中間件的產生主要是爲了達到如下目的：

1. 異步
2. 解耦
3. 最終一致性
4. 並行

 下面咱們來看針對同一件事情，不一樣的處理辦法：

過年了拜年發微信：

• 普通青年：編輯微信，羣發給全部人。
• 文藝青年：編輯微信，交給美膩祕書發送，本身已去......
• 二筆青年：編輯微信，發送；編輯微信，發送；編輯微信，發送；..........

咱們如今主要關注第二種場景，它的使用方式實現瞭解耦操做和異步操做。

• 舉一個淘寶的簡單例子：

一筆交易的完成涉及到不少系統協調操做的過程，如上多個系統，但若是隻是串行的執行這些操做，可能還沒執行完這些操做，用戶可能已沒有耐心，離開了操做界面。給用戶留下很差的用戶體驗。

• 如今消息中間件就派上了用場：

（如下截圖都取自阿里沈詢消息中間件ONS講解）

消息中間件具備減小延遲，提高用戶體驗（異步解耦）

最終一致性：若是因爲消息中間件消費端的一個模塊 crash 了，而出現的短暫不一致現象，而該模塊恢復之後會從新完成它的操做，最終保證數據操做的一致性，咱們可使用消息中間件來保證最終狀態的統一。

並行：由於消息時並行發送到各個消息隊列的，也是並行的被各個系統進行處理的，系統的高效能夠由此獲得保證。

ONS的設計思路：

消息中間件的難點主要是在於權衡和取捨。

• 設計假定：
  • 每臺PC機器均可能down機不可服務
  • 任意集羣均可能處理能力不足
  • 最壞的狀況必定會發生
  • 內網環境要低延遲來提供最佳用戶體驗
• 關鍵設計：
  • 分佈式集羣化
  • 強數據安全
  • 海量數據堆積
  • 毫秒級投遞延遲

數據安全：交易物流等 數據不能丟失

使用隊列多冗餘的方式保證消息隊列的高可用性。（包括數據的複製，服務器的切換等操做都是在消息隊列後端來完成，對用戶是不可見的）。

中間件設計保證：無論系統堆積了多少消息，系統自己的處理能力不能慢或不能掛。

• 消息投遞的三種方式：

1. 推
2. 拉
3. 推拉結合

Kafkia 面向的場景是：日誌的分析，處理 及 統計功能，它主要更關注於日誌拉取的吞吐量。而不太關注數據拉取的延遲，它採起的主要地消息投遞模式是拉模型。

ONS採起的是推拉結合的模式（長輪詢的模式）

推送策略：

隊列中收到消息後會主動推送給訂閱者，訂閱者返回一個ack，這樣的數據延遲會比較小，而且訂閱者比較輕量，主須要關注接收和處理消息就能夠了。

拉取策略：拉消息是訂閱者定時向消息服務器拉取消息，這樣消息服務器壓力會比較大，而且延遲相對來講會比較大，拉消息模式關注的主要是吞吐量。

推拉結合：當隊列中收到發佈者發送的消息以後，會給消息訂閱者一個通知，我這邊收到消息了，而後訂閱者會向消息中間件的服務器拉取消息。——缺點，拉取消息自己的交互次數會變得很是多。

另外一種方案：消息的訂閱者在主動拉取消息的同時，ONSServer 會 hold住你拉的請求，知道有消息之後會返回給你。以這種方式能夠實現 以拉取的模式（策略）來實現很是及時的通信。