在并發(fā)情況下, 允許多個消費者消費同一個消息隊列, 并保證消息被消費的基本語義(Kafka的模式). 通過消費者之間對消息進行收取競爭, 來保證整體負載的平衡.
問題
分布式環(huán)境下的程序往往對下層的服務有大量的需求. 由于網絡的不穩(wěn)定性等, 我們往往希望底層的服務能夠分布在不同的機器上, 同時去響應需求并異步返回結果.
在真實引用中, 往往業(yè)務需求和時間有很大的關系. 如每年雙11, 雙12, 大量的請求會涌入電商服務. 每天晚上10點到12點, 對于歐洲足球聯賽的需求會擠壓底層服務等等. 我們需要對能夠接受的請求, 進行削峰填谷. 避免大量請求和鏈接淹沒整個底層基礎架構
解決
image.png
這個設計模式是Kafka使用的, 內部就不再累述了, 可以直接閱讀Kafka的設計文檔
問題
消息順序 隊列是否需要維護進來的消息的先后順序, 是一個需要權衡的點. 像Kafka并不保證全局消息的順序性, 帶來的是更高的吞吐
彈性服務 是否需要在線橫向擴容, 是否支持故障節(jié)點的重啟和fail-over
檢查有毒信息 在經典的拜占庭將軍問題中, 有一個概念是poison message, 部分將軍可能是判斷節(jié)點. 隊列系統(tǒng)是否需要識別這些有害的信息, 并把它們自動剔除掉是一個權衡點.
結果處理 很多分布式隊列系統(tǒng), 支持一個基本概念是future, 異步的把處理結果返回到消息的發(fā)送方. 這是一個需要注意的點.
消息可靠性 在分布式隊列系統(tǒng)里, 需要保證消息不會丟失, 可靠性的設計是需要考慮的
