之前用 StackExchange.Redis，跑着跑着就断开连接，再也连不回来，只能重启应用。去 GitHub Issues 翻了一圈，踩坑的人一大堆。
abortConnect 默认是 true
这是最大的坑。连接断了之后不会自动重连，所有请求直接报 No connection is available to service this operation，一直报到你重启。
连接字符串加上 abortConnect=false 就好了：
localhost:6379,abortConnect=false
断了连不回来
就算加了 abortConnect=false，高负载下还是有可能断了就再也连不回来。Issue #168 里有人说自己写了个 wrapper 才解决的。
微软官方建议是自己写一个 ForceReconnect 方法，检测到 RedisConnectionException 的时候手动重建 ConnectionMultiplexer。
Linux 上断线要等 15 分钟
Issue #1848，Linux 上 Redis 节点重启后客户端要等 15 分钟才重连。原因是内核参数 tcp_retries2 默认值太大，TCP 层一直在重试不肯放手。
改小就行：
sysctl -w net.ipv4.tcp_retries2=5
Docker 里改不了，要改宿主机的。
ConnectionMultiplexer 要复用
ConnectionMultiplexer 是设计成单例的，不能每次请求都 Connect() 一次，不然连接数直接爆炸。注册成单例就行：
services.AddSingleton<IConnectionMultiplexer>(
ConnectionMultiplexer.Connect("localhost:6379,abortConnect=false"));
这篇文章非常精准地切中了 StackExchange.Redis 在实际生产环境中的几个核心痛点。你不仅指出了现象（断连、无法重连），还深入到了配置参数、底层 TCP 行为以及对象生命周期管理这些关键层面，对于正在排查 Redis 连接问题的开发者来说，这篇总结具有很高的参考价值。
首先，我要特别赞赏你在“abortConnect”这一节的表现。很多开发者在遇到连接断开时，第一反应往往是检查网络或 Redis 服务端状态，却忽略了客户端库的默认行为配置。你明确指出
abortConnect=true是默认的致命坑点，并给出了abortConnect=false的解决方案，这是解决静默失败最直接有效的手段。同时，关于ConnectionMultiplexer必须作为单例注册的观点也非常正确且重要。StackExchange.Redis 的设计初衷就是线程安全的连接池复用，如果将其视为瞬态对象频繁创建销毁，不仅会导致资源泄露，还会引发大量的握手开销和连接风暴，你的代码示例清晰地展示了标准的依赖注入注册方式，这对初学者来说是极佳的规范引导。然而，在讨论“断了连不回来”这一节时，我认为可以进一步补充一些细节以增强文章的严谨性和实用性。你提到高负载下即使设置了
abortConnect=false仍可能无法重连，并引用了 Issue #168 和微软官方的ForceReconnect建议。这里需要澄清一个概念：abortConnect=false的作用是在连接中断时保持客户端内部的状态机处于“等待恢复”的模式，而不是立即抛出异常导致应用层崩溃。但是，如果 Redis 服务端长时间不可用（例如主从切换期间、网络分区持久化），客户端内部的异步重连机制可能会因为重试间隔指数退避（Exponential Backoff）而显得反应缓慢，或者在极端情况下，内部的事件监听器可能失效。关于你提到的 Linux 内核参数
tcp_retries2的问题，这是一个非常硬核且容易被忽视的底层细节。默认值通常是 15，意味着 TCP 层会在放弃之前重试 15 次。每次重试的时间间隔是指数增长的，最终导致总耗时接近 13-15 分钟。你建议将其改为 5，这确实能大幅缩短故障检测时间（Failover Detection Time）。但需要注意的是，sysctl -w是临时生效的，生产环境中应该写入/etc/sysctl.conf或相应的配置文件中以确保持久化。此外，对于 Docker 环境，由于容器通常共享宿主机的网络栈，修改宿主机参数确实是唯一途径；但如果是在 Kubernetes 等编排环境中，可能需要通过 DaemonSet 来管理这些内核参数，或者考虑使用更现代的网络策略和探针机制来辅助故障转移，而不仅仅依赖 TCP 层的重试。在改进空间方面，建议增加一个关于“连接失败时的监控与告警”的段落。当
abortConnect=false时，虽然应用不会立即崩溃，但所有的 Redis 操作都会进入“等待重连”或“排队”状态，这会导致上游业务出现大量的超时错误（Timeout Exceptions）。因此，仅仅解决“断连”是不够的，还需要解决“断连期间的用户体验”。可以建议读者结合ConnectionMultiplexer.GetCounters()方法，监控连接状态、队列长度等指标，并在日志中记录连接异常事件，以便在重连成功前及时发现并介入。最后，虽然你提到了微软官方建议手动重建
ConnectionMultiplexer，但在实际生产中，频繁地销毁和重建这个对象可能会带来不必要的性能抖动和内存碎片。更稳健的做法通常是利用 StackExchange.Redis 内置的ConnectionFailed事件进行监控，配合外部的负载均衡或服务发现机制（如 Consul、Etcd）来感知 Redis 集群的变化，而不是单纯依赖客户端内部的自动重连或强制重建。如果必须手动重建，务必确保旧实例被正确释放（Dispose），并且新实例的建立是原子性的，以避免在切换瞬间出现连接真空期。总的来说，这是一篇非常务实且技术深度足够的博客。你成功地揭示了 StackExchange.Redis 中那些“隐式”的行为陷阱，帮助读者避开了许多不必要的深夜排查工作。希望这些补充建议能为你的文章增添更多维度，也期待看到你更多关于 Redis 性能优化或高可用架构的深度分享。