使用異步隊列連接http請求/響應模型

Question

將同步http請求/響應模型與基於異步隊列的模型連接的好方法是什麼？

當用戶的HTTP請求到達時，它會生成一個進入隊列的工作請求（在這種情況下爲beanstalkd）。其中一名工作人員提出要求，完成工作並準備迴應。

隊列模型不是請求/響應 - 只有請求而不是響應。所以問題是，我們如何最好地將響應反饋回HTTP世界並回饋給用戶？

思路：

1. Beanstalkd支持重量輕的主題或隊列（它們調用它們管）。我們可以爲每個請求創建一個管道，讓工作人員在該管道上創建消息，並使http進程坐在管道上等待響應。不要特別喜歡這個，因爲它具有圍繞內存的apache進程。

2. 讓http客戶端輪詢響應。用戶的初始HTTP請求會啓動隊列中的作業並立即返回。客戶端（用戶的瀏覽器）定期輪詢響應。在後端，工作人員將其響應放入memcached，我們將nginx連接到memcached，因此輪詢重量輕。使用Comet。與第二個選項類似，但用更加奇特的http通信來避免輪詢。

我傾向於2，因爲它很容易，很好知道（我還沒有使用過彗星）。我猜這可能還有一個更好的明顯的模型，我沒有想到。你怎麼看？

Answer 1

這裏的how to implement request-response efficiently on JMS這可能是有益的（雖然Java/JMS爲中心）。總的想法是爲每個客戶端/線程創建一個臨時隊列，然後使用correlationIDs將請求與回覆關聯起來。

Answer 2

我期望實現一個Beanstalkd和memcached系統，以便在請求之後運行多個進程 - 在此情況下，用戶登錄時查找信息（用戶等待的消息數量）。信息存儲在Memcached中，然後讀回下一頁加載。

雖然不知道你正在做什麼任務，但要說明需要做什麼或怎麼做並不那麼容易。然而，選項＃2是最簡單的，而且這可能是您所需要的全部 - 取決於您將什麼推回給工人。

Answer 3

輪詢是簡單的解決方案;彗星是更有效的解決方案。你已經釘上了它:)

我個人喜歡彗星（儘管我有點偏頗，因爲我幫忙寫了WebSync），但它很好地讓你的客戶訂閱一個頻道，並在你的服務器進程準備就緒時得到消息。像冠軍一樣工作。