Redis高可用需主从+哨兵+客户端容错；连接池大小应匹配并发与耗时；键设计要小而准，禁大Value和pickle；穿透用布隆过滤器，击穿用逻辑过期或互斥锁，雪崩加TTL随机偏移。
Redis 作为 Python 缓存系统的核心组件，要真正落地高可用与高性能，不能只靠配置调优，得从架构设计、连接管理、数据建模、故障应对四个层面系统性推进。
一、Redis 高可用：主从 + 哨兵 + 客户端容错缺一不可
单节点 Redis 再快也是单点故障。生产环境必须部署哨兵（Sentinel）集群监控主从状态，并配合支持自动故障转移的客户端（如 redis-py 的 SentinelConnectionPool）。
- 哨兵至少部署 3 个实例（奇数），跨机器或可用区，避免脑裂
- Python 中初始化连接时明确指定 sentinel 和服务名：
sentinel = Sentinel([('10.0.1.10', 26379), ('10.0.1.11', 26379)], socket_timeout=0.5)
master = sentinel.master_for('mymaster', socket_timeout=0.5) - 不要依赖“自动重连”——redis-py 默认不重试失败命令，需用 retry_strategy 或外层 try/catch + 指数退避
二、连接池不是开得越大越好：控制并发与资源水位
Python 多线程/协程场景下，无节制创建连接会耗尽 Redis 端 maxclients 或本地文件描述符。连接池大小应匹配业务并发量和命令耗时。
- 推荐公式：max_connections ≈ 并发请求数 × 每请求平均连接占用时间（秒）/ 0.1（假设平均命令耗时 100ms）
- 使用 connection_pool 显式复用，避免每次 new Redis()：
pool = ConnectionPool(host='localhost', port=6379, max_connections=30)
redis_client = Redis(connection_pool=pool) - 启用 health_check_interval=30 让空闲连接定期 ping，及时剔除断连
三、缓存键设计与序列化：小而准，避免大 Value 和 JSON 全量序列化
缓存性能瓶颈常不在网络或 CPU，而在内存带宽和序列化开销。Python 默认用 pickle 序列化，体积大、慢、有安全风险。
立即学习“Python免费学习笔记（深入）”；
- 优先用 json + str 编码（兼容性好、体积小）；高频场景可选 msgpack 或 orjson（更快更小）
- 键名加前缀分类（如 user:123:profile、order:456:items），便于批量清理和监控
- 禁止缓存超 1MB 的对象；大字段拆分为独立 key（如 user:123:avatar_url 单独缓存）
- 设置合理过期时间（expire），用 EXPIREAT 替代 EXPIRE 避免时钟漂移导致批量失效
四、穿透、雪崩、击穿：用布隆过滤器 + 逻辑过期 + 互斥锁组合防御
缓存异常流量冲击往往源于业务逻辑缺陷，而非 Redis 本身。三类经典问题需不同策略应对：
- 穿透：查不存在的 ID（如 -1、随机字符串）。在接入层加布隆过滤器（pybloom_live）预判 key 是否可能存在
- 击穿：热点 key 过期瞬间大量请求打穿缓存。用 setnx 实现简单分布式锁，或改用“逻辑过期”——value 内嵌过期时间戳，后台异步刷新
- 雪崩：大量 key 同一时刻过期。给 TTL 加随机偏移（如 expire = base_ttl + random.randint(0, 300)）
不复杂但容易忽略。把连接管住、把键理清、把异常兜住，Redis 就真能扛住流量，而不是成为第一个倒下的环节。
