CN109242457A - 一种抢红包的方法及系统 - Google Patents
一种抢红包的方法及系统 Download PDFInfo
- Publication number
- CN109242457A CN109242457A CN201811120106.XA CN201811120106A CN109242457A CN 109242457 A CN109242457 A CN 109242457A CN 201811120106 A CN201811120106 A CN 201811120106A CN 109242457 A CN109242457 A CN 109242457A
- Authority
- CN
- China
- Prior art keywords
- red packet
- money
- amount
- user
- robbing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种抢红包的方法及系统,所述抢红包方法包括:接收发红包用户录入的待发红包金额和红包个数并缓存所述待发红包金额至数据库;推送通知消息至抢红包用户;接收抢红包用户的抢红包请求并通过分析判断进行响应。通过本发明公开的技术方案解决现有技术中存在的抢红包性能低下的技术问题。
Description
技术领域
本发明属于电子技术领域,具体涉及一种抢红包的方法及系统。
背景技术
据统计,2016年春节支付宝抢红包的峰值达到8.83亿次/分钟,2017年春节微信参与抢红包的峰值达到8.1亿次/分钟,抢红包已蔚然成为一种中国人特有的社交潮流。现有抢红包功能主要集中在微信、支付宝等手机APP,需要下载、安装才能使用,具有局限性,另外,现有的抢红包方案需要优化,因为不能满足现有的需求。
发明内容
本发明的目的在于提供一种抢红包的方法及系统,用以解决现有技术中存在抢红包的系统性能低下的技术问题。
为实现上述目的,本发明实施例第一方面提供了一种抢红包的方法,包括:接收发红包用户录入的待发红包金额和红包个数并缓存所述待发红包金额至数据库;推送通知消息至抢红包用户;接收抢红包用户的抢红包请求并通过分析判断进行响应。
优选地,所述接收抢红包用户的抢红包请求并通过分析判断进行响应,包括:若剩余红包个数和剩余红包金额为0,则向所述抢红包用户返回“已抢完”;若已分配用户队列包含所述抢红包用户ID,则向所述抢红包用户返回“已抢过”;如果所述剩余红包个数和剩余红包金额不为0且已分配红包队列不包括所述抢红包用户ID,则向所述抢红包用户ID分配一个所述红包金额,所述红包金额是根据红包分配算法生成,向所述抢红包用户返回“抢红包成功”和抢到的红包金额,并将所述红包金额与所述抢红包用户ID存入已分配红包队列。
优选地,所述红包分配算法,包括:若所述红包个数总数为一个,则生成的红包金额为待发红包金额;若所述红包个数为多个,则生成的红包金额取0.01与a倍红包均值之间的随机数,红包均值=剩余总金额/剩余个数,a≥2,a为整数;若所述红包个数为多个,每生成一次红包,红包总金额减去生成的红包金额,红包个数减一,直至红包个数值为一,红包金额使用剩余的金额,不再随机生成。
优选地,所述接收发红包用户录入的待发红包金额和红包个数之后,包括:根据红包分配算法依据发红包金额和红包个数生成至少一个红包金额;缓存所述至少一个红包金额至未分配红包队列。
优选地,所述缓存所述至少一个红包金额至未分配红包队列之后,包括:根据抢红包用户的抢红包请求,从所述未分配红包队列中取出一个红包金额向所述抢红包用户分配所述红包金额,向已分配红包队列中存入分配到的所述红包金额和抢红包用户ID。
优选地,所述缓存所述至少一个红包金额至未分配红包队列,包括:所述红包金额存储在缓存模块,所述缓存模块以键值对KV形式存取数据,以待发红包ID作为K值,以所述红包金额作为V值,构成未分配红包队列。
优选地,所述接收抢红包用户的抢红包请求之后,包括:根据所述发红包用户录入的待发红包金额和红包个数构成大红包队列,所述大红包队列记录剩余红包个数和剩余待发红包金额;调用红包分配算法进行计算并生成向所述抢红包用户分配的红包金额,将所述抢红包用户分配到的所述红包金额和抢红包用户ID存入已分配红包队列,所述已分配红包队列记录所述抢红包用户ID和所述抢红包用户抢到的金额;判断所述抢红包用户ID是否包括在所述已分配红包队列中,如果否,则所述红包金额和所述抢红包用户ID写入已分配红包队列并更新所述大红包队列。
优选地,所述抢红包用户或所述发红包用户在抢红包或发红包所使用的界面是基于浏览器打开,所述浏览器支持Html5。
本发明公开的实施例的另外一个方面,提供了一种抢红包的系统,包括:客户端,包括抢红包用户客户端和发红包用户客户端,所述抢红包用户客户端用于向应用服务器发送抢红包请求;所述发红包户客户端用于向应用服务器发送发红包请求;所述客户端上安装有支持Html5的浏览器,在所述浏览器上打开抢红包用户和发红包用户的使用界面;应用服务器,用于接收并处理所述抢红包用户和所述发红包用户的抢红包请求和发红包请求的业务逻辑;数据库,用于存储所述抢红包用户通过所述客户端录入的待发红包金额和所述抢红包用户通过所述客户端抢到的红包金额。
优选地,所述抢红包的系统的系统架构包括:CDN缓存层,用于缓存静态化资源;负载均衡层,用于根据访问量,负责将请求转发到不同应用服务器;Web应用层,用于在Tomcat集群上部署相同的Web应用;Redis缓存层,用于缓存抢红包过程产生的数据;数据存储层,用于存储待发红包金额和小红包抢完后的小红包金额;其中,所述CDN缓存层位于所述负载均衡层之上,所述负载均衡层位于所述Web应用层之上,所述Web应用层位于所述Redis缓存层之上,所述Redis缓存层位于所述数据存储层之上。
本发明具有如下优点:
本方案设计的抢红包的系统基于Html5技术开发前端,使用响应式布局,能自动匹配手机端、平板端、电脑端等不同客户端分辨率,用户在不同设备上使用浏览器打开系统就能使用,而不仅仅局限在APP内部。
本方案设计一种基于B/S架构的通用抢红包方案,使用缓存达到高性能,可以单机部署、集群化部署、云端部署。
附图说明
图1为本发明实施例公开的抢红包方法的流程图;
图2为本发明实施例公开的发红包用户的流程设计流程图;
图3为本发明实施例公开的抢红包用户的流程设计流程图;
图4为本发明实施例公开的抢红包方法的流程图;
图5为本发明实施例公开的抢红包方法的流程图;
图6为本发明实施例公开的抢红包方法的通过未分配红包队列和已分配红包队列存储红包数据的示意图;
图7为本发明实施例公开的抢红包方法的通过未分配红包队列和已分配红包队列存储红包数据的示意图;
图8为本发明实施例公开的抢红包的系统的结构示意图;
图9为本发明实施例公开的抢红包的系统的技术架构图。
具体实施方式
以下实施例用于说明本发明,但不用来限制本发明的范围。
需要说明的是,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
实施例1
参考图1,图1为本发明实施例公开的抢红包方法的流程图;
本发明实施例公开了一种抢红包的方法,包括:
步骤S01,接收发红包用户录入的待发红包金额和红包个数并缓存所述待发红包金额至数据库;
具体应用中,发红包用户在浏览器上打开发红包用户的使用界面,浏览器支持Html5,发红包用户在发红包客户端填写待发红包金额和红包个数,发送红包金额和红包个数到应用服务器端,将待发红包金额存储在数据库中,以便发红包用户进行查看。
发红包结构设计如下:
发红包用户的动作是封一个红包,封装的红包关键数据包括发红包用户ID、红包ID、个数、总金额等,为应对同时发红包的请求超过系统的并发处理能力,可在流量高峰阶段使用队列技术减缓对应用服务器的冲击。发红包的实现结构设计为:1)发包者在前端填写红包数据并向应用服务器提交;2)若同时发红包提交请求超过一定量级,可先将请求放入发红包队列;3)应用服务器先将红包数据存入缓存,缓存模块基于内存运行,因为内存的存取性能远远大于硬盘,将抢红包的过程放在内存完成性能很高,为保证缓存模块中单个红包数据的全局唯一性,这时可以通过Random提前生成全局唯一ID作为红包主键;4)红包数据在缓存之后,进入入库队列,被推送到数据库进行持久化存储;5)同时,红包数据进入红包广播队列,被推送到众多抢红包用户客户端,抢红包用户拿到待发红包ID准备发起抢红包流程。发红包实现结构设计如图2所示。
在步骤S01之后,根据红包分配算法依据发红包金额和红包个数生成至少一个红包金额,红包金额根据发红包用户自行设定。
抢红包结构设计如下:
大量用户争抢一个红包,实质是有限资源在高并发情况下的抢占,这就存在高并发竞争的问题,红包在发出时是有个数限制的,也就是说在发出时就能估算有效抢到红包用户的个数,超过红包个数的用户访问请求,红包已经分配完,再去争抢是无意义的,所以,当抢红包的请求并发量比较大时,可以设置一层请求过滤队列,通过计数器统计,在红包个数内的请求直接放入,一旦红包已经抢完,红包个数减为零,后面的请求不再放入,直接返回“红包已抢完”,抢红包的过程在内存完成,红包数据和抢到的用户列表都暂存在缓存,这样可保证最快的响应性能,等红包抢完,则将抢到红包的用户ID和金额批量入库。抢红包的实现结构设计为:1)抢红包用户发出抢红包的请求;2)当并发量比较大时,请求先放入队列,通过计数器统计,超过红包个数直接返回;3)放入有效的抢红包请求,抢红包过程在内存完成,根据待发红包ID从缓存拿到红包剩余数量和剩余金额,通过红包分配算法随机生成一个金额给抢包者,这个计算是在内存实时完成的,更新红包剩余金额,红包剩余数量减1,将更新后的红包数据再放回缓存以备下次抢红包使用,同时将抢到红包的用户ID和金额也放入缓存,可维护一个抢到用户的数据数组,记录所有抢到用户的ID和金额;4)当红包被抢完时,将抢到红包的用户数据数组放入入库队列5)入库队列里的数据异步批量存入数据库。抢红包实现结构设计如图3所示。
本实施例公开的是在抢红包用在未进行抢红包之前,应用服务器端已经存在两个队列,一个是未分配红包队列,一个是已分配队列,当根据红包分配算法依据发红包金额和红包个数生成至少一个红包金额后,自动将红包金额和待发红包金额ID存入未分配红包队列;红包金额存储在缓存模块,缓存模块以键值对KV形式存取数据,以待发红包ID作为K值,以红包金额作为V值,构成未分配红包队列;以待发红包ID作为K值,以抢到的红包金额和抢红包用户ID组合作为V值,构成已分配红包队列。
具体的红包分配算法为:
因人民币最小金额为1分,生成红包的金额最小为0.01元;
若红包个数是一个,则生成红包金额直接使用总金额;
若红包个数是多个,则生成红包金额取0.01与a倍红包均值之间的随机数,红包均值=剩余总金额/剩余个数,即每轮生成的随机红包金额最小为0.01,最大为a倍红包均值,使用a倍红包均值做最大值可以保证每轮生成的红包金额不会相差太大,a≥2,a为整数。
每生成一次红包,总金额减去生成的金额,红包个数减一,直至红包个数值为一,也就是最后一个红包,金额使用剩余的金额,不再随机生成。
假设剩余红包总金额为m,剩余红包个数为n,每轮生成的红包金额为x,算法公式如下:
每次计算一轮后,将m=m-x,n=n-1进行迭代计算,直到n=1为止。
以10人抢100元大红包为例,一开始红包的数量为10、金额为100,同一个用户对同一个红包只能抢一次,也就是要经过10轮才能抢完,10位不同用户抢到的金额经过算法随机计算得到,经测试,其中一种分配情况如表1所示,本案例在笔者机器上经100000次运行,计算平均耗时约为7微秒,可见使用本算法在内存生成红包的速度是很快的。
表1以10人抢100元红包为例
步骤S02,推送通知消息至抢红包用户;
在具体的应用中的一个实施例中,应用服务器端根据红包分配算法进行计算得到至少一个红包金额,将红包金额缓存至未分配红包队列后,向抢红包用户推送抢红包消息,供抢红包用户抢红包。
步骤S03,接收抢红包用户的抢红包请求并通过分析判断进行响应。
作为本发明的一个实施例,根据抢红包用户的抢红包请求,从未分配红包队列中取出一个红包金额向抢红包用户分配红包金额,向已分配红包队列中存入分配到的红包金额和抢红包用户ID。
作为本发明另外一个实施例,根据抢红包用户的抢红包请求,根据发红包用户录入的待发红包金额和红包个数构成大红包队列,大红包队列记录剩余红包个数和剩余待发红包金额;调用红包分配算法进行实时计算并生成向抢红包用户分配的红包金额,将抢红包用户分配到的红包金额和抢红包用户ID存入已分配红包队列,已分配红包队列记录抢红包用户ID和抢红包用户抢到的金额。
判断抢红包用户ID是否包括在所述已分配红包队列中,如果否,则红包金额和所述抢红包用户ID存入已分配红包队列并更新大红包队列。
步骤S03中,通过分析判断进行响应具体包括:
若剩余红包个数和剩余红包金额为0,则向抢红包用户返回“已抢完”;
若已分配用户队列包含抢红包用户ID,则向抢红包用户返回“已抢过”;
如果剩余红包个数和剩余红包金额不为0且已分配红包队列不包括抢红包用户ID,则向抢红包用户ID分配一个所述红包金额,红包金额是根据红包分配算法生成,向抢红包用户返回“抢红包成功”和抢到的红包金额,并将红包金额与抢红包用户ID存入已分配红包队列。
如图4所示,图4为本发明实施例公开的抢红包方法的流程图;本实施例具体以事先依据红包分配算法生成红包金额为例详细说明本发明实施例,具体如下:
(1)发红包用户填写大红包数据,红包金额和红包个数,发送到应用服务器端。
(2)应用服务器根据红包分配算法,从总金额生成和红包个数相等的红包。
(3)将生成的红包数据缓存至缓存模块,缓存模块支持以KV(键值对)形式存取数据,红包金额数据以集合格式存储在缓存模块,以待发红包ID作为K值,以红包金额作为V值,构成未分配红包队列。
(4)红包数据缓存成功后,应用服务器推送通知消息给抢红包用户。
(5)待发红包金额进入数据库持久化存储,以备用户查询。
(6)抢红包用户收到红包提醒,点击抢红包。
(7)抢红包请求携带待发红包ID和抢红包用户ID进入应用服务器,发送的抢红包请求可能远远大于红包个数,若红包已抢完,再处理抢红包请求是无意义的,所以抢红包请求先经原子计数,超过红包个数的直接返回。
具体原子计数模型如下:
对同一个红包,可能有非常多的抢包者同时发送抢红包请求,在能够确定红包数量的基础上,对放入的请求进行原子计数,如表2所示,当数目和红包个数相等时,即红包被抢完,后面的抢红包请求无需再放入,直接返回“已抢完”,既能提高响应速度又能减轻系统压力。本方案使用Redis两个原子性的操作命令incr、decr完成计数,以待发红包ID为key,每次放入一个抢红包请求,计数就加1,在Redis中使用代码:redis>incr key,在Spring环境中使用代码:Long incrementId=redisTemplate.opsForValue().increment(key,1)。
表2
原子计数(incrkey)
本实施例中红包数据格式如下:
在Redis缓存模块,每个红包对应两个数据队列:未分配红包队列和已分配红包队列,如图6所示,根据红包分配算法将待发红包生成一组小红包,构成未分配红包队列,以Redis的List数据类型存储,以待发红包ID为key,以小红包金额为value,存储命令如下:
>lpush44015215.54--存入15.54
…
>lpush44015213.2--存入13.2
抢红包过程中,同时会有非常大的并发请求,为保证抢红包操作的原子性,使用Lua脚本执行抢红包逻辑。
已分配红包队列使用Redis的Hash数据类型存储,以红包ID为key,以抢包者ID为field,以抢到的金额为value,存储命令如下:
>hmset hid:44015211115.54--存入{抢包者ID:111,抢到金额:15.54}
…
>hmset hid:44015212013.2--存入{抢包者ID:120,抢到金额:13.2}。
(8)有效请求进入缓存,根据红包ID找到两个队列:未分配红包队列和已分配红包队列。
(9)若未分配红包队列已为空,则直接返回“已抢完”,否则继续;若已分配红包队列包括用户ID,则返回“已抢过”,否则继续;若未分配红包队列不为空且已分配红包队列不包括用户ID,则进行抢红包活动,从未分配红包队列取出一个金额,与抢红包用户ID组合一起,存入已分配红包队列,从而达到某个用户抢到了红包的某个金额,返回前端“抢红包成功,抢到金额XX元”。重复以上操作,直至未分配红包队列为空,也即红包都被分配到了抢红包用户ID,整个抢红包过程都在内存完成。
(10)抢红包结束,未分配红包队列为空,将已分配红包队列数据批量异步存入数据库,一个抢红包流程结束。
为了测试本发明实施例设计的抢红包方法的性能,在PC机上进行了两组模拟实验,硬件配置为:CPU Core i53.3GHz、内存8GB,软件配置为:Tomcat 7.0、JDK 1.7、Redis3.0、MySQL 5.5。
1)测试红包分配算法
为了测试本发明实施例设计的红包分配算法的公平性,本发明实施例优选a=2,此时,模拟10人抢100元红包,每轮产生10个小红包数据,执行1000000轮,每人产生了1000000条红包数据,将每个人的红包数据求平均值和标准差,得到的数据为表5所示。
表5
抢包者 | 平均值 | 标准差 |
第1人 | 10.00 | 5.78 |
第2人 | 9.99 | 5.82 |
第3人 | 10.00 | 5.88 |
第4人 | 9.99 | 5.95 |
第5人 | 10.00 | 6.07 |
第6人 | 10.00 | 6.22 |
第7人 | 10.00 | 6.44 |
第8人 | 10.01 | 6.84 |
第9人 | 10.01 | 7.69 |
第10人 | 10.00 | 7.68 |
由实验数据可知:(1)10人的平均值大致相等,都在100/10=10附近波动,从统计学角度看,说明每人抢到红包的期望值是大致相等的,也就是大家抢到的红包面额在概率上是大致均匀分布的,都接近于理论平均值(总金额/总个数);(2)10人的标准差存在差异,从第1人到第10人逐渐增大,这表明,先生成的红包数据波动较小,后生成的红包数据波动较大,也就是后抢的人有较大几率拿到“手气最佳”或者“手气最差”,增加了抢红包的趣味性。
进一步地,上述实验中的平均值和标准差均于红包分配算法公式中的参数a相关,具体地,a取值越大,达到平均值需要大致相等所需的执行抢红包的轮数越大,标准差波动越大。因此,可以通过参数a来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动进行调整,并且是在红包均值的倍数范围内进行调整。这样,红包分配算法公式进一步可优化为:
每次计算一轮后,将m=m-x,n=n-1进行迭代计算,直到n=1为止。
上述优化的红包分配算法,当b<m/n时,首先,通过参数a来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动在红包均值的倍数范围内进行调整,同时,通过参数b来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动在红包均值的一倍范围内进行微调;当b>m/n时,首先,通过参数a来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动在红包均值的倍数范围内进行调整,同时,通过参数b来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动在大于红包均值的一倍范围内进行放大调整。
2)测试抢红包性能
使用Java编程模拟高并发抢红包场景,红包个数为100000个,总金额为1000000元,红包数据和明细都存储在Redis,抢红包过程在内存完成,同时启动30个线程运行抢红包程序。通过抢完的红包总个数除以总耗时可得到抢红包速度,经多次测算,每毫秒可以抢23个,也就是每秒大致可以抢2.3万个红包,可见在内存完成抢红包过程性能是很高的,能满足绝大多数场景需求。
实施例2
如图5所示,图5为本发明实施例公开的抢红包方法的流程图;本实施例具体以实时依据红包分配算法生成红包金额为例详细说明本发明实施例,具体如下:
(1)用户发红包的流程是:发红包用户在发红包客户端录入待发红包金额和红包个数,如图7所示,根据发红包用户录入的待发红包金额和红包个数构成大红包队列,大红包队列记录剩余红包个数和剩余待发红包金额;点击发出红包,应用服务器端推送通知消息给抢红包用户。
(2)用户抢红包的流程是:抢红包用户在抢红包用户客户端收到红包提示信息,查看红包列表,点击抢红包,抢红包用户发送请求到应用服务器,如图7所示,调用红包分配算法进行实时计算并生成向抢红包用户分配的红包金额,将抢红包用户分配到的红包金额和抢红包用户ID存入已分配红包队列,已分配红包队列记录抢红包用户ID和抢红包用户抢到的金额;应用服务器通过计算判断返回前端响应信息,若剩余金额和剩余红包个数为0,返回“已抢完”;若抢到的用户队列包含该用户ID,则返回“已抢过”;若剩余金额和剩余红包个数不为0,且不包含该用户ID,则从剩余金额分配出一个小金额给该用户,返回“抢红包成功”,显示抢到的金额,并更新所述大红包队列,即,大红包队列剩余个数减一,剩余红包金额减少。
具体的红包分配算法为:
因人民币最小金额为1分,生成红包的金额最小为0.01元;
若红包个数是一个,则生成红包金额直接使用总金额;
若红包个数是多个,则生成红包金额取0.01与a倍红包均值之间的随机数,红包均值=剩余总金额/剩余个数,即每轮生成的随机红包金额最小为0.01,最大为a倍红包均值,使用a倍红包均值做最大值可以保证每轮生成的红包金额不会相差太大,a≥2,a为整数。
每生成一次红包,总金额减去生成的金额,红包个数减一,直至红包个数值为一,也就是最后一个红包,金额使用剩余的金额,不再随机生成。
假设剩余红包总金额为m,剩余红包个数为n,每轮生成的红包金额为x,算法公式如下:
每次计算一轮后,将m=m-x,n=n-1进行迭代计算,直到n=1为止。
为了测试本发明实施例设计的抢红包方法的性能,在PC机上进行了两组模拟实验,硬件配置为:CPU Core i53.3GHz、内存8GB,软件配置为:Tomcat 7.0、JDK 1.7、Redis3.0、MySQL 5.5。
1)测试红包分配算法
为了测试本发明实施例设计的红包分配算法的公平性,本发明实施例优选a=2,此时,模拟10人抢100元红包,每轮产生10个小红包数据,执行1000000轮,每人产生了1000000条红包数据,将每个人的红包数据求平均值和标准差,得到的数据为表5所示。
表5
抢包者 | 平均值 | 标准差 |
第1人 | 10.00 | 5.78 |
第2人 | 9.99 | 5.82 |
第3人 | 10.00 | 5.88 |
第4人 | 9.99 | 5.95 |
第5人 | 10.00 | 6.07 |
第6人 | 10.00 | 6.22 |
第7人 | 10.00 | 6.44 |
第8人 | 10.01 | 6.84 |
第9人 | 10.01 | 7.69 |
第10人 | 10.00 | 7.68 |
由实验数据可知:(1)10人的平均值大致相等,都在100/10=10附近波动,从统计学角度看,说明每人抢到红包的期望值是大致相等的,也就是大家抢到的红包面额在概率上是大致均匀分布的,都接近于理论平均值(总金额/总个数);(2)10人的标准差存在差异,从第1人到第10人逐渐增大,这表明,先生成的红包数据波动较小,后生成的红包数据波动较大,也就是后抢的人有较大几率拿到“手气最佳”或者“手气最差”,增加了抢红包的趣味性。
进一步地,上述实验中的平均值和标准差均于红包分配算法公式中的参数a相关,具体地,a取值越大,达到平均值需要大致相等所需的执行抢红包的轮数越大,标准差波动越大。因此,可以通过参数a来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动进行调整,并且是在红包均值的倍数范围内进行调整。这样,红包分配算法公式进一步可优化为:
每次计算一轮后,将m=m-x,n=n-1进行迭代计算,直到n=1为止。
上述优化的红包分配算法,当b<m/n时,首先,通过参数a来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动在红包均值的倍数范围内进行调整,同时,通过参数b来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动在红包均值的一倍范围内进行微调;当b>m/n时,首先,通过参数a来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动在红包均值的倍数范围内进行调整,同时,通过参数b来对达到每人抢到红包的期望值大致相等的抢红包的轮数以及后生成的红包数据波动在大于红包均值的一倍范围内进行放大调整。
2)测试抢红包性能
使用Java编程模拟高并发抢红包场景,红包个数为100000个,总金额为1000000元,红包数据和明细都存储在Redis,抢红包过程在内存完成,同时启动30个线程运行抢红包程序。通过抢完的红包总个数除以总耗时可得到抢红包速度,经多次测算,每毫秒可以抢23个,也就是每秒大致可以抢2.3万个红包,可见在内存完成抢红包过程性能是很高的,能满足绝大多数场景需求。
实施例3
本发明公开的实施例中公开了一种抢红包的系统的结构示意图,如图8所示:
客户端01,包括抢红包用户客户端和发红包用户客户端,所述抢红包用户客户端用于向应用服务器发送抢红包请求;所述发红包户客户端用于向应用服务器发送发红包请求;所述客户端上安装有支持Html5的浏览器,在所述浏览器上打开抢红包用户和发红包用户的使用界面;
前端界面使用Html5技术开发响应式页面,客户端设备可以是手机、平板、电脑、触摸一体机等,只需要安装有支持Html5的浏览器就可以使用本系统。Html5技术是html5标签、CSS3、javascript三者的统称,使用CSS3提供的@media查询,可以针对不同的屏幕尺寸设置不同的样式,从而达到一个页面在不同设备都能正常显示。
应用服务器02,用于接收并处理所述抢红包用户和所述发红包用户的抢红包请求和发红包请求的业务逻辑;
应用服务器处理抢红包业务逻辑,当并发量比较大时,可以在应用服务器前面加一层负载均衡服务器;Tomcat轻量、稳定,用作应用服务器;Nginx具备强大的并发处理、灵活的反向代理能力,用作负载均衡服务器。
数据库03,用于存储所述抢红包用户通过所述客户端录入的待发红包金额和所述抢红包用户通过所述客户端抢到的红包金额。
数据库用于存储红包数据,本方案使用MySQL持久化数据,MySQL是最流行的用于Web开发的关系型数据库,支持事务和锁机制,可以单点、主从复制、集群多种规模运行。
如图9所示,图9为本发明实施例公开的抢红包的系统的技术架构图;
抢红包的系统的系统架构包括:
CDN缓存层,用于缓存静态化资源;
负载均衡层,用于根据访问量,负责将请求转发到不同应用服务器;
Web应用层,用于在Tomcat集群上部署相同的Web应用;
Redis缓存层,用于缓存抢红包过程产生的数据;
数据存储层,用于存储待发红包金额和小红包抢完后的小红包金额;
其中,所述CDN缓存层位于所述负载均衡层之上,所述负载均衡层位于所述Web应用层之上,所述Web应用层位于所述Redis缓存层之上,所述Redis缓存层位于所述数据存储层之上。
一般来说,当上线的Web系统并发量达到一定数量级时,都可以通过大规模应用服务器集群化部署提高系统的抗压能力。对于实际线上的抢红包的系统,通过不断增加应用服务器可以快速提高系统的并发处理能力。
虽然,上文中已经用一般性说明及具体实施例对本发明作了详尽的描述,但在本发明基础上,可以对之作一些修改或改进,这对本领域技术人员而言是显而易见的。因此,在不偏离本发明精神的基础上所做的这些修改或改进,均属于本发明要求保护的范围。
Claims (10)
1.一种抢红包的方法,其特征在于,包括:
接收发红包用户录入的待发红包金额和红包个数并缓存所述待发红包金额至数据库;
推送通知消息至抢红包用户;
接收抢红包用户的抢红包请求并通过分析判断进行响应。
2.如权利要求1所述的一种抢红包的方法,其特征在于,所述接收抢红包用户的抢红包请求并通过分析判断进行响应,包括:
若剩余红包个数和剩余红包金额为0,则向所述抢红包用户返回“已抢完”;
若已分配用户队列包含抢红包用户ID,则向所述抢红包用户返回“已抢过”;
如果所述剩余红包个数和剩余红包金额不为0且已分配红包队列不包括所述抢红包用户ID,则向所述抢红包用户ID分配一个红包金额,所述红包金额是根据红包分配算法生成,向所述抢红包用户返回“抢红包成功”和抢到的红包金额,并将所述红包金额与所述抢红包用户ID存入已分配红包队列。
3.如权利要求2所述的抢红包的方法,其特征在于,所述红包分配算法,包括:
若所述红包个数总数为一个,则生成的红包金额为待发红包金额;
若所述红包个数为多个,则生成的红包金额取0.01与a倍红包均值之间的随机数,红包均值=剩余总金额/剩余个数,a≥2,a为整数;
若所述红包个数为多个,每生成一次红包,红包总金额减去生成的红包金额,红包个数减一,直至红包个数值为一,红包金额使用剩余的金额,不再随机生成。
4.如权利要求1所述的一种抢红包的方法,其特征在于,所述接收发红包用户录入的待发红包金额和红包个数之后,包括:
根据红包分配算法依据发红包金额和红包个数生成至少一个红包金额;
缓存所述至少一个红包金额至未分配红包队列。
5.如权利要求4所述的一种抢红包的方法,其特征在于,所述缓存所述至少一个红包金额至未分配红包队列之后,包括:
根据抢红包用户的抢红包请求,从所述未分配红包队列中取出一个红包金额向所述抢红包用户分配所述红包金额,向已分配红包队列中存入分配到的所述红包金额和抢红包用户ID。
6.如权利要求4所述的一种抢红包的方法,其特征在于,所述缓存所述至少一个红包金额至未分配红包队列,包括:
所述红包金额存储在缓存模块,所述缓存模块以键值对KV形式存取数据,以待发红包ID作为K值,以所述红包金额作为V值,构成未分配红包队列。
7.如权利要求1所述的一种抢红包的方法,其特征在于,所述接收抢红包用户的抢红包请求之后,包括:
根据所述发红包用户录入的待发红包金额和红包个数构成大红包队列,所述大红包队列记录剩余红包个数和剩余待发红包金额;
调用红包分配算法进行计算并生成向所述抢红包用户分配的红包金额,将所述抢红包用户分配到的所述红包金额和抢红包用户ID存入已分配红包队列,所述已分配红包队列记录所述抢红包用户ID和所述抢红包用户抢到的金额;
判断所述抢红包用户ID是否包括在所述已分配红包队列中,如果否,则所述红包金额和所述抢红包用户ID写入已分配红包队列并更新所述大红包队列。
8.如权利要求1所述的抢红包的方法,其特征在于,所述抢红包用户或所述发红包用户在抢红包或发红包所使用的界面是基于浏览器打开,所述浏览器支持Html5。
9.一种抢红包的系统,其特征在于,包括:
客户端,包括抢红包用户客户端和发红包用户客户端,所述抢红包用户客户端用于向应用服务器发送抢红包请求;所述发红包户客户端用于向应用服务器发送发红包请求;所述客户端上安装有支持Html5的浏览器,在所述浏览器上打开抢红包用户和发红包用户的使用界面;
应用服务器,用于接收并处理所述抢红包用户和所述发红包用户的抢红包请求和发红包请求的业务逻辑;
数据库,用于存储所述抢红包用户通过所述客户端录入的待发红包金额和所述抢红包用户通过所述客户端抢到的红包金额。
10.如权利要求9所述的一种抢红包的系统,其特征在于,所述抢红包的系统的系统架构包括:
CDN缓存层,用于缓存静态化资源;
负载均衡层,用于根据访问量,负责将请求转发到不同应用服务器;
Web应用层,用于在Tomcat集群上部署相同的Web应用;
Redis缓存层,用于缓存抢红包过程产生的数据;
数据存储层,用于存储待发红包金额和小红包抢完后的小红包金额;
其中,所述CDN缓存层位于所述负载均衡层之上,所述负载均衡层位于所述Web应用层之上,所述Web应用层位于所述Redis缓存层之上,所述Redis缓存层位于所述数据存储层之上。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811120106.XA CN109242457A (zh) | 2018-09-21 | 2018-09-21 | 一种抢红包的方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811120106.XA CN109242457A (zh) | 2018-09-21 | 2018-09-21 | 一种抢红包的方法及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN109242457A true CN109242457A (zh) | 2019-01-18 |
Family
ID=65057444
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811120106.XA Pending CN109242457A (zh) | 2018-09-21 | 2018-09-21 | 一种抢红包的方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109242457A (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110675133A (zh) * | 2019-09-30 | 2020-01-10 | 北京金山安全软件有限公司 | 一种抢红包的方法、装置、电子设备及可读存储介质 |
CN110688215A (zh) * | 2019-08-23 | 2020-01-14 | 咪咕文化科技有限公司 | 虚拟资源的分配方法、服务器和计算机可读存储介质 |
CN111949393A (zh) * | 2019-05-16 | 2020-11-17 | 腾讯科技(深圳)有限公司 | 资源分配、获取方法、装置、存储介质和设备 |
CN111985799A (zh) * | 2020-08-11 | 2020-11-24 | 北京达佳互联信息技术有限公司 | 对象集合更新方法、装置、电子设备和存储介质 |
CN112308621A (zh) * | 2020-11-04 | 2021-02-02 | 深圳市欢太科技有限公司 | 数据处理方法、装置、计算机存储介质及电子设备 |
CN112561567A (zh) * | 2020-12-03 | 2021-03-26 | 星宏传媒有限公司 | 一种电子红包领取请求的异步处理方法、系统及设备 |
WO2021083090A1 (zh) * | 2019-10-30 | 2021-05-06 | 维沃移动通信有限公司 | 消息发送方法及移动终端 |
CN113645323A (zh) * | 2021-07-29 | 2021-11-12 | 广州鲁邦通智能科技有限公司 | 一种高并发状态下防止mac地址重复写入的方法、单元和系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106095877A (zh) * | 2016-06-07 | 2016-11-09 | 中国建设银行股份有限公司 | 一种红包数据处理方法和装置 |
CN106230926A (zh) * | 2016-07-27 | 2016-12-14 | 宁波圆形网络科技有限公司 | 一种红包发送系统及方法 |
CN106503975A (zh) * | 2016-11-03 | 2017-03-15 | 北京京东金融科技控股有限公司 | 处理信息的方法、装置以及终端设备 |
CN107330680A (zh) * | 2017-06-22 | 2017-11-07 | 福建中金在线信息科技有限公司 | 红包控制方法、装置、计算机设备及计算机可读存储介质 |
CN108055328A (zh) * | 2017-12-18 | 2018-05-18 | 苏州燕云网络技术有限公司 | 发放电子红包的方法及装置 |
-
2018
- 2018-09-21 CN CN201811120106.XA patent/CN109242457A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106095877A (zh) * | 2016-06-07 | 2016-11-09 | 中国建设银行股份有限公司 | 一种红包数据处理方法和装置 |
CN106230926A (zh) * | 2016-07-27 | 2016-12-14 | 宁波圆形网络科技有限公司 | 一种红包发送系统及方法 |
CN106503975A (zh) * | 2016-11-03 | 2017-03-15 | 北京京东金融科技控股有限公司 | 处理信息的方法、装置以及终端设备 |
CN107330680A (zh) * | 2017-06-22 | 2017-11-07 | 福建中金在线信息科技有限公司 | 红包控制方法、装置、计算机设备及计算机可读存储介质 |
CN108055328A (zh) * | 2017-12-18 | 2018-05-18 | 苏州燕云网络技术有限公司 | 发放电子红包的方法及装置 |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111949393A (zh) * | 2019-05-16 | 2020-11-17 | 腾讯科技(深圳)有限公司 | 资源分配、获取方法、装置、存储介质和设备 |
CN111949393B (zh) * | 2019-05-16 | 2024-02-06 | 腾讯科技(深圳)有限公司 | 资源分配、获取方法、装置、存储介质和设备 |
CN110688215A (zh) * | 2019-08-23 | 2020-01-14 | 咪咕文化科技有限公司 | 虚拟资源的分配方法、服务器和计算机可读存储介质 |
CN110675133A (zh) * | 2019-09-30 | 2020-01-10 | 北京金山安全软件有限公司 | 一种抢红包的方法、装置、电子设备及可读存储介质 |
WO2021083090A1 (zh) * | 2019-10-30 | 2021-05-06 | 维沃移动通信有限公司 | 消息发送方法及移动终端 |
CN111985799A (zh) * | 2020-08-11 | 2020-11-24 | 北京达佳互联信息技术有限公司 | 对象集合更新方法、装置、电子设备和存储介质 |
CN112308621A (zh) * | 2020-11-04 | 2021-02-02 | 深圳市欢太科技有限公司 | 数据处理方法、装置、计算机存储介质及电子设备 |
CN112561567A (zh) * | 2020-12-03 | 2021-03-26 | 星宏传媒有限公司 | 一种电子红包领取请求的异步处理方法、系统及设备 |
CN113645323A (zh) * | 2021-07-29 | 2021-11-12 | 广州鲁邦通智能科技有限公司 | 一种高并发状态下防止mac地址重复写入的方法、单元和系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109242457A (zh) | 一种抢红包的方法及系统 | |
CN103885986B (zh) | 主备数据库同步的方法和装置 | |
Li et al. | Resource and replica management strategy for optimizing financial cost and user experience in edge cloud computing system | |
KR101959153B1 (ko) | 데이터베이스에서의 계좌와 관련된 거래 요청의 효율적인 처리를 위한 시스템 | |
CN109684358A (zh) | 数据查询的方法和装置 | |
US20230109969A1 (en) | Data processing method and apparatus based on node internal memory, device and medium | |
US10678697B1 (en) | Asynchronous cache building and/or rebuilding | |
CN103795781B (zh) | 一种基于文件预测的分布式缓存方法 | |
CN110599263A (zh) | 用户互动数据处理方法、装置、存储介质和计算机设备 | |
US20080313189A1 (en) | Parallel processing of assigned table partitions | |
CN108073684A (zh) | 一种数据处理方法、服务器及计算机可读存储介质 | |
US20100115059A1 (en) | Transaction processing system | |
US10824559B2 (en) | Counter tracker service | |
CN108228349A (zh) | 用于处理任务的方法、系统和存储介质 | |
EP2449520A1 (en) | System and method for adaptive selection of bank card for payment | |
CN112860695B (zh) | 监控数据查询方法、装置、设备、存储介质及程序产品 | |
CN109804354A (zh) | 用于消息队列的消息高速缓存管理 | |
CN104317957B (zh) | 一种报表处理的开放平台、系统及报表处理方法 | |
Adya et al. | Fast key-value stores: An idea whose time has come and gone | |
CN109101554A (zh) | 用于java平台的数据缓存系统、方法以及计算机终端 | |
CN109101580A (zh) | 一种基于Redis的热点数据缓存方法和装置 | |
CN107451853A (zh) | 一种红包实时派发的方法、装置、系统及存储介质 | |
CN110489696A (zh) | 缓存更新方法、装置及电子设备、存储介质 | |
CN109614270A (zh) | 基于Hbase的数据读写方法、装置、设备及存储介质 | |
CN110109978A (zh) | 基于指标的数据分析方法、装置、服务器及可读存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190118 |
|
RJ01 | Rejection of invention patent application after publication |