业务是那种消费并发很高的刷礼物的那种,现在的业务实现是先查后修改用存储过程都放一起,然后返回用户余额。 想问各位大佬,不用存储过程还有别的什么方法吗?
1,悲观锁  系统要求并发高,吞吐量大,加了悲观锁 用户请求锁住行数据,每次要等待修改成功锁释放。性能下降 ,很不符合我们的场景
2,乐观锁 采用乐观锁后,可以解决这种问题,但是可能存在 ABA 问题 
3,采用CAS理论,在并发量比较高的情况下,反复尝试更新某一个变量,却又一直更新不成功,循环往复,会给CPU带来很到的压力
4,redis分布式锁  各位大佬在做这种用户并发消费扣减余额的时候 是怎么做的呀。 妈的  想了都不知道怎么搞的。

解决方案 »

  1.   

    要不你试试ThreadLocal?
      

  2.   

    我也有点好奇你们的具体业务场景是什么?
    比如抢红包,在群里经常看到刚发个红包两三秒就被抢完了,每秒几十次也是正常的,但这对于服务器CPU来说根本不算什么。即便是几百上千个这样的群同时操作也还好,最多是几秒钟的事。从你的描述来看,每次读写都用存储过程,性能瓶颈应该在数据库操作上,不能放到缓存里来做这个么。
    另外,所谓的并发操作是针对同一共享变量的,你也可以在业务上做些优化,比如礼物分成几类,一等奖多少个,用一个变量,二等奖多少个,用另一个变量,分散对同一个变量的读写压力。这样你就可以用分布式来处理了,甚至可以做到每一个变量的读写各自用一台服务器来处理都行,面向客户用一台代理服务器分发请求到这些服务器上,这样你还可以给各服务器配置请求的权重,比如大部分请求都丢给幸运奖的服务器,少部分请求给二三等奖,极少部分的请求分配到一等奖或特等奖的服务上。仅供参考。