java 抽奖 高并发处理_如何设计高并发下的抽奖?

关于抽奖,需要考虑的点有很多,这里稍微整理了下主要需要考虑以下三点:

用户抽奖次数限制

奖品数量限制

奖品发放的分布

中奖的概率的可控性

用户抽象次数限制

一个用户必须限制抽奖的次数,而同一个用户的并发几率其实是很小的,所以这里可以用悲观锁来控制用户的抽奖次数。

奖品数量限制

因为并发修改一个奖品的数量可能性是很大的,特别是一些安慰奖,如果这里我们再用悲观锁的话,很容易造成锁超时。所以这里我选择用乐观锁来解决可能出现的并发脏读的情况。

奖品发放的分布

为了防止用脚本来刷抽奖,所以这里需要控制一下奖品发放的一个分布,中大奖需要一个时间间隔,当然这里通过代码来控制是很容易实现的(当然这里也需要考虑一下并发中到两个大奖的情况,也可以通过乐观锁来控制)

中奖的概率的可控性

当我们开始估计抽奖大概会有10W人参加,所以我在设计概率的时候是按照10w来设计的,但是突然发现活动开始一个小时候以后抽奖人数就达到了5W,这个时候就需要可以动态来调整中奖的概率了。这里最好的方式是,不要把中奖概论写死在数据库,而是通过中奖次数/参加人数来计算出来,这样就可以方便的动态的改变中奖概率了。

关于优化

如果并发量实在是太大,导致数据库的QPS异常的高。那么可以在数据库前面加一层缓存来挡一下,把需要写进数据库的数据放入队列。当使用了这种架构架构,就需要考虑一些数据一致性的问题了,比如说

怎么保证数据库的数据和缓存的数据是一致的

如果队列挂掉了,怎么保证缓存的数据能够及时更新到数据库中。如果缓存挂掉了,怎么保证抽奖能够继续进行下去(当然这里可以进行业务妥协,如果缓存挂掉整个抽奖挂掉,如果来不及写进数据库的数据,就当做这些事情没有发生,这就会导致某些人抽奖次数超过限定次数,或者某些奖中奖次数超过了限定次数)

关于优化中我对一些异常情况的解决方法不是很了解,希望懂的朋友可以指教一下

附录(简单流程图)

28daf5be6b1c9bbc1c4ddc510ac82b5f.png

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Java抽奖系统后台使用Spring Boot、MyBatis和Redis队列可以有效地处理高并发情况。 首先,Spring Boot提供了一个轻量级的开发框架,可以简化Java后台开发的流程。它内置了Tomcat服务器,提供了自动配置和快速构建的功能,可快速搭建开发环境。此外,Spring Boot还具有良好的扩展性和灵活性,可以方便地集成其他框架和技术。 MyBatis是一款优秀的持久层框架,可以大幅简化数据库操作的代码。它提供了灵活的SQL映射配置,可以通过注解或XML编写SQL语句,同时也支持动态SQL。MyBatis还支持多种数据库连接池,能够提高数据库连接的效率和并发处理能力。 Redis是一款高性能的内存数据库,可作为缓存或消息队列使用。在抽奖系统中,可以将中奖结果存储在Redis中,以提高中奖查询的性能。此外,Redis还提供了发布-订阅(Publish-Subscribe)机制,可用于实现消息队列。当用户进行抽奖时,可以将请求放入Redis队列中,后台程序可以通过订阅该队列来处理请求,实现并发处理。 使用Redis队列处理高并发可以有效地降低系统的负载和响应时间。通过将请求放入队列中,可以使请求在后台异步处理,减少前端请求等待的时间。同时,通过控制队列的长度和处理速度,还可以防止系统负载过高。 综上所述,Java抽奖系统后台使用Spring Boot、MyBatis和Redis队列可以实现高并发处理能力,提高抽奖系统的性能和可扩展性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值