redis - 一個領券的隊列問題

Question

用戶在領券頁面點選領取後，呼叫後台服務介面A，介面A將該領取操作寫入佇列：

// 写入队列
addQue(....)

然後呢，寫入隊列後緊接著循環讀取隊列嗎？使用者還在等待是否領取成功的結果。

Answer 1

https://redis.io/topics/pubsub

redis支援發布/訂閱

Answer 2

我所知的是在領券成功頁裡做一個輪詢（或websocket配合redis pubsub更好的體驗）來獲取最終結果。

Answer 3

本身的產品需求是同步的(結果同步回)，佇列主要是用來實現非同步，例如訂單、通知等。
如果實在要用到隊列來模擬同步結果，就只能再單獨取得領券的結果了。

"redis支援發布/訂閱"：使用這種模式存在以下一些問題

1. 需要定義的channel太多，如果復用1個channel的話，訂閱者需要過濾的message很多，而且需要有個文本協議(publish 只支持文本)

2. 服務提交請求後，收到回覆前掛掉了，領券資訊就會遺失

建議如下：

1. 最好的方法是把非同步請求修改同步請求

2. 不然，可以考慮把請求的處理結果放在一個hash(id->結果)

Answer 4

如果是異步，領取結果不是透過領取請求返回的話，如果用樓上說的ajax去獲取領取結果，那不是要ajax循環發起請求，因為你不知道領取結果什麼時候會出來，你只能去輪詢，只要涉及到輪詢，那麼問題就來了，輪詢間隔過短，伺服器壓力就會很大，輪詢間隔長，那麼通知領取結果就會有延遲。

如果不想做同步，可以用websocket啊，雙方通信，隨時交換數據，沒有任何延遲。
或直接用 SSE（Server-sent Events）推送，WebSocket是雙向的，SSE是單向的，對於推播訊息足夠了。

服务器推送事件（Server-sent Events），简称SSE，是 HTML 5 规范中的一个组成部分，可以用来从服务端实时推送数据到浏览器端。相对于与之类似的 COMET 和 WebSocket 技术来说，服务器推送事件的使用更简单，对服务器端的改动也比较小。对于某些类型的应用来说，服务器推送事件是最佳的选择。

SSE 連結SSE

至於服務端內部的操作流程可選方案那就多了，非同步的只要中間加上一層cache或mq都能實現非同步操作。例如zmq，redis的pub/sub等等等等。

Answer 5

求知。 。 。 。