京麦微信小程序圣诞抽奖项目的架构设计

来源： linkedkeeper.com
作者：肖依云，热爱技术，熟悉Struts2、Spring、Spring MVC等常用开源框架，对开发分布式、高并发系统有一定的学习和研究。正在学习大数据和AI相关技术，梦想是把代码写成诗。
责编：钱曙光（qianshg@csdn.net）

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

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

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

项目需求

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

1. 普通用户部分：

手机扫二维码或者点击链接进入小程序
点击“点我送礼”按钮，随机匹配送礼用户
获得匹配结果，将礼物送给匹配用户

2. 管理员部分：

上传用户数据
进行数据初始化操作
查看抽奖结果

初始数据库设计

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

表结构如下图所示：

初始流程

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

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

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

初始版本存在的问题

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

每进行一次抽奖活动，都要从数据库中查询数据，效率低下
存在并发问题：从数据库中产生的未中奖用户列表无法与数据库数据保持一致，有可能导致一个用户中奖多次
更新数据库操作要进行加锁处理，降低效率

优化思路

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

主要优化思路如下：

管理员端只导入基本数据，取消user_in和user_out字段
将用户手机号初始化两份到JimDB中，在初始化时进行无序存储
- List：存放未中奖用户手机号
- Hash：存放用户手机号<当前用户手机号，中奖用户手机号>
从List中lpop出手机号作为中奖用户，更新Hash中当前用户value为中奖用户手机号
返回中奖用户信息，在管理员端可以进行结果查询

初始化流程

初始化流程如图所示：

抽奖流程

抽奖流程如图所示：

不足之处

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

查看结果模块的完全实现（目前只能查看Hash中的数据，没用过滤分析功能和对数据的二次加工处理）
单独修改用户信息（目前只支持批量上传，无法修改）
锁定未抽奖用户进行提示（目前没有这个功能的实现

相关阅读：《京东11.11：京麦服务市场交易平台备战实践》

1月13日，SDCC 2017之数据库线上峰会即将强势来袭，秉承干货实料（案例）的内容原则，邀请了来自阿里巴巴、腾讯、微博、网易等多家企业的数据库专家及高校研究学者，围绕Oracle、MySQL、PostgreSQL、Redis等热点数据库技术展开，从核心技术的深挖到高可用实践的剖析，打造精华压缩式分享，举一反三，思辨互搏，报名及更多详情可点击此处查看。