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

原创 2017年12月29日 11:17:51

来源: 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,再进行解密操作取得用户手机号,传入业务层。

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

这里写图片描述

初始版本存在的问题

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

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

优化思路

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

主要优化思路如下:

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

初始化流程

初始化流程如图所示:

这里写图片描述

抽奖流程

抽奖流程如图所示:

这里写图片描述

不足之处

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

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

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


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

版权声明:本文为博主原创文章,未经博主允许不得转载。

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

该项目的主要功能特点是类似于一个秒杀系统,存在短时间高并发问题,在拿到项目需求后,我们对该项目进行了两版程序设计,初始版本中,在高并发的情况下,无法保持数据的正确性,存在可能一个用户被抽中多次的问题,...
  • ruanchengmin
  • ruanchengmin
  • 2017年12月29日 16:43
  • 43

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

该项目的主要功能特点是类似于一个秒杀系统,存在短时间高并发问题,在拿到项目需求后,我们对该项目进行了两版程序设计,初始版本中,在高并发的情况下,无法保持数据的正确性,存在可能一个用户被抽中多次的问题,...
  • qq_40267706
  • qq_40267706
  • 2017年12月29日 16:45
  • 70

微信营销平台架构设计初解

最近做了点微信移动营销平台的架构和实现,然后大体画了几张图来说明其架构,贴上来分享一下,不好之处多多指正:...
  • liulangdeyue
  • liulangdeyue
  • 2014年12月04日 16:31
  • 848

万亿级调用下的优雅——微信序列号生成器架构设计及演变(上)

微信在立项之初,就已确立了利用数据版本号实现终端与后台的数据增量同步机制,确保发消息时消息可靠送达对方手机,避免了大量潜在的家庭纠纷。时至今日,微信已经走过第五个年头,这套同步机制仍然在消息收发、朋友...
  • tengxy_cloud
  • tengxy_cloud
  • 2016年11月14日 10:17
  • 334

万亿级调用下的优雅——微信序列号生成器架构设计及演变(下)

上一篇文章介绍了seqsvr的原型,这篇会简单地介绍下seqsvr容灾架构的演变。我们知道,后台系统绝大部分情况下并没有一种唯一的、完美的解决方案,同样的需求在不同的环境背景下甚至有可能演化出两种截然...
  • tengxy_cloud
  • tengxy_cloud
  • 2016年11月14日 10:15
  • 204

转:微信序列号生成器架构设计及演变(下)

版权声明:本文由曾钦松原创文章,转载请注明出处:  文章原文链接:https://www.qcloud.com/community/article/201 来源:腾云阁 https://www...
  • apple_operation
  • apple_operation
  • 2016年11月24日 18:33
  • 258

万亿级调用系统:微信序列号生成器架构设计及演变

原文:https://www.sdk.cn/news/3844 作者介绍 曾钦松,微信高级工程师,目前负责微信后台基础服务、朋友圈后台等开发优化,致力于高可用高性能后台系统的设计与研发。2011年...
  • mrdothe
  • mrdothe
  • 2016年06月19日 15:29
  • 653

高并发秒杀系统架构设计 · 抢购、微信红包、一元夺宝

秒杀业务在各业务中已然非常流行,这里我将互联网行业中的秒杀定义为:在非常短的时间内,将一件商品分成多份进行购买的行为。微信抢红包、一元夺宝、双11大促抢购等业务本质上都可视作秒杀业务。而最近大热的抢红...
  • u013322876
  • u013322876
  • 2017年03月07日 12:54
  • 1160

微信红包的架构设计简介

背景:有某个朋友在朋友圈咨询微信红包的架构,于是乎有了下面的文字(有误请提出,谢谢)概况:2014年微信红包使用数据库硬抗整个流量,2015年使用cache抗流量。 微信的金额什么时候算? 答:微...
  • qq_14927217
  • qq_14927217
  • 2017年04月28日 20:18
  • 394

微信序列号生成器架构设计及演变

一、摘要 微信在立项之初,就已确立了利用数据版本号实现终端与后台的数据增量同步机制,确保发消息时消息可靠送达对方手机,避免了大量潜在的家庭纠纷。时至今日,微信已经走过第五个年头,这套同步机制仍然...
  • chenhaifeng2016
  • chenhaifeng2016
  • 2017年01月11日 17:06
  • 506
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:京麦微信小程序圣诞抽奖项目的架构设计
举报原因:
原因补充:

(最多只允许输入30个字)