这篇文章主要是对半年前开发的红包模块进行整理,把其中主要的设计思想以及具体的实现方案进行介绍,如有设计以及实现上的缺陷,或是存在漏洞,请大家批评指正!
红包功能大家都很熟悉了,那在这里就简单的对红包功能进行描述...
功能描述:红包业务主要的功能包括四部分,分别是红包发送,红包接收,红包回收,以及红包记录查询。
1)红包发送:发送者账户->红包中间层
2)红包接收:红包中间层->接收者账户
3)红包回收:红包中间层中若存在红包留存超过24小时,则将其回收,红包中间层->发送者账户
功能描述大体了解之后,那接下来就是实现方案了...
首先给出设计流程,这部分将依次对红包发送、红包接收、红包回收的流程进行分析...
1. 设计流程
首先是红包发送功能,以群红包为例,其流程图如下所示:
图1 红包发送流程图
首先,采用基于高斯分布的方法,将金额100随机的分配成8份,然后将这8份数据存入到Redis缓存队列(list)中,同时将队列的过期时间设置成24h;考虑到在抢红包的时候会出现重复抢的问题,那在这里采用的去除重复的方案是在redis缓存中维护一个已分配集合(set),集合里面存储的是已经接收过红包的用户ID;另外,在大量的用户同时抢红包的 情况,出于优化方面的考虑,为了起到一定的限流作用,同时减少对数据库的访问压力(考虑这种情况:一个时间段内,大量的用户在抢红包,在红包已经分配完的时刻之后 到来的请求,会给数据库带来一定的访问压力),那做法是在redis缓存中维护一个红包已分配完的标记(key-value),有0(为分配完)/1(已分配完)两种状态,从而起到一定的限流作用。
继缓存层面之后,接下来是数据库层面,那在MySQL中的红包发送表(account_coin_records_user_coin_package_send)中生成一条记录,同时呢在把上面经高斯分布方法得到的8份金额插入到红包分配表(account_coin_records_user_coin_package_assign)中,初始化分配标记为0(未分配),至此,红包发送的整个流程完成。
然后是红包接收功能,其流程图如下所示:
图2 红包接收流程图
红包接收者发起请求(请求中包含红包ID、请求人的用户ID)去抢红包,首先需要一系列的验证,这个验证操作要同时基于redis缓存以及mysql数据库中的数据进行 验证,主要是验证红包ID对应的红包是否存在、红包是否已经分配完了、红包是否已经过期了、红包接收者是否重复接收红包等。如果验证通过,那么这个用户是允许接收到红包的,接下来就是账户同步(红包中间层->用户账户,事务处理),若数据库操作成功,则红包接收成功,否则失败,至此,红包接收整体流程完成。
最后就是红包回收功能,其流程图如下所示:
图3 红包回收流程图
红包回收是采用定时调度策略发起的,时间间隔为5min不间断的轮询访问MySQL数据库,查询是否有待回收的红包(红包在红包中间层留存已经超过24h,且红包 未 分配完),若有需要回收的红包,这个时候基于效率方面的考虑,采用多线程方案来进行回收操作,每个红包对于一个线程,策略是:一个线程,一个请求,一个事务(这 个 方案只适用于待回收的红包个数不是很多的情况)。(注意:若需要回收的红包很多,若不断的申请线程,可能造成内存溢出问题,这时候具体问题具体分析,可以考虑生产者-消费者模式);分布式架构,远程调用,接下来处理红包回收的服务器接收到红包回收请求后,进行账户同步以及红包状态标记(标记为已回收),若数据库事务出现异常,那么事务回滚,此时,这个红包没有回收成功,只能等待下一个5min后再次被回收。
到这里,流程基本介绍完了,那接下来介绍一下数据模型...
2. 数据模型
数据库用的是MySQL。将红包记录进行持久化存储,用于查询红包分配记录以及后期的历史记录查询。红包分配的数据模型如下图所示:
图4 红包分配数据模型
图4中展示了部分的比较重要的数据信息,表之间的关联是靠红包ID建立起来的,红包记录以及状态标记图中已经标识出来了,就不一一介绍了。
在数据库层面,接收红包功能存在高并发问题,那接下来就简单介绍下是如何处理并发的...
3. 并发处理
是如何处理高并发问题的呢?
分析:
首先,由于红包的金额存放在redis缓存队列中,由于redis是单线程的,那么在获取红包的阶段不存在并发问题...
然后,下一步是MySQL数据库一系列的update操作,存在高并发问题...
最后,是记录保存,insert操作,也不存在并发问题...
数据库中update操作,主要应用乐观锁和X锁两种方式来保证数据一致性的。
4. 并发测试
在一段时间的并发测试中,测试通过,不会出现数据不一致问题,红包回收功能也能正常进行。
目前在并发方面,至少支持同一时刻并发量为3000的抢红包操作不会出现问题。
总结,由于能力以及技术有限,目前的方案基本适用用户量不是很大的应用场景,后期随着用户量的增大,会进一步的进行优化...