Redis 几乎每小时都出现大量超时，求助

报错信息是 Timeout awaiting response (outbound=1KiB, inbound=0KiB, 5728ms elapsed, timeout is 5000ms), command=SET, next: EVAL, inst: 0, qu: 0, qs: 15, aw: False, bw: SpinningDown, rs: ReadAsync, ws: Idle, in: 76, in-pipe: 0, out-pipe: 0, serverEndpoint: 127.0.0.1:6379, mc: 1/1/0, mgr: 10 of 10 available, clientName: AppProductionEnvServer1(SE.Redis- v2.5.43.42402), IOCP: (Busy=0,Free=10000,Min=9000,Max=10000), WORKER: (Busy=236,Free=32531,Min=10000,Max=32767), POOL: (Threads=236,Queueditems=50,Completeditems=8751117254), v: 2.5.43.42402 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)

出错的时候看了下也就三百多并发，比较怀疑是下面这段代码引起的：

   while (!await redis.GetDatabase().LockTakeAsync($"PlaceOrder:{user.UserId}", "1", TimeSpan.FromSeconds(180)))
        {
            await Task.Delay(1);
        }

作用是确保同一用户只有一个订单未写入数据库（系统下单逻辑涉及几十个函数，全是一些莫名奇妙的判断逻辑，混淆后可读性大幅提升的那种（当然是开玩笑的）），屎山作者已经跑路了，没人能看懂他代码，一个用户下多个订单数据会混乱。更牛逼的这套系统除了性能极差，运行 3 年没出错一次。一次调用 API 只能下一单，客户端随硬件交付，已经写死了，不能更新，然后客户端一次多少个订单就多少并发调用 API 提交，没有队列功能。目前要求 500 订单 10 秒内全部下单完成返回订单号（单独提交的话每个订单 0.01 秒左右能写入完数据拿到订单号）。

预分配订单号行不通，不运行一遍这部分屎山代码不能确定这个订单能不能提交，返回订单号就代表这个订单提交成功了，不能取消。目前打算改造成 Sub/Pub ，不知道能不能提升性能，或者 V 友有没有更好的改造方案？只要能让这屎山跑起来就行，代码多脏都没关系，改动需要尽可能小，不能把系统改炸。目前加硬件到 256GB 内存都没解决。

8355

68 天前

我猜测了一下你的代码上下文，通过首行业务加并发锁，并且在执行到最后一个业务的时候内部有一个解锁指令。
加了个 180 秒的锁，执行到最后应该执行 del 解锁。

可以把你的订单内容，产品+数量之类的编个字符串算个 hash 加入到 rediskey 中，这样的话相同的产品并发下单才会触发锁，而不同产品下单不会受到影响。

这样改的前提是你需要把整个执行流程看一遍确认只有 2 个位置（也有可能只有一个）有锁操作，如果其他位置有锁检查一定要再看下代码逻辑。
我觉得这是最低成本改动，不牵扯到原有逻辑，可以通过搜索去检查该 key 的应用次数。