Daily Study

更新: 9/30/2025 字数: 0 字 时长: 0 分钟

Daily Plan

#todo

• 写博客
• [ ]

Redis的数据结构和项目中的问题

skiplist

为什么 ZSET 选跳表

• 需要同时支持：按分值有序范围查询（如排行榜区间）、按成员精确查找、动态插入/删除。
• 跳表平均 O(log N) 的查找/插入/删除复杂度，范围遍历是顺序链式前进；实现简单、更新局部化，适合高并发环境。官方也明确 ZSET 内部维护 skiplist + hash table 两份索引以同时满足需求

soc告警研判项目中为什么要用Redis，为什么不直接用内存

和“其它选型”的对比（为什么不是 X）

• 关系型数据库：支持强查询、复杂统计，但延迟高、写放大，做入流实时过滤不合适；TTL/自动淘汰也需要额外任务。

• 本地进程缓存（LRU/Guava）：延迟更低，但不共享、不可持久、难做全局命中计数与权重提升，多个服务实例容易不一致。

• 消息队列：不适合做“存在性判定+计数+TTL”这类 KV 任务；更适合异步流水线/解耦。

优点

• 低时延 & 高并发过滤

  • 白名单判定在告警流入口（或模型前）执行，每条告警都要查；Redis 走内存、单条读写常在微秒级，适合高 QPS 场景。

  • 相比关系型库（需要索引、事务、锁），Redis 更适合“key→exist/value 快判”与“轻量计数”。

• 天然支持 TTL（生存时间）

  • 你的“结果反馈白名单”要求命中就刷新 TTL、过期自动淘汰。Redis 的 EXPIRE/PEXPIRE 正好满足；不需额外定时任务清理落灰条目。

  • 结合“权重分组→更长 TTL”的策略，只要在阈值提升时延长 TTL 即可，机制简单可靠。

• 原子性与并发安全

  • 白名单命中时要原子地：更新命中次数、刷新 TTL、（可能）提升权重。Redis 单线程执行命令本身就具备原子性；多步更新可用 MULTI/EXEC 或 Lua 脚本一次完成，避免并发竞态。

• 灵活的数据结构，契合你的两类模式

  • 自定义规则白名单：你已把“已排序的告警特征元组”转为唯一 key，值放在 Hash（或 JSON 字符串）。Redis 的 Hash 适合这种稀疏字段结构（count、last_hits、weight…）。

  • 结果反馈白名单：需要命中计数与最近命中时间列表——可放在 Hash 的字段里，或用 List 存最近 N 次时间，并 LTRIM 做上限。

  • 若需“按维度反查”（比如按 IP 查有哪些白名单），可加二级索引 Set（wl:idx:ip:1.2.3.4 -> {key1,key2}），扩展容易。

• 易横向扩展 & 高可用

  • 白名单总量或 QPS 升高时，可用 Redis Cluster 分片扩展；高可用上用 哨兵/主从 切换。

  • 服务多实例共享一份状态（而不是各自进程内缓存），避免实例重启丢失或一致性问题。

• 可持久化，服务重启不丢表

  • 选 AOF（或 RDB+AOF），重启能恢复白名单；相比纯进程内缓存（如 LRU Cache），Redis 能跨服务与重启保留状态。

• 生态与易用性

  • 你是 Python + redis-py，开发快；需要批量操作用 pipeline，减少 RTT；需要观测可接 Prometheus exporter。