Redis Streams 用 XADD 存操作日志最直接，天然按毫秒级时间戳排序，支持 XREAD/XRANGE 按时间范围查询，需设 MAXLEN 防爆涨，多服务通过 consumer group 共享且互不干扰，持久化依赖 AOF 配置。
Redis Streams 怎么存操作日志
用 XADD 往 Stream 写日志最直接，它天然按时间戳排序，不需要自己维护序号或加锁。每次写入自动带毫秒级时间戳（如 1718234567890-0），后续用 XREAD 或 XREVRANGE 拉取时，顺序就稳了。
常见错误是把日志当普通字符串塞进 SET 或 LPUSH：一来没时间维度，二来并发写可能乱序，三来没法按时间范围查。Streams 是 Redis 唯一原生支持「追加+有序+可回溯」的日志结构。
-
XADD的第一个参数是 Stream 名（比如log:auth），第二个参数建议用*让 Redis 自动生成时间戳 - 字段名别用空格或二进制字节，
XADD log:auth * action login user_id 123 ip 192.168.1.5这样安全 - 单条日志不宜超过 4KB，大日志先压缩或拆成多段，否则影响
XREAD吞吐
怎么查某段时间的操作记录
用 XREVRANGE 倒序查最近 N 条，或者用 XRANGE 正序查某个时间窗口——关键在时间戳格式要对。Redis 时间戳是「毫秒 + 序号」组合，但查范围时可以只写毫秒部分，比如 1718234567000 到 1718234568000。
容易踩的坑：时间戳填成秒级（少三位）会导致查不到；用字符串比较（如 "1718234567"）会因字典序错乱；还有人误用 XRANGE 查未来时间，结果返回空却以为数据丢了。
- 查最近 10 条：
XREVRANGE log:auth + - COUNT 10 - 查 2024-06-13 10:00 到 10:05 的记录：先算毫秒时间戳，再执行
XRANGE log:auth 1718244000000 1718244300000 - 生产环境建议给 Stream 设上限，用
MAXLEN ~10000防止无限增长，~表示近似裁剪，性能更好
多个服务怎么共用一个日志 Stream
靠 consumer group 实现。不同服务作为独立 consumer（比如 svc:payment、svc:notify），各自维护读取位置，互不干扰。不用自己存 offset，Redis 全托管。
典型翻车点：没建 group 就直接 XREADGROUP，报错 NOGROUP No such key or consumer group；或者多个实例用同一个 group name 却没区分 consumer name，导致消息被重复 ack 或漏处理。
- 首次创建 group：
XGROUP CREATE log:auth mygroup $ MKSTREAM（$表示从最新开始） - 服务 A 读取：
XREADGROUP GROUP mygroup svc_a COUNT 10 STREAMS log:auth >（>表示新消息） - 处理完必须
XACK，否则下次还会拉到同一批；不ACK的消息会在PENDING列表里堆积
Stream 日志能持久化吗？宕机丢不丢
和 Redis 其他数据一样，取决于你的持久化配置。AOF 开启且设为 everysec 或 always，日志基本不丢；RDB 快照本身不包含 Stream 的增量写入，纯 RDB 模式下断电可能丢最后几秒。
容易被忽略的是：Stream 的 MAXLEN 裁剪发生在内存，但裁剪后的数据仍会记入 AOF。如果 AOF 重写频繁，可能放大磁盘 I/O；另外，XAUTOCLAIM 处理死 consumer 时，若没配好超时时间，可能把本该丢弃的消息又捞回来。
真正复杂的地方在于权衡：要强一致性就得开 AOF everysec + 同步刷盘，但吞吐下降；想高性能就接受秒级丢失风险。没有银弹，得看你的日志是用来审计还是仅作调试。
