java用redis处理并发_使用Redis中间件处理商品秒杀活动中出现的超卖问题(使用Java多线程模拟高并发环境)...

a7a848cbd599390a2009a4f824d101a0.png

一、引入Jedis依赖

可以新建Spring或者Maven工程,在pom文件中引入Jedis依赖:

redis.clients

jedis

2.9.0

二、Jedis工具类

JedisUtil.java

d0942260f38827fcd86b910c34c573cd.png

三、秒杀测试类(代码模拟多客户+高并发)

RedisSecKiller.java

fa7801d996b1e1f5b3f09f7a757020df.png

265c1ae1180659129c31a4769f0499b0.png

注:关于多线程部分代码的说明

传统的方式是使用new Thread来创立、运行(start)线程,但那样太低效了;使用定长线程池 + ExecutorService的execute方法来创立、运行线程,比前者高效得多。

四、运行结果

4.1 Redis数据插入结果

进入RedisManager -> db0查看

6bf068c1bf732e9539e8aa4966bc3745.png

1af1c1695c3c2ed542ded2a1c2e6a048.png

4.2 IDEA控制台输出结果

58ca5450095afe1951b37a824bc09f5a.png

五、有趣的测试

5.1 客户数量小于商品数量,且等于最大并发数

将RedisSecKiller类中的USER_NUM从100改为5,由于此时N_THREADS依然为5,最大并发数仍为5,即有5个客户同时在抢购10件商品。注意,只需最大并发数大于等于客户数量,就会造成所有客户同时抢购商品(高并发)的情况出现。

运行结果如下:

6c93d4bc1e26b0d01ca48e3ef1201bfb.png

5.2 客户数量小于商品数量,且大于最大并发数

将N_THREADS从5改为3,此时有5名顾客抢购10件商品,但最多只有三名顾客在同一时刻抢购。运行结果:

56db751dad7cd8c4e003f9b480d0a525.png

5.3 总结

(1)由5.1和5.2比照可知,当客户数量小于商品数量时,并发访问量越大,客户秒杀到商品的成功率就会越低,由于并发量越大,可以进行的秒杀轮数就会越少,能抢购到商品的客户也就越少。

(2)5.1和5.2中的假设其实是不正当的,假如客户数量小于商品数量,供大于求,那也就不应该存在高并发秒杀的概念了,即便此时强行制造秒杀这个概念,但由于库存充足,所以也应该让所有客户都抢购到商品,只是抢到的先后顺序不同而已。

一个真实的网上商城的秒杀活动应该存在如下关系:客户数量(在线)>> 商品数量 > 客户并发数,举例:

由1W台手机等待秒杀,在线等待秒杀活动开始的客户数量为10W,客户并发量为3k。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值