用户在领券页面点击领取后,调用后台服务接口A,接口A将该领取操作写入队列:
// 写入队列
addQue(....)
然后呢,写入队列后紧接着循环读取队列吗?用户还在那等着是否领取成功的结果。
过去多啦不再A梦2017-04-28 09:06:36
本身的产品需求是同步的(结果同步返回),队列主要是用来实现异步,比如订单、通知等。
如果实在要用到队列来模拟同步结果,就只能再单独获取领券的结果了。
"redis支持发布/订阅":使用这种模式存在下面一些问题
需要定义的channel太多,如果复用1个channel的话,订阅者需要过滤的message很多,而且需要有个文本协议(publish 只支持文本)
服务提交请求后,收到回复前挂掉了,领券信息就会丢失
建议如下:
最好的办法是把异步请求修改同步请求
不然,可以考虑把请求的处理结果放在一个hash(id->结果)
高洛峰2017-04-28 09:06:36
如果是异步,领取结果不是通过领取请求返回的话,如果用楼上说的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等等等等。