不能直接存json字符串，因redis stream字段设计要求结构化拆分：需将日志各字段转为独立field-value，配合消费者组、xack重试及xtrim容量管控，才能保障海量日志的可查、可靠与高性能。
直接用 RedisTemplate.opsForStream().add() 往 Stream 里塞原始字符串日志，短期能跑，长期必崩——数据不可查、无法过滤、消费端易丢消息、序列化混乱，根本撑不住“海量”和“结构化”两个关键词。
为什么不能直接往 Stream 存 JSON 字符串？
看似简单：把 LogEvent 对象 new ObjectMapper().writeValueAsString() 后塞进 add("log:stream", "event", jsonStr)。但实际会踩三个坑：
- Redis Stream 的
field是 key-value 对，你传一个大 JSON 字符串当 value，等于把整个对象压成单个 field；后续用XREADGROUP拉取时，必须全量反序列化才能拿到任意字段（比如只查level == "ERROR"），CPU 和带宽浪费严重 - Stream 的天然索引是 ID（时间戳+序号），不支持按
service、traceId等业务字段做范围查询或跳读——你没法“查某服务最近10条 ERROR 日志”，只能靠客户端遍历过滤 - 如果多个字段值含特殊字符（如
"、\n、=），JSON 字符串在 Redis 协议解析阶段就可能被截断或报错，ERR Protocol error频发
正确做法：把结构化字段拆成 Stream 的 field-value 映射
让 Redis 原生理解你的日志结构，而不是把它当黑盒字符串。关键不是“存什么”，而是“怎么拆”：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
Map<string string></string>构造 entry，每个业务字段单独成 field：Map.of("level", "ERROR", "service", "order-api", "traceId", "abc123", "msg", "timeout on payment") - 调用
redisTemplate.opsForStream().add(streamKey, fieldMap)，不要传ObjectRecord或 raw string - 务必保证所有字段值都是 UTF-8 字符串；数值类型（如
durationMs）转成字符串再存，避免 Lettuce 序列化器误处理 - 推荐加一个固定 field 标识 schema 版本，例如
"v":"2"，方便后续字段变更时兼容
消费端必须用消费者组（Consumer Group），且设置 pending 重试
单靠 XREAD 无法应对海量日志的可靠消费。漏一条 ERROR 日志可能意味着线上事故没被发现：
- 初始化时用
XGROUP CREATE创建组（Spring Data Redis 对应opsForStream().createGroup()），组名建议含环境标识，如"log-consumer-prod" - 消费用
XREADGROUP GROUP {group} {consumer} COUNT 100 STREAMS {stream} >，注意末尾的>表示只读新消息 - 处理失败时，**不要删消息**，而要调用
XACK（对应acknowledge()）前先记录失败原因，再让消息留在 pending 队列中；Lettuce 默认不自动重试 pending 消息，需主动XCLAIM拉回 - 消费者实例重启后，必须先调用
XPENDING拉出未确认消息，否则丢失
性能与容量必须提前卡死边界
Redis Stream 不是日志数据库，它没有 TTL 自动清理机制，不设上限等于埋雷：
- 写入前用
XLEN监控 stream 长度，超过阈值（如 1000 万条）必须触发归档或裁剪；Spring Boot 可配@Scheduled(fixedDelay = 60000)定期执行XTRIM log:stream MAXLEN ~ 5000000 - 单条日志建议控制在 2KB 内；含大堆栈或二进制内容（如 base64 图片）的日志，应存到对象存储，Stream 中只留 URL 和 hash
- 避免用同一个 stream 存所有服务日志；按
service:env分 stream，如log:order-api:prod，否则单 stream 成为热点和瓶颈 - Redis 内存不足时，
add()会直接抛RedisSystemException，需捕获并降级写本地文件或丢弃，不能让日志逻辑拖垮主业务
真正难的不是把日志塞进 Redis，而是让每条消息可定位、可追溯、可重放，且不拖慢业务。Stream 的 field 设计、consumer group 的异常路径、内存水位的硬性管控——这三处不落地，再多的“高并发”“高性能”宣传都只是幻觉。
