Subscribe易丢消息是因为Redis Pub/Sub无持久化与ACK机制，断连即丢；需改用Streams或List+Pub/Sub混合模式，并配连接池与心跳保活。
为什么直接用 Subscribe 容易丢消息
StackExchange.Redis 的 ISubscriber.Subscribe 返回的是一个 IBasicSubscriber，它底层基于 TCP 连接复用和异步管道，但**不保证消息投递可靠性**。一旦客户端断连（网络抖动、Redis 重启、应用崩溃），正在传输中或刚收到未处理完的消息就彻底丢失——Redis 发布订阅本身是“即发即弃”的，服务端不会暂存未确认消息。
常见错误现象包括：本地调试时一切正常，上线后偶发收不到某条关键通知（比如订单状态变更）；或压测时批量发布后，消费者只处理了前几条。
-
Subscribe是 fire-and-forget 模式，没有 ACK 机制 - 连接断开时，
IBasicSubscriber不会自动重连并补订历史消息（Redis 本身也不支持） - 事件回调（如
OnMessage）在任意线程执行，若处理逻辑抛异常且未捕获，该消息直接消失
用 ChannelMessageQueue + 手动 ACK 模拟可靠消费
StackExchange.Redis 没有内置的“可靠订阅”抽象，但可以借助其 IConnectionMultiplexer.GetDatabase().ListLeftPush 和 ListRightPop 构建一个带持久化缓冲的消费者队列。核心思路是：让订阅者只做一件事——把收到的每条消息立刻落库到 Redis List（作为临时队列），再由另一个独立工作线程从该 List 中取、处理、成功后再 ListLeftPop 或标记已处理。
这样即使消费者进程崩溃，未处理的消息仍在 List 中，重启后可继续拉取。
- 发布端保持不变：
subscriber.Publish("order:status", "order_123:shipped") - 订阅端改用
Subscribe接入原始消息，但不做业务逻辑，只做db.ListLeftPush("queue:order_events", message) - 另起一个
Task.Run(() => ProcessQueueLoop())，循环执行：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 在首次连接失败时会抛出异常并终止整个连接实例。对于发布订阅这种长生命周期场景，这会导致订阅完全中断且无法自动恢复。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
必须显式配置连接字符串或 ConfigurationOptions：
var options = new ConfigurationOptions
{
EndPoints = { "localhost:6379" },
AbortOnConnectFail = false,
ReconnectDelay = TimeSpan.FromMilliseconds(500),
ConnectTimeout = 5000,
SyncTimeout = 5000
};
否则你会遇到：StackExchange.Redis.RedisConnectionException: No connection is available to service this operation，且后续所有 Subscribe 调用都静默失败。
-
AbortOnConnectFail=false是底线，否则重连逻辑根本不会触发 -
ReconnectDelay建议设为 300–1000ms，太短可能触发 Redis 连接风暴 - 不要依赖
ConnectionMultiplexer.IsConnected判断状态——它返回 true 仅表示“曾经连过”，实际连接可能已断
如何避免重复消费和顺序错乱
Redis 发布订阅本身不保证顺序（多 subscriber 时）、也不防重（网络重传、客户端重连后重复订阅）。靠应用层收敛：
- 消息体里必须带唯一 ID（如
Guid.NewGuid().ToString()）和时间戳，消费者入库前先查SETNX processed:{id} 1 EX 3600，失败则跳过 - 如果业务强依赖顺序（如订单状态流转：created → paid → shipped），不要依赖订阅接收顺序，改用 Redis Stream（
XADD/XREAD），它原生支持 consumer group、ACK 和按 ID 有序读取 - 别在
OnMessage回调里直接写 DB 或调远程 API——回调线程不可控，容易堆积或并发冲突；务必转成队列异步处理 - 日志必须记录每条消息的 ID、接收时间、处理结果，否则问题发生时无法追溯是丢了、重复了，还是卡在中间件
真正麻烦的不是代码怎么写，而是你得想清楚：这条消息丢了能不能接受？重复了业务会不会双扣款？顺序错了系统状态会不会不一致？这些决定了你该用 Pub/Sub、Stream 还是干脆换 RabbitMQ。
