What I know is to do a poll on the coupon collection success page (or use websocket with redis pubsub for a better experience) to get the final result.
The product requirements are synchronous (results are returned synchronously), and the queue is mainly used to achieve asynchronous implementation, such as orders, notifications, etc. If you really want to use a queue to simulate the synchronization results, you can only obtain the coupon results separately.
"Redis supports publish/subscribe": There are some problems with using this model
There are too many channels that need to be defined. If one channel is reused, subscribers will need to filter a lot of messages, and a text protocol is required (publish only supports text)
After submitting a request to the service, if it hangs up before receiving a reply, the coupon information will be lost
The suggestions are as follows:
The best way is to modify the asynchronous request into a synchronous request
Otherwise, you can consider putting the request processing results in a hash (id->result)
If it is asynchronous and the collection result is not returned through the collection request, if you use ajax as mentioned above to get the collection result, it does not require ajax to initiate the request in a loop, because you don’t know when the collection result will come out, you can only take the turn As long as polling is involved, problems will arise. If the polling interval is too short, the server will be under great pressure. If the polling interval is long, there will be a delay in notifying and receiving the results.
If you don’t want to do synchronization, you can use websocket. The two parties can communicate and exchange data at any time without any delay. Or use SSE (Server-sent Events) to push directly. WebSocket is two-way and SSE is one-way, which is enough for pushing messages.
服务器推送事件（Server-sent Events），简称SSE，是 HTML 5 规范中的一个组成部分，可以用来从服务端实时推送数据到浏览器端。相对于与之类似的 COMET 和 WebSocket 技术来说，服务器推送事件的使用更简单，对服务器端的改动也比较小。对于某些类型的应用来说，服务器推送事件是最佳的选择。
SSE linkSSE
As for the internal operation process of the server, there are many options. As long as a layer of cache or mq is added in the middle, asynchronous operation can be achieved. For example, zmq, redis pub/sub, etc.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
https://redis.io/topics/pubsub
redis supports publish/subscribe
What I know is to do a poll on the coupon collection success page (or use websocket with redis pubsub for a better experience) to get the final result.
The product requirements are synchronous (results are returned synchronously), and the queue is mainly used to achieve asynchronous implementation, such as orders, notifications, etc.
If you really want to use a queue to simulate the synchronization results, you can only obtain the coupon results separately.
"Redis supports publish/subscribe": There are some problems with using this model
There are too many channels that need to be defined. If one channel is reused, subscribers will need to filter a lot of messages, and a text protocol is required (publish only supports text)
After submitting a request to the service, if it hangs up before receiving a reply, the coupon information will be lost
The suggestions are as follows:
The best way is to modify the asynchronous request into a synchronous request
Otherwise, you can consider putting the request processing results in a hash (id->result)
If it is asynchronous and the collection result is not returned through the collection request, if you use ajax as mentioned above to get the collection result, it does not require ajax to initiate the request in a loop, because you don’t know when the collection result will come out, you can only take the turn As long as polling is involved, problems will arise. If the polling interval is too short, the server will be under great pressure. If the polling interval is long, there will be a delay in notifying and receiving the results.
If you don’t want to do synchronization, you can use websocket. The two parties can communicate and exchange data at any time without any delay.
Or use SSE (Server-sent Events) to push directly. WebSocket is two-way and SSE is one-way, which is enough for pushing messages.
SSE linkSSE
As for the internal operation process of the server, there are many options. As long as a layer of cache or mq is added in the middle, asynchronous operation can be achieved. For example, zmq, redis pub/sub, etc.
Seeking knowledge. . . .