这是一个创建于 1887 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近接了一个比较老的系统，营销系统使用的，主要是用来活动现场发红包。
现在有个需求，活动现场，主持人在台上点击发红包按钮，台下进入小程序（公众号）的签到用户在小程序（公众号）界面会自动弹出红包，用户点击领取。
感觉这个功能有点像博客的消息提醒或者实时变化的未读邮件数，初步的想法是用户页面不停地发接口查询状态，状态改变后就出现红包，但是感觉不是很好的方法。
想请教下应该怎么实现。感谢！
框架用的 spring MVC 。
 | 1 gy134340 2021 年 2 月 23 日 免费要技术方案？ |
 | 3 mokeyjay 2021 年 2 月 23 日 轮询就已经是很好的方法了 |
 | 4 mauve PRO  1 websocket |
 | 6 Kasumi20 2021 年 2 月 23 日 1 websocket |
 | 10 Amayadream 2021 年 2 月 23 日 进入页面时主动查询 + 定时轮询查询即可，这种需求使用轻量级的解决方案即可，没必要引入复杂度。 |
 | 11 litchinn 2021 年 2 月 23 日 觉得轮询 low 的话用 rabbitmq 吧 |
 | 12 keepeye 2021 年 2 月 23 日 现场多少人？算好轮询请求间隔时间，区区并发，问题应该不大吧？ |
 | 13 zjsxwc 2021 年 2 月 23 日 2000 人抢红包，带宽要买大点的。 保守点 1 一个请求 2KByte，1 秒内 2000 个请求就是 4MByte，也就是 32M 带宽了。 |
 | 14 markgor 2021 年 2 月 23 日 1 是不是想复杂了呢.... 主持人在台上点击发红包按钮->小程序（公众号）界面会自动弹出红包，用户点击领取。 精简下流程... 用户签到(小程序 /公众号)->记录 openID |这一步没多大并发和流量 主持人点发红包->后台接收请求|根据几率随机取出数据，调用微信红包 api，发送红包；没中的可以发送安慰通知。 这样流量并发问题就可以甩手微信了。 |
 | 15 imdong 2021 年 2 月 23 日 via iPhone 1 14 楼优化版本 用户签到记录下来后，主持人点击发红包时，就直接将用户分为可中奖用户和未中奖用户，并且更新 CDN 静态文件为开奖中(或中奖用户列表)。 客户端签到后，进入小程序轮训位于 CDN 的静态文件，记得加时间戳来过缓存，变更后客户端按钮更新。 至于抽奖过程，用户点击后决定，还是根据列表直接给假动画，都可以。 |
 | 16 Tokin 2021 年 2 月 23 日 1 |
 | 18 BarryAllen 2021 年 2 月 23 日 商量一个具体时间 等到规定时间假装点一下按钮 舌战去吧 |
| 19 markgor 2021 年 2 月 23 日 @nobuger 你还没理解我的意思。 建议你可以看看微信商户平台-微信红包 API 你只需要 1 、签到->记录用户的 OPENID ； 2 、然后主持人点开始->后端随机获取中奖的 OPENID->调用微信红包 API ； 用户侧的体验是： 中奖用户：公众号会下发一个红包，点击打开后的效果和你平时发红包给别人的效果一致。 未中奖：可以适当发送“xxxx，再接再厉” 这样你只需要完成 3 个功能，1 个界面即可了。 |
| 20 markgor 2021 年 2 月 23 日 另外，你确定你用小程序做个红包界面，审核能通过？ 还是说你打算用隐藏大法来通审？被举报 /发现是直接封主体喔.... 搞个活动无非就是为了 吸粉 /打品牌 /增加现场活跃 1 、如果你是要吸粉，签到已经吸粉了，没必要要求用户一直打开 H5 或小程序。 2 、如果你是要搞小程序使用量，签到的时候不就已经搞到使用人数了吗。 3 、打品牌 /加活跃，客户从不关心有多少是你自己做的，只关心用起来爽不爽有没中奖。 所以上述方案基本能用最少的资源去薅微信的处理能力羊毛。 上面方案唯一耗时的就是 从签到处随机取出 中奖者的 OPENID，这部分用 redis 随机取出即可了。 然后网络 /IO 消耗的部分就是 发送 openID 到微信红包的 API，java 我不清楚，你中奖数量我也不清楚，可以考虑异步发送过去微信红包 API 。如返回取关 /红包发送失败（未实名）之类的错误，重新在 redis 上随个出来补上就行了。 |
 | 21 ajaxfunction 2021 年 2 月 23 日 用 websocket 就是纸上谈兵，理论没问题，实际坑死。 活动现场人数很多，无论是 wifi 或 4g 网络抖动都很严重，websocket 是长连接应用，一旦短线务必重连，又的走一遍权限认证，各种校验流程，负载不比轮询低 轮询呢这次请求错误，那就继续请求呗，session 和 cookie 又不会丢。 redis 里放一个活动状态，默认是关，主持人点了发送，活动状态改成开 你觉得不好的方法，反而是最优的设计，只不过在 UI 界面上可以用障眼法来降低负载，比如滑动拖动点击元素来进入活动增加趣味性也避免并发 这种现场实时系统，简单稳定是最重要的，否则就是事故，轻则挨批，重则砸场子。 |
 | 22 vindurriel 2021 年 2 月 24 日 via iPhone 最小成本且最受信任的解决方案是 登录鉴权后展示群二维码 进群 管理员在群里发包 如果自己做抽奖 即使费劲解决了并发的问题 所有没中的人都会怀疑有黑幕 |
Select Language