redis 并发锁的疑问 可以给个方案嘛

[zjj911]

业务场景：
1.现在有一个活动资源金额，但是需要实时计算。（其中包括金额使用和退还）
比如活动1 设置总金额10000，用户参加活动，但是不同的条件使用的活动金额不同，没法全部缓存。
2.活动金额的使用是在分布式机器服务上的，防止并发消耗产生资源数量超限问题，和回退金额，我这边做了redis的分布式锁，使用的是setnx，getset的方式
问题：
1.金额消耗和回退我都先加锁，完成业务逻辑后释放锁，正常消耗一单大概需要10ms左右，退单全流程在20ms左右
2.问题是高并发的时候，第一个线程在处理消耗、退单时，第二个和其它线程全部等待。
第一个线程处理完，第二个线程处理，第三个线程和之后的继续等待。
以此场景等待，比如100个消耗线程，虽然单次处理时间不慢，但是等到第100个线程进行消耗时，此时等待时间已经不能接受了。
3.实际场景线上并发没那么高，也就30了不起了，但是最坑爹的是公司有要求，得抗200并发，循环进行200并发压测，扛不住啊，现在会后面直接爆超时
求解：
遇到这样的场景，我能从什么方面进行处理，中间的消耗、恢复已经很优化了没什么优化空间了。
有什么方案嘛，给点建议，或者方向吧，谢谢大拿们啊。

[Mechnaic]

http://www.cnblogs.com/candychen/p/5736128.html

[zjj911]

引用 1 楼 Mechnaic 的回复:

http://www.cnblogs.com/candychen/p/5736128.html

然而我并没明白这个的作用在哪， 用不用队列有区别嘛 我理解的用队列，出队第一个数据，业务处理，比如20ms，那队列里的99个并发是不是也还是等待， 然后是第二个，第三个。。。 那从第100个请求的开始，到等到第100进行处理理论前面99个就至少消耗99*20=1980ms=1.9s了，这还是业务处理优化的非常好了，如果一个业务处理需要100ms，200并发，那最后的请求等待的时间就很长了。 其实我求教的是，这样的等待场景，有什么别的设计方案和技术方案，解决或者优化这种等待

[zjj911]

引用 3 楼 baidu_38649964 的回复:

我知道您说的意思,这就是一个多线程的问题.解决办法只有继续增加线程,减小同步的代码块,或者写一次同步函数专门处理金额,你看一下这样会不会快一点,要不就将此活动单独打包,放在独立的服务器上.如果有效果了请告诉我,欢迎私信一起讨论.

这个不是单独的线程问题，是线程加锁的问题，相当于所有的线程需要在锁的业务逻辑处变成单线程 1.增加线程 那后面的线程等待不是更严重 2.我现在20ms 已经没办法了，处理业务逻辑怎么也要一点时间的吧 3.同步函数专门处理金额 暂时没明白这个同步函数的意思具体是指什么 4.这个现在服务器性能是ok的

[正怒月神]

你既然加了锁， 理所应当的线程进来就要排队。 不知道读写分离，对你有没有用

[baidu_38649964]

我知道您说的意思,这就是一个多线程的问题.解决办法只有继续增加线程,减小同步的代码块,或者写一次同步函数专门处理金额,你看一下这样会不会快一点,要不就将此活动单独打包,放在独立的服务器上.如果有效果了请告诉我,欢迎私信一起讨论.

[baidu_38649964]

建议你测试一下同步代码块的单线程运行时间,是不是像你所说的都卡在这里了.

[笑為紅顏苦為誰]

亲，最后是怎么解决的。。求学习下。。

[JamesCang]

我觉得可以多线程+自旋+乐观锁更新