抽奖型电商活动后台技术实践
2017-03-22 12:43
323 查看
背景
在某互联网金融平台的会员体系建设中,用户积分是很重要的一环。用户可以在交易、登录、签到和兑换过程中,按照后台设置的规则获得积分。这些积分又可以参与到各种活动,其中抢购类型的活动,由于其参与门槛低,结果不确定性高,深受用户的喜爱。
活动形式
交互流程
CurrentReq
当前活动收到的有效抽奖活动序列号,每收到一个抽奖请求原子自增。
WinNumber
为保证如10,000次抽奖一定能抽走10个奖品的需求(每次概率计算不能保证一定抽走10个奖品),后台为每次活动设置的中奖号码位置,保证抽到10,000次的时候,10个奖品已经抽完。
{ProductId}_{UserId}
用户在该活动下已经参与的抽奖次数,为保证公平起见,单个用户在单个活动下的抽奖次数受限。
运维保障措施
[b]Nginx限流[/b]在带宽耗光,连接池打满,CPU冲高的情况下,对请求来源IP级别限流。
会误伤某几个IP下的一批正常用户,但是保证了其他IP用户的服务可用性。
抽奖活动专用泳道
在七层负载上,根据抽奖请求特定的URL形式,将服务指定分发到某一组服务器上。剩余的服务器不处理抽奖请求,保证其他业务的正常运行。
活动期间临时服务器扩容
活动量太大,服务器还是的扩容。前提是服务需要做到无状态,可以使用集中式的Session,数据库存储上下文信息。
数据库垂直拆分
将抽奖相关的DB从核心库拆分到独立实例中,避免因为抽奖耗光数据库资源,而影响其他金融交易活动。
静态资源处理
JavaScript/CSS/JPEG/HTML等静态资源,分发到CDN上去,请求消耗的带宽落到CDN上。
启用终端缓存静态资源, last-modified-at/expired-at等HTTP原始信息定义。
存在的问题及改进方案
自动脚本刷单用户限流在自增用户单词活动抽奖次数的同时,记录服务器端收到用户下单请求的时间。
后续用户发送抽奖请求时,根据最近几次抽奖请求的时间间隔,判断是否脚本刷单。
抽奖请求序列REQ持久化
如果Redis 在活动期间宕机,其中关键的CurrentReq会丢失,恢复的时候从数据库中记录的抽奖请求中恢复。
支付能力检查通过后支付又失败的问题
用户的支付能力一直在变,可以在同步请求中完成用户支付扣减积分后,才去自增CurrentReq以及创建抽奖订单。
为保证响应速度,要求支付服务做得
相关文章推荐
- 竞拍类型电商活动技术实践
- 推荐一本今年八月份的新书《后台开发:核心技术与应用实践》,作者腾讯资深后台开发工程师徐晓鑫
- 《后台开发核心技术与应用实践》(四)
- 自然语言处理在电商的技术实践
- 2017微软 MVP 数据实践技术活动日(北京站)
- “双十一”背后的隐形战场:电商后台IT技术大检阅
- 腾讯技术工程 | QQ相册后台存储架构重构与跨IDC容灾实践
- 《后台开发核心技术与应用实践》(二)
- 用Elasticsearch构建电商搜索平台,一个极有代表性的基础技术架构和算法实践案例[转]
- APP后台开发运维与架构实践 2 : App后台基础技术
- 做后台开发用到的技能都在这儿——《后台开发:核心技术与应用实践》
- C++小结(二)(《后台开发核心技术与应用实践》第二章笔记)
- 【技术分享】京东电商广告和推荐的机器学习系统实践
- 《后台开发核心技术与应用实践》(三)
- 后台开发:核心技术与应用实践(边写代码边读书才是最好的学习方式)
- App后台开发运维和架构实践学习总结(1)——App后台核心技术之用户验证方案
- 地址已经被使用——Address already in use(纠正《后台开发:核心技术于应用实践》书中的错误)
- 智能人机交互在电商领域的技术实践 ——阿里小蜜
- APP后台开发运维与架构实践 3 : App后台核心技术