Redis Streams 不用于实时拦截穿透，而是记录请求行为供归因分析与策略触发；需配合外部服务实现熔断或封禁，XADD/XTRIM 构建低开销日志流水线，按 IP 和 key 字段聚合识别穿透特征。
Redis Streams 本身不直接用于拦截穿透，而是做异常行为归因与策略触发
Streams 不是限流或过滤组件，它不能替代布隆过滤器或滑动窗口限流。它的价值在于：把“谁在查什么、查了多少次、时间戳精确到毫秒”这些原始行为落盘，供后续分析或联动其他防护模块。一旦发现某 IP 在 10 秒内对 user:-1、sku:999999999 这类明显非法 key 发起 200+ 次查询，就可以触发熔断或加入黑名单——但这个判断逻辑必须由外部服务（如网关、风控系统）完成，不能指望 Streams 自己拦。
用 XADD + XTRIM 构建低开销的请求日志流水线
别用 LPUSH 或 SET 存日志：它们不支持自动过期、无时间序、难做范围查询。Streams 天然带时间戳和自动分片能力，适合长期轻量记录。
-
XADD写入时必须显式传入毫秒级时间戳（*会用服务器本地时间，跨节点可能错乱），例如：XADD req_log * ip 192.168.1.100 key user:999999999 ts 1729395240123 -
XTRIM要设最大长度而非过期时间（Streams 无 TTL），比如XTRIM req_log MAXLEN 10000，避免无限增长；若需按时间清理，得靠外部定时任务扫描XRANGE+XDEL - 不要为每个请求建独立 Stream，统一用一个
req_log，靠ip和key字段过滤，否则 10 万 IP 就产生 10 万 key，运维爆炸
结合 XRANGE + 客户端聚合识别穿透特征
单纯看单条日志没意义，关键是从 Streams 里捞出“高频查非法 key”的模式。典型穿透特征是：同一 IP 对不同但格式可疑的 key（如全数字超长、负值、含 SQL 片段）在短时间密集请求。
- 用
XRANGE req_log - + COUNT 1000拉最近 1000 条，客户端按ip分组，再按key做正则匹配（如^user:-?\d{6,}$）统计频次 - 避免在 Redis 里用
KEYS或SCAN查 Stream，它不支持模糊匹配字段值；所有条件过滤必须拉到应用层做 - 如果日志量大（>10k QPS），别实时扫整个 Stream，改用
XREAD长轮询 + 游标位移，配合内存 LRU 缓存最近 5 分钟的 IP-key 组合计数
真正拦截动作必须落在网关或中间件，不能依赖 Redis 响应延迟
从 Streams 发现异常到执行拦截，链路至少经过：Redis → 应用服务 → 网关配置更新 → 生效。这中间有几百毫秒延迟，根本挡不住穿透洪峰。所以 Streams 只能用于事后溯源、策略调优和批量封禁，不能当实时防火墙。
- 实时拦截必须前置：布隆过滤器在 Nginx/Lua 或 Spring Boot
HandlerInterceptor里校验，user_id连 Redis 连接都不该建立 - Streams 日志唯一能做的实时联动，是让网关定期（如每 5 秒）拉取最新异常 IP 列表，写入本地缓存，然后在请求入口做
if ip in blocked_ips判断 - 注意客户端时间戳精度：若业务用秒级时间戳写入 Streams，
XRANGE拉不到毫秒级攻击节奏，误判率会升高
实际部署中最容易被忽略的一点：Streams 的 MAXLEN 是按条数截断，不是按时间。如果你设了 MAXLEN 10000，但流量低谷期一小时才写 100 条，那这条日志就存了一小时；高峰期一秒写 1000 条，10 秒就刷没了。想按时间保留，必须自己维护索引或换用 RedisTimeSeries。
