代金券锁券优化方式

有一个用券逻辑，券有金额/剩余金额属性。并发场景有很多请求使用同一张券，我用到了 select for update 的方式进行锁券，当一个请求消耗完券之后，update 记录（券剩余金额），然后会释放锁，下一个请求再继续用券。

但现在同一张券，券金额比较大且并发场景的情况下，某些请求耗时会比较长，因为等待锁释放

请教下，这里有什么优化点么，合并请求之类的改动太大，需要上游配合

我完全不懂，但是按金额切分券，分别锁，闲时再合并？

@yankebupt 可能没说清 1. 券可以用多次 2. 用券请求是并发的 所以会出现一张券要被并发使用多次的情况。因为要修改剩余金额，所以需要给券加锁，但加了锁之后，等待锁释放的请求又会慢一些

券不是发放到个人账户上然后消费吗？ OP 问的是发的券超库存了吗？

券余额也是余额, 所以你要问的是并发余额怎么减. 问题是单用户会有并发么? 如果是全局有一个“该券能用多少次、最多全局抵多少钱”. 那就是减库存问题了. 最好的就是落到缓存,然后用队列按顺序处理.

当用户从页面点选那张优惠券还没有提交时，立刻把券切成两张，并锁住相应金额的那张，如果用户提交，就更新，如果不更新页面关闭了，把两张券再合起来......

或者你也可以提供一个功能让用户自己切然后一张一张用（很丑陋，但代码最少

1 、内存队列（或者 MQ ），排队对单券扣减，减少无畏的 CPU 消耗、加解锁消耗 2 、使用 Redis 的 decrby 进行扣减，通过内存扣减提升性能 3 、如果是多次的金额相同，还可以使用券预置拆分策略，减少锁竞争

就是类似京东的 e 卡 说是卷 就是一个单独的存储余额

用 redis 缓存剩余金额，直接在 redis 中 decrby 可行吗？