@dynastysea #23 这是应用问题，是代码写成这样，遇到屎山问题我没脸提工单。我怕人家让我提供代码我截出来丢老脸。

delay + random(1,20)试试？ 可以少试 10 倍请求，随机过后不容易有空闲或堵塞

循环里面 delay 的带短了吧  
拿 redis 锁之前 加个本地锁 应该会好点

这个错误信息，没什么问题，毕竟都用了异步 IOCP 也是空闲。

如果有监控且是单机 redis ，那就查查 redis 当时的连接数是不是爆了，首行提示 Timeout awaiting response 。

加锁和解锁的地方都加下日志看看 应该是死锁了

增加重试时间啊 1ms 这瓶颈是 cpu 了 你加内存什么用
redis 单线程还不能利用多核优势

https://learn.microsoft.com/zh-cn/azure/azure-cache-for-redis/cache-management-faq

还是修改锁的实现, 可重入

是不是惊群了，每次锁空闲会唤起一大批在等待的，但只有一个拿到了锁

setex 作为一个原子操作，兼顾读写，消耗较大。
300 个线程 1ms 一次，那就是 30w qps ，超时也正常。
基于这个思路改善肯定没问题。