京麦微信小程序圣诞抽奖项目总结
您目前处于:架构&实践  -  案例分析  2017年12月27日  阅读 1409

该项目的主要功能特点是类似于一个秒杀系统,存在短时间高并发问题,在拿到项目需求后,我们对该项目进行了两版程序设计,初始版本中,在高并发的情况下,无法保持数据的正确性,存在可能一个用户被抽中多次的问题,以及对数据库频繁的写操作会降低程序运行效率。

在第二版中,我们着重对两点问题进行了优化,摒弃了直接查询、更新数据库的思路,转用了Redis进行缓存处理,很好的解决了第一版中的两大痛点。

下面将对该项目程序设计的整体思路进行阐述。


项目需求

该项目是一个和微信小程序结合的抽奖活动,主要的业务需求如下:

1. 普通用户部分:

1) 手机扫二维码或者点击链接进入小程序

2) 点击“点我送礼”按钮,随机匹配送礼用户

3) 获得匹配结果,将礼物送给匹配用户

2. 管理员部分:

1) 上传用户数据

2) 进行数据初始化操作

3) 查看抽奖结果


初始数据库设计

根据项目需求,首先进行了初始版本的数据库设计,除了基本数据字段,我们在这里另外添加了两个标志字段user_in和user_out,分别代表该用户收到礼物对应ERP账号和送出礼物对应的ERP账号,用来记录当前用户收到了谁的礼物和将礼物送给了谁。

表结构如下图所示:


初始流程

在初始版本中,用户和管理员的主要程序流程如下图所示。

在用户流程中,从前端传进来的数据并不是用户手机号,而是jsCode,vi,和croptedData这三个参数,在Controller层接收以后调用微信小程序接口根据jsCode获取SessionKey,再进行解密操作取得用户手机号,传入业务层。

在管理员流程部分,目前只支持批量导入,并且使用事务处理写入数据库的过程,要么全部成功,要么全部失败。


初始版本存在的问题

在初始版本设计中,用户每进行一次抽奖活动,后端就需要对数据库进行读写操作,存在严重的并发问题:

1. 每进行一次抽奖活动,都要从数据库中查询数据,效率低下

2. 存在并发问题:从数据库中产生的未中奖用户列表无法与数据库数据保持一致,有可能导致一个用户中奖多次

3. 更新数据库操作要进行加锁处理,降低效率


优化思路

针对以上问题,我们在第二版中,针对抽奖算法做出了调整,摒弃了直接从数据库查询、更新数据的想法,改用Redis进行数据缓存,利用Redis中的List结构存储未中奖用户,用户进行抽奖活动时,从list中pop出中奖用户返回给前端,从而很好地解决了并发问题。而且整个流程只有在给前端返回中奖用户信息时才会对数据库进行读操作,不需要加锁,不会产生脏读问题,保证了数据安全。

主要优化思路如下:

1. 管理员端只导入基本数据,取消user_in和user_out字段

2. 将用户手机号初始化两份到JimDB中,在初始化时进行无序存储

1) List:存放未中奖用户手机号

2) Hash:存放用户手机号<当前用户手机号,中奖用户手机号>

3. 从List中lpop出手机号作为中奖用户,更新Hash中当前用户value为中奖用户手机号

4. 返回中奖用户信息,在管理员端可以进行结果查询


初始化流程

初始化流程如图所示:


抽奖流程

抽奖流程如图所示:


不足之处

在正式上线使用后,也暴露出很多不足之处,目前该项目还未实现的功能模块如下:

1. 查看结果模块的完全实现(目前只能查看Hash中的数据,没用过滤分析功能和对数据的二次加工处理)

2. 单独修改用户信息(目前只支持批量上传,无法修改)

3. 锁定未抽奖用户进行提示(目前没有这个功能的实现


本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/肖依云)

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

赞赏支持
分享到: 更多
作者  肖依云  发布于 2017年12月27日  阅读 1409
该项目的主要功能特点是类似于一个秒杀系统,存在短时间高并发问题,在拿到项目需求后,我们对该项目进行了两版程序设计,初始版本中,在高并发的情况下,无法保持数据的正确性,存在可能一个用户被抽中多次的问题,以及对数据库频繁的写操作会降低程序运行效率。在第二版中,我们着重对两点问题进行了优化,摒弃了直接查询、更新数据库的思路,转用了Redis进行缓存处理,很好的解决了第一版中的两大痛点。下面将对该项目程序...
作者 李振发 发布于 2017年07月28日  阅读 2452
京麦消息中心是京麦平台核心业务之一,负责向京麦平台商家用户提供消息推送,ISV消息订阅,以及消息追踪,消息监控,消息统计等功能。京麦消息中心(以下简称MC)经过4个618的洗礼,技术及业务模型日趋成熟和稳定,本文将为您揭开京麦消息中心业务模型及涉及到的技术点内幕。首先简单聊下整体架构,整个消息中心承载业务系统消息,资讯类消息,其他类消息。业务系统消息首先经Anycall系统接入,然后分发给MC。资...
作者  张松然  发布于 2017年01月06日  阅读 355
# 背景随着大家对系统稳定性愈加重视,提高线上系统稳定,加强代码设计、编码等评审工作,成为京麦团队在本次迭代开展的一项重要工作。但是,本次迭代对设计评审过程中暴露出的问题,大家在本次迭代的回顾会议上也进行了思考和建议,从如何提高评审效率,总结出了有建设性的意见。同时,在本次迭代中有一些时间点特质的故事出现严重延期,让别人对团队的能力产生了质疑,大家在本次迭代的回顾会议上也是痛定思痛,认真考虑和提议...
作者  张松然  发布于 2016年10月19日  阅读 2597
简介—— 从全视角以时间线的方式,介绍京麦开放平台的发展演变和架构体系,重点讲解京麦HTTP网关和京麦TCP平台,如何实现API快速接入承载海量HTTP请求调用,以及如何建立TCP全双工的长链接会话通道;深度剖析基于Zookeeper的网关Register Center、基于Netty的平台TCP长链接Container、基于ElasticSearch、HBase的消息Search Engine等...
作者 Frank 发布于 2016年04月20日  阅读 748
Service Tenet1. Service in the Open Platform (include ISV), to provide high performance and stable interface, build the Delicacy Service.2. Service in the Vender, to build high-quality security boutiq...