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<iconnectionmultiplexer>(sp => ConnectionMultiplexer.Connect(configuration))</iconnectionmultiplexer> - 连接字符串里加
abortConnect=false，避免启动失败直接崩掉进程；加connectTimeout=5000和syncTimeout=5000防止阻塞过久 - 监听
ConnectionFailed和InternalError事件，但别在里面做重连逻辑（multiplexer 自己会重试），适合打日志或触发告警
Database 实例可随意获取，无需缓存
IDatabase 是轻量级句柄，不持有连接，每次调用 connection.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<t></t>，调用链全程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 查当前连接数，确认是否真由客户端连接爆炸引起，而非服务端配置限制
ConnectionMultiplexer 的健康状态感知和故障转移延迟——它不会主动通知你“这个节点已永久失联”，得靠你结合 IsConnected、GetStatus() 和业务超时做兜底。 
