图1 在线开盘系统整体架构
下面具体介绍一下在线开盘系统的技术细节：
总体方案如下：从前端开始 ， 在各层级模块进行限流处理 ， 对单个用户的请求频率作限制 ， 进行多级校验 ， 及时丢弃?效请求；前端和后端联合进行请求数据校验 ， 防止请求作弊 ， 减小服务器负载 。具体如下：
客户登录时 ， 在nginx层经过会lua脚本的防刷处理 ， 对登录接口访问频率作限制 ， 防止登录接口请求频率过高导致的数据库崩溃；同时 ， 前端读取当前时间戳 ， 与用户ID进行拼接后进行Hash运算 ， 生成token ， 存储在Redis缓存以及Cookie中 ， 并返回Cookie给客户端浏览器；该token作为用户的身份校验凭证 ， 每次发起抢购请求时 ， 后端都会校验该token ， 判断前后端是否匹配 ， 若不匹配则拒绝客户端请求 ， 并提示用户重新登录；从图2可以看出 ， 当用户从其他设备重新登录时 ， 会生成最新的token覆盖旧token ， 原设备Cookie中存储的token则失效 。这样保证了C端用户只能在单台设备上进行登录 ， 减少了用户通过多台设备同时参与秒杀的可能 。
图2 前端限制单台设备登录的示意图
客户抢购过程中 ， 从多个层级模块对认购请求进行限流削峰处理 ， 整体流程图如图3所示 ， 包括如下几个步骤：
1.前端控制用户点击抢购按钮的频率 ， 每一次点击之后都出现一个蒙层或倒计时 ， 对抢购按钮禁用一段时间 ， 之后才允许C端用户再次点击按钮发起抢购请求；
图3 抢购流程图
2.服务器端对来自于客户端的请求做合法性校验 ， 判断用户token是否有效 ， 判断请求参数中的签名值是否正确（即图4中后端模块第二步） ， 判断活动是否已经开始 ， 从缓存获取客户信息 ， 校验用户是否具有抢购资格 ， 对不合法的请求全部拒绝并返回失败结果；
3.获取用户频率锁 ， 若成功获取 ， 则进行后续判断 ， 否则认为用户访问频率超限 ， 使缓存中存储的用户token失效 ， 给客户返回失败结果 ， 并提醒用户重新登录；
4.获取对应房源的分布式锁 ， 若获取失败 ， 则认为该房源已售 ， 返回失败结果；若获取商品锁成功 ， 则认为本次抢购成功 ， 返回成功结果；
5.客户抢购成功后 ， 请求数据会推送给Kafka消息队列 ， 并进行后续处理；
6.消费Kafka队列中的记录 ， 发送抢购成功的通知短信给用户 ， 将成交数据持久化到数据库 ， 通过WebSocket实时传递成交记录给B端投屏页面 。
在这个过程中 ， 用户频率锁和商品锁都是通过Redis分布式非阻塞锁实现 ， 只尝试一次 ， 不阻塞等待 。前端所使用的静态资源文件 ， 通过CDN获取 ， 避免对业务服务器的直接访问；服务器热点数据 ， 如活动描述、活动须知等数据 ， 存储在进程本地缓存中 ， 以此提高程序响应速度 。
图4 前后端校验防作弊方法流程图
抢购成功之后使用Kafka消息队列异步进行后续处理 ， 包括写入订单到数据库、发送抢购成功的提醒短信、推送实时消息给B端前台投屏页等操作 ， 既减少了客户的等待时百思特网间百思特网 ， 也减轻了服务器和数据库的平均压力 。
推荐阅读
- 剑网三 宠物 攻略 灰狐
- 一方木材怎么算，一方是怎么计算的
- 家装博古架效果图大全，博古架图片大全室内
- 如何学会分析问题 如何解决问题
- 怎么把Word文字快速转成表格
- 用康王洗头发正确方法 - 康王一停就又有头屑
- 其实焦虑症很容易好 如何解决过度焦虑
- 德国曼全新一代tgs卡车四驱技术
- 手工制作简易小灯笼 「灯笼制作手工制作大全」