StackExchange.Redis 连接字符串怎么写才有效
直接用
ConnectionMultiplexer.Connect("localhost:6379") 最常见，但生产环境必须加超时和重连控制。不设 connectTimeout或
syncTimeout，一卡就是几秒；不配
abortConnect=false，启动时 Redis 暂不可用会导致整个应用初始化失败。
推荐写法：
var configuration = "localhost:6379,connectTimeout=5000,syncTimeout=5000,abortConnect=false,keepAlive=30";
abortConnect=false是关键：允许连接器后台自动重连，而不是抛异常中断
keepAlive=30防止 NAT 或防火墙断掉空闲连接 若 Redis 启用了密码，必须加
password=xxx，且不能放在 URL 里（会误解析）
ConnectionMultiplexer 是单例还是每次 new
必须单例复用 —— 它本身是线程安全的，内部维护连接池和订阅通道。每次
new ConnectionMultiplexer或反复
Connect()会快速耗尽 socket、触发
SocketException或
TimeoutException。
正确姿势：
private static readonly Lazy<ConnectionMultiplexer> LazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
return ConnectionMultiplexer.Connect(configuration);
});
public static ConnectionMultiplexer Connection => LazyConnection.Value;
用 Lazy<t></t>延迟初始化，避免静态构造函数阻塞 不要在 Web API 的每个请求里 new 一个，也不要封装成 Scoped 服务（ASP.NET Core DI 默认 Scoped 生命周期太短） 应用退出前调用
Connection.CloseAsync()，但通常可忽略（进程结束时 OS 会回收）
IDatabase.Get 和 GetStringAsync 区别在哪
IDatabase.StringGet()是底层通用方法，返回
RedisValue类型；
GetStringAsync()是扩展方法，内部调用
StringGet()后再做
.ToString()转换 —— 看似方便，但有隐式风险。 如果键不存在，
StringGet()返回
RedisValue.Null，而
GetStringAsync()会返回
null string，容易掩盖“空值存入”和“键不存在”的语义差异 如果存的是非 UTF-8 编码二进制数据（比如 Protobuf），
GetStringAsync()强转会乱码或抛
ArgumentException性能上无差别，但语义清晰性优先：建议统一用
StringGet()+ 显式判断
result.IsNull
如何安全地处理 Redis 连接断开和命令失败
StackExchange.Redis 不会自动重试命令，网络闪断或主从切换期间，
StringSet()可能抛
RedisServerException、
RedisConnectionException或直接 timeout。靠 try-catch 捕获所有异常并重试是错的 —— 某些失败（如
READONLY错误）重试毫无意义。 先检查
ConnectionMultiplexer.IsConnected，但注意它只反映连接状态，不保证命令可达 对幂等操作（如
StringSet(key, value, when: When.Always)）可加简单重试（最多 2 次），用
Task.Delay()避免雪崩 对事务（
ITransaction）或 Lua 脚本，失败即终止，不应重试 —— 它们本身是原子的，重试可能破坏一致性 真正要监控的是
ConnectionMultiplexer.ErrorMessage和日志中的
PhysicalConnectionFailed事件
最常被忽略的一点：默认配置下，连接器在后台检测到服务器不可达后，不会立即刷新拓扑，可能导致几分钟内持续往已下线节点发请求。启用
allowAdmin=true并配合
CONFIG GET心跳可缓解，但更稳的方式是结合 Redis Sentinel 或 Cluster 配置自动发现。
