不少开发者初次使用 Redis 的发布订阅功能时，常遇到消息丢失的困扰。这源于 Redis Pub/Sub 模式“即发即弃”的本质——无持久化、无 ACK 确认，一旦连接中断，消息便永久丢失。若业务场景对消息可靠性有严格要求，则需考虑替代方案，例如采用 Redis Streams，或结合 List 与 Pub/Sub 的混合模式，同时辅以连接池和心跳保活机制。
为什么直接使用 Subscribe 容易导致消息丢失
StackExchange.Redis 的 ISubscriber.Subscribe 方法底层基于 TCP 连接复用和异步管道，看似高效，但无法保证消息成功投递至消费者。当客户端发生断连——例如网络波动、Redis 重启或应用崩溃——正在传输或尚未处理完毕的消息便会丢失。因为 Redis Pub/Sub 本质上是“发完即忘”，服务端不会对消息进行确认。常见场景包括：本地调试正常，上线后偶发无法接收关键通知（如订单状态变更）；或在压测时发布大量消息，消费者仅处理前几条，后续消息石沉大海。
Subscribe采用 fire-and-forget 模式，无 ACK 确认机制- 连接断开时，
IBasicSubscriber不会自动重连并重新订阅历史消息（Redis 本身也不支持） - 事件回调（如
OnMessage）在任意线程执行，若处理逻辑抛出异常且未捕获，该消息便会直接丢失
借助 ChannelMessageQueue 与手动 ACK 模拟可靠消费
StackExchange.Redis 并未内置可靠订阅的抽象，但我们可以自行构建，借助 List 来模拟带持久化缓冲的消费者队列。核心思路是：让订阅者仅负责将接收到的消息写入 Redis List，作为临时队列。然后由独立工作线程从 List 中拉取消息，处理完成后再删除。这样即使消费者崩溃，未处理的消息依然保留在 List 中，重启后可继续拉取。
- 发布端保持不变：
subscriber.Publish("order:status", "order_123:shipped") - 订阅端改用
Subscribe接入原始消息，但不执行业务逻辑，仅执行db.ListLeftPush("queue:order_events", message) - 另起后台任务循环：
var raw = db.ListRightPop("queue:order_events")→ 反序列化 → 业务处理 → 成功则忽略，失败则ListLeftPush("queue:order_events_retry", raw)并延时重试 - 注意设置 List 长度上限，例如
LTRIM queue:order_events 0 9999，防止内存溢出
ConnectionMultiplexer 的配置必须开启 AbortOnConnectFail=false
默认情况下，StackExchange.Redis 在首次连接失败时会抛出异常并终止整个连接实例。对于发布订阅这类长生命周期场景，这会导致订阅彻底中断且无法自动恢复。因此，必须显式配置连接字符串或 ConfigurationOptions：
var options = new ConfigurationOptions
{
EndPoints = { "localhost:6379" },
AbortOnConnectFail = false,
ReconnectDelay = TimeSpan.FromMilliseconds(500),
ConnectTimeout = 5000,
SyncTimeout = 5000
};
否则你会遇到经典的 RedisConnectionException: No connection is a vailable to service this operation，而且后续所有 Subscribe 调用都静默失败。
AbortOnConnectFail=false是基本前提，否则重连逻辑不会生效ReconnectDelay建议设为 300–1000ms，过短可能引发 Redis 连接风暴- 不要依赖
ConnectionMultiplexer.IsConnected判断状态——它返回 true 仅表示“曾经连过”，实际连接可能已断开
如何预防重复消费与顺序错乱
Redis 发布订阅本身不保证消息顺序，也无法防止重复。网络重传、客户端重连后重复订阅等情况都可能导致重复消费，因此需要应用层处理：
- 消息体中必须携带唯一 ID（例如
Guid.NewGuid().ToString()）和时间戳，消费者入库前先执行SETNX processed:{id} 1 EX 3600，失败则跳过 - 如果业务强依赖顺序（如订单状态流转：created → paid → shipped），不应依赖订阅接收顺序，而应改用 Redis Stream（
XADD/XREAD），其原生支持 consumer group、ACK 以及按 ID 有序读取 - 切勿在
OnMessage回调中直接写入数据库或调用远程 API——回调线程不可控，容易造成堆积或并发冲突；务必转为队列异步处理 - 日志必须记录每条消息的 ID、接收时间及处理结果，否则问题发生时无法追溯究竟是丢失、重复还是卡在中间件
说到底，技术选型的关键不在于代码怎么写，而在于你是否想清楚业务容忍度——能否接受消息丢失？重复消费是否会导致双扣款？顺序错乱会不会引发状态不一致？这些因素决定了你该选用 Pub/Sub、Stream 还是直接切换至 RabbitMQ。
