c# StackExchange.Redis 的连接管理和并发策略

ConnectionMultiplexer 必须全局单例复用，严禁每次新建或Scoped注入；IDatabase可随时获取无需缓存；异步操作必须await，禁用.Result/.Wait()；读多写少时可用CommandFlags.DemandSlave分流至从节点。

ConnectionMultiplexer 是单例，不是每次 new

StackExchange.Redis 的核心是 ConnectionMultiplexer，它本身线程安全、内置连接池和自动重连，**必须全局复用一个实例**。多次 new ConnectionMultiplexer 会导致 socket 耗尽、TIME_WAIT 暴涨、CPU 升高，甚至 Redis 服务端拒绝新连接。

常见错误是把 ConnectionMultiplexer 塞进 using 或注入为 Scoped 服务——这等于每请求建一次连接，完全违背设计初衷。

• ASP.NET Core 中应注册为 Singleton：用 services.AddSingleton(sp => ConnectionMultiplexer.Connect(configuration))
• 连接字符串里加 abortConnect=false，避免启动失败直接崩掉进程；加 connectTimeout=5000 和 syncTimeout=5000 防止阻塞过久
• 监听 ConnectionFailed 和 InternalError 事件，但别在里面做重连逻辑（multiplexer 自己会重试），适合打日志或触发告警

Database 实例可随意获取，无需缓存

IDatabase 是轻量级句柄，不持有连接，每次调用 connecti

on.GetDatabase() 都是 O(1) 开销。没必要把它存成字段或缓存起来——反而容易在多库（如 db0/db1）场景下搞混上下文。

注意：如果用了 defaultDatabase 参数（比如 GetDatabase(1)），它只影响后续命令的默认 db 编号，不会改变底层 multiplexer 行为。

• 并发读写时，多个线程共用同一个 IDatabase 实例完全安全
• 若需事务（ITransaction）或管道（IBatch），才需要显式创建新上下文，且必须在同一线程内完成提交
• 避免在异步方法中把 IDatabase 当闭包变量长期持有——没坏处，但无意义

异步 API 必须用 async/await，别用 .Result 或 .Wait()

StackExchange.Redis 的所有 *Async 方法（如 StringGetAsync、HashSetAsync）底层基于 ValueTask，**同步等待（.Result / .Wait()）极易引发死锁**，尤其在 ASP.NET Core 同步上下文受限环境里。

典型现象：接口偶尔卡住、线程池饥饿、请求堆积。这不是 Redis 慢，是线程被自己锁死了。

• Controller 或 Service 方法标记 async Task，调用链全程 await
• 不要用 Task.Run(() => db.StringGetAsync(...)).Result —— 这只是把死锁换个地方发生
• 极少数无法改 async 的旧代码（如某些 Filter），可用 db.StringGet(key) 同步版本，但它会阻塞线程，仅限低频、超短耗时场景

高并发*意 CommandFlags 和连接负载均衡

默认情况下，所有命令都走主节点（即使你配了哨兵或集群）。遇到读多写少场景，可以利用 CommandFlags 把只读命令发到从节点，减轻主节点压力：

await db.StringGetAsync("key", CommandFlags.DemandSlave);

但这有前提：Redis 配置了 slave-read-only yes，且 multiplexer 连接字符串里启用了 allowAdmin=true（仅开发/测试环境建议开启，生产慎用）。

• 集群模式（Cluster）下，DemandSlave 不生效，路由由 key hash 决定，无法手动指定节点
• 连接数瓶颈时，优先检查是否误用了 SyncTimeout 过小（导致频繁超时重试）或 AbortOnConnectFail=false 未设（启动失败静默）
• 用 IServer.ClientList() 在 Redis CLI 查当前连接数，确认是否真由客户端连接爆炸引起，而非服务端配置限制

真正难处理的，是跨多个 Redis 实例做分布式锁或事务协调时，ConnectionMultiplexer 的健康状态感知和故障转移延迟——它不会主动通知你“这个节点已永久失联”，得靠你结合 IsConnected、GetStatus() 和业务超时做兜底。

# ai  # 都是  # 多个  # 里加  # 复用  # redis  # 路由  # 并发  # 堆  # c#  # 字符串  # 接口  # .net  # 线程  # 异步  # 死锁  # 事件  # red  # 重试  # 闭包  # 负载均衡  # Filter  # database  # using  # 服务端  # 分布式  # 连接数  # 多写  # 超短 

相关栏目： <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 AI推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 SEO优化<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 技术百科<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 谷歌推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 百度推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 网络营销<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 案例网站<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 精选文章<？ｍｕｍａ echo $count; ?> 】