@testcgd delay 的方案有一点效果，但是一次性订单少的情况变得更慢了

@sampeng 不是 node ，是 .net

不需要关注车次 我记得日本新干线就是这样的，起点站终点站对，随便上哪班车都行

这算什么，我还接触过后台纯前端鉴权的商城项目，被黑了好几次，最后加了个 basicauth 解决

@EscYezi 看错误消息，连接池应该还是有很多空闲的

@antli 以前就考虑过 minThreads 的问题，把 minThreads 调大了，没解决，后面调到非常大，像上面的错误消息里的那样，还是不行

@abccccabc 6.0.16 ，不敢更新

@abccccabc 就是确保同一用户只有一个订单正在写入数据库的意思
@8355 我看到他的代码后一个订单有引用前一个订单的数据，同时下多个订单确实会出问题。逻辑实在太混乱了，有几处我都看不懂，实在不敢改

@drymonfidelia 另外 1ms 也不一定能拿到锁

@sagaxu 不能直接乘吧，拿到锁的请求就不会继续申请锁了

@lsk569937453 redis 服务端不是单线程运行的么，客户端从上面的报错信息看线程池还有很大空闲

@sagaxu 但是这个 timeout 似乎是 redis 被卡死了，一次加锁尝试一直没返回结果

@chenqh 每个任务结束后都要释放锁才能进入下一个任务，我觉得问题出在频繁加锁上。

@drymonfidelia #14 但是不知道这样弄性能会不会更差，一条 SET 命令能解决的问题我要 SUB 几百次

@keakon 当时的需求文档已经没了。我觉得这么混乱的逻辑他能弄到没问题还是有点水平的
@chenqh 在下单结束的时候

@lsk569937453 是，但是我需要确保前一个锁释放到加下一个锁的间隔尽可能最短。目前我的想法是如果没加锁成功，Sub 一个锁名称的 Channel ，每个锁释放就 Pub 一条消息，Sub 收到消息就再尝试加锁

@javalaw2010 没有，redis 里面全是锁和缓存，丢了重启就好，不需要备份

@sujin190 谢谢，我看一下