StackExchange.Redis 是 .NET 平台下被广泛采用的 Redis 客户端之一，它在设计上与传统数据库驱动有本质区别。传统方式下每执行一个命令要么新建一个连接，要么从连接池借出一个连接，而 StackExchange.Redis 通过内部的 ConnectionMultiplexer 对象把多个逻辑请求复用到同一条物理 TCP 连接上。这样做的好处是客户端占用的套接字数量大幅下降，Redis 服务端也不需要频繁处理连接握手与断开，从而能把更多 CPU 时间留给实际数据操作。不过这套机制引入了一些新的使用约束，比如必须维持单例连接、避免同步阻塞异步调用等，如果忽略这些约束，性能不但不会提升，反而会出现间歇性的超时异常。

本文从连接模型、命令执行、序列化策略和性能调优四个角度展开，帮助读者在真实项目中更稳妥地落地这套客户端。

多路复用机制与单例连接的必要性

StackExchange.Redis 的核心类是 ConnectionMultiplexer。它内部维护着一个到 Redis 服务端的物理连接，并将所有命令请求封装成异步消息队列，通过单个套接字批量发送。Redis 服务端也会按照请求顺序处理并返回结果，客户端再根据命令标识把结果分发给对应的异步任务。这种模式与 HTTP 的复用类似，但比简单的连接池更进一步：连接池减少的是连接创建开销，而多路复用减少的是连接数量本身。

因此，ConnectionMultiplexer 应当被创建为全局单例。如果每次数据库操作都调用 Connect 创建一个新实例，每创建一个实例就会建立一条独立连接，多路复用的优势将完全丧失，应用会退化为最原始的一命令一连接模式，在高并发下立刻出现连接数暴涨甚至服务端拒绝连接。常见的做法是在应用启动时创建一次，然后通过依赖注入或静态属性共享给所有业务代码。

var config = new ConfigurationOptions
{
    EndPoints = { "localhost:6379" },
    AbortOnConnectFail = false,
    ConnectTimeout = 5000,
    SyncTimeout = 3000,
    KeepAlive = 60
};
var conn = ConnectionMultiplexer.Connect(config);
var db = conn.GetDatabase();

这段代码中的 AbortOnConnectFail 设置为 false 很重要。默认情况下，如果初始连接失败，客户端会抛异常并阻止启动；而设置为 false 后，客户端会静默重试，这更适合需要依赖外部缓存但不希望启动就失败的系统。连接字符串选项里 SyncTimeout 控制同步命令的最大等待时间，不要设得过小，否则正常命令也会触发超时。

常用命令与异步方法的正确使用

StackExchange.Redis 提供了一套与 Redis 命令高度对应的 API。字符串、哈希、列表、集合等类型都有对应的同步和异步方法。异步方法以 Async 结尾，返回值是 Task 类型。推荐在业务代码中优先使用异步方法，因为它可以让等待网络响应的 CPU 时间释放出来处理其他请求，尤其适合 .NET Core 和 .NET 5 及以上版本的异步管道。

以字符串和哈希为例，存储用户信息时可以先用 StringSetAsync 写入序列化后的 JSON，再用 HashSetAsync 存储经常需要单独更新的字段。下面的示例演示了这两种方式的差异和应用场景。哈希结构适合频繁修改某个字段而不需要整体重新序列化，字符串结构适合整体读取、写入频率不高的场景。

// 字符串方式
await db.StringSetAsync("user:1001", "{\"name\":\"张三\",\"age\":30}", TimeSpan.FromMinutes(30));
string json = await db.StringGetAsync("user:1001");
// 哈希方式
await db.HashSetAsync("user:1001", new HashEntry[] {
    new HashEntry("name", "张三"),
    new HashEntry("age", 30)
});
string name = await db.HashGetAsync("user:1001", "name");

另一个高频需求是批量执行多个命令。虽然 StackExchange.Redis 的单连接已经能并行发送，但框架并不能自动把所有语句合并成一个网络包。要实现真正的管道，需要创建 IBatch 或 ITransaction。这两种接口可以收集多个命令，最后一次性发送给 Redis。区别在于事务会加上 MULTI/EXEC 语义，保证原子性，而批量不会。

var batch = db.CreateBatch();
var task1 = batch.StringSetAsync("a", "1");
var task2 = batch.StringSetAsync("b", "2");
batch.Execute();
await Task.WhenAll(task1, task2);
var trans = db.CreateTransaction();
var t1 = trans.StringIncrementAsync("counter");
var t2 = trans.KeyExpireAsync("counter", TimeSpan.FromMinutes(10));
bool committed = await trans.ExecuteAsync();

序列化策略与缓存一致性

Redis 不关心存进去的字符串具体含义，所有数据最终都是字节序列。这意味着客户端必须自己决定如何把对象转换成字节。很多开发者在测试时习惯直接 StringSetAsync("key", "value") 存字符串，但当对象变成复杂类型时，如果没有统一序列化，就会出现乱码或类型转换异常。比较推荐的方案是在客户端封装一层仓储接口，统一使用 System.Text.Json 或 MessagePack 进行序列化。

以 System.Text.Json 为例，可以在写入前调用 JsonSerializer.SerializeAsync 或同步版本，将对象转成字符串再存入 Redis。读取时反序列化为目标类型。需要注意的是，当对象包含枚举、日期或需要忽略 null 字段时，应该提前配置 JsonSerializerOptions，避免不同端使用不同序列化配置导致缓存命中失败。

var options = new JsonSerializerOptions
{
    PropertyNameCaseInsensitive = true,
    DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
};
string json = JsonSerializer.Serialize(user, options);
await db.StringSetAsync("user:1001", json, TimeSpan.FromMinutes(30));
string cached = await db.StringGetAsync("user:1001");
if (cached is not null)
{
    var user = JsonSerializer.Deserialize<User>(cached, options);
}

缓存一致性问题通常出现在数据库更新后缓存未失效。常见做法是在写入数据库后主动删除对应缓存，或者使用较短过期时间作为兜底。对于热点数据，可以结合互斥锁防止缓存击穿。StackExchange.Redis 本身提供了 LockTakeAsync 和 LockReleaseAsync 方法，可以用来实现简单的分布式锁，控制同一时刻只有一个请求去重建缓存，其他请求等待或返回旧值。这种方法虽然不能完全解决一致性问题，但能有效降低数据库压力。

超时与性能调优的常见坑

使用 StackExchange.Redis 时，最让人头疼的异常是 TimeoutException。触发原因往往不是 Redis 本身慢，而是客户端内部队列积压、线程池饥饿或者同步阻塞。例如在异步方法后调用 .Result 或 .Wait()，会同步阻塞当前线程，导致多路复用回调无法及时处理，后续命令全部排队超时。在 ASP.NET 应用中尤其需要注意：同步阻塞会消耗线程池线程，进一步放大超时范围。

要缓解线程池饥饿，可以在应用启动时设置最小线程数。对于 .NET Core 或 .NET 5 以上版本，可以通过 ThreadPool.SetMinThreads 来调整。另一个常见问题是单个 value 过大，如果序列化后达到几 MB，每次网络传输和反序列化都会显著增加时间。建议将大对象拆分成多个哈希字段，或者将文件类数据存到对象存储，Redis 中只保留路径和元信息。

ThreadPool.SetMinThreads(200, 200);
var config = new ConfigurationOptions
{
    EndPoints = { "localhost:6379" },
    SyncTimeout = 5000,
    ConnectTimeout = 5000,
    AbortOnConnectFail = false,
    KeepAlive = 60,
    ClientName = "order-service"
};

此外，避免在线上环境直接使用 KEYS 命令，它会阻塞 Redis 的事件循环。如果需要遍历所有键，应使用 SCAN。在排查慢命令时，可以通过 SLOWLOG GET 查看服务端的记录。客户端方面，连接字符串中的 ClientName 可以帮助定位连接来源，这在多服务共享 Redis 时非常有用。

总的来说，StackExchange.Redis 本身已经足够成熟和高效，大部分性能问题都来自使用方式。保持单例连接、优先异步调用、统一序列化、合理设置超时，这四点做到位后，生产环境的表现通常都会比较稳定。