用戶在領券頁面點選領取後，呼叫後台服務介面A，介面A將該領取操作寫入佇列：
// 写入队列 addQue(....)
然後呢，寫入隊列後緊接著循環讀取隊列嗎？使用者還在等待是否領取成功的結果。
小伙看你根骨奇佳，潜力无限，来学PHP伐。
https://redis.io/topics/pubsub
redis支援發布/訂閱
我所知的是在領券成功頁裡做一個輪詢（或websocket配合redis pubsub更好的體驗）來獲取最終結果。
本身的產品需求是同步的(結果同步回)，佇列主要是用來實現非同步，例如訂單、通知等。 如果實在要用到隊列來模擬同步結果，就只能再單獨取得領券的結果了。
"redis支援發布/訂閱"：使用這種模式存在以下一些問題
需要定義的channel太多，如果復用1個channel的話，訂閱者需要過濾的message很多，而且需要有個文本協議(publish 只支持文本)
服務提交請求後，收到回覆前掛掉了，領券資訊就會遺失
建議如下：
最好的方法是把非同步請求修改同步請求
不然，可以考慮把請求的處理結果放在一個hash(id->結果)
如果是異步，領取結果不是透過領取請求返回的話，如果用樓上說的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等等等等。
求知。 。 。 。
https://redis.io/topics/pubsub
redis支援發布/訂閱
我所知的是在領券成功頁裡做一個輪詢（或websocket配合redis pubsub更好的體驗）來獲取最終結果。
本身的產品需求是同步的(結果同步回)，佇列主要是用來實現非同步，例如訂單、通知等。
如果實在要用到隊列來模擬同步結果，就只能再單獨取得領券的結果了。
"redis支援發布/訂閱"：使用這種模式存在以下一些問題
需要定義的channel太多，如果復用1個channel的話，訂閱者需要過濾的message很多，而且需要有個文本協議(publish 只支持文本)
服務提交請求後，收到回覆前掛掉了，領券資訊就會遺失
建議如下：
最好的方法是把非同步請求修改同步請求
不然，可以考慮把請求的處理結果放在一個hash(id->結果)
如果是異步，領取結果不是透過領取請求返回的話，如果用樓上說的ajax去獲取領取結果，那不是要ajax循環發起請求，因為你不知道領取結果什麼時候會出來，你只能去輪詢，只要涉及到輪詢，那麼問題就來了，輪詢間隔過短，伺服器壓力就會很大，輪詢間隔長，那麼通知領取結果就會有延遲。
如果不想做同步，可以用websocket啊，雙方通信，隨時交換數據，沒有任何延遲。
或直接用 SSE（Server-sent Events）推送，WebSocket是雙向的，SSE是單向的，對於推播訊息足夠了。
SSE 連結SSE
至於服務端內部的操作流程可選方案那就多了，非同步的只要中間加上一層cache或mq都能實現非同步操作。例如zmq，redis的pub/sub等等等等。
求知。 。 。 。