多主題消息隊列

我對微服務的體系結構有一個相當理論上的問題。多主題消息隊列

假設我們有兩個通過RabbitMQ彼此交互的微服務A和B。當A有問題時，它會向queue_1發送消息，並通過queue_2接收來自B的答覆（因此通信可以保持異步）。

  ------------ 
     ---> queue_1 ---> 
    A  ------------  B 
      ------------ 
     <--- queue_2  <--- 
      ------------

現在我明白了，我們將至少有4種不同的可能由A問到的問題。我的問題是什麼是最好的配置方式？

可以爲每種問題創建一個單獨的隊列對（所以它們不是混合的，它更容易確定，期望得到什麼樣的答案）？

或者它被認爲不是非常優化的，最好爲所有消息創建單個通道並在微服務中路由它們？

我會感謝有關此主題的任何種類的鏈接和信息。

來源

2017-08-28 user2957954

沒有簡單的答案;建築師的工作是徹底分析真實場景並確定合適的結構。

假設請求類型是W，X，Y和Z.爲了簡單起見，讓我們假設每個隊列有一個消費者。如果W和X快速處理，而Y和Z是漫長的操作，那麼在單個隊列中擁有所有內容意味着一旦在隊列頂部有Y或Z，那麼任何排隊的W和X將花費很多的時間排隊等待消費者完成冗長的過程。在這種情況下，最好有一個Ws和Xs排隊，另一個排隊Ys和Zs。

想想現實生活中的排隊服務，可以說超市。你有收銀臺的正常通道，並且你有那些「多達10個產品」的快車道。

要考慮的另一件事是：你是否想要對每種請求類型應用不同的策略和保證？例如，可能是Ws是每隔一段時間到達的「文檔消息」，不能丟失（需要保存到磁盤），並且必須處理，而不管它們何時被分派（不包括「），而X是始終到達的「事件消息」，必須快速處理，並且僅在幾秒鐘內有效（具有短的TTL）。這意味着他們需要不同的隊列。

也許Ys和Zs有不同的優先級：也許你必須儘快處理Zs，即使有待處理的Ys。這將再次要求不同的隊列。

如果所有請求類型的重要性都是相同的，那麼爲簡單起見，也許單個隊列會更好。

對響應隊列進行相同的討論。您可以有四個不同的請求隊列和一個響應隊列。或者四個響應隊列，或兩個...（它不必是對稱的）。

還有其他問題需要考慮，如安全性，可伸縮性和性能。

實際的路由並不是真正的挑戰，並且確定哪個處理程序應該處理每個消息類型可以通過使用消息頭很容易地幫助（您不必檢查實際的消息體來確定它的類型），這是真的就像擁有不同的隊列一樣簡單。

來源

2017-08-30 23:14:49

多主題消息隊列

回答

相關問題