```作用是确保同一用户只有一个订单未写入数据库```

这句话怎么怪怪的，用户的订单不是都应该写入数据库吗？

如果确定是卡死了 redis ，业务要求就是如此的话，感觉要么增大等待时间，锁的粒度是不是也可以变小一点例如上面提到了 hash ，不知道上集群会不会有改善，要么就上队列来搞

有使用 StackExchange.Redis.Extensions 这个包吗? 有个话把 poolSize 改成 1 试试。
https://www.cnblogs.com/cmt/p/16405164.html

还有个不是办法的办法，如果你们能在 load-balancer 里自定义一个按 user-id hash 的策略，那可以考虑把分布式锁干掉

看下 jstack ，看下主、副、pub/sub 线程卡在哪里？ refer： https://mp.weixin.qq.com/s/t040fhPDPzQ3EeZo1_yp8A

@drymonfidelia delay 50 你觉得长，可以先试试 10 ，5, 3 哪怕是 2 都减少了一半的并发啊

是不是连接池耗尽了，循环等待过程中一直持有连接没归还？

感觉是锁的实现问题，你把 delay 改下，等待一次时间翻倍，最多等 50ms

先抓包确定是否是 redis 慢了还是应用问题 假设是 redis 分析 cpu 使用然后 pprof 去打热点

EVAL 执行了什么逻辑？