-
RedisLua脚本需用原子“读-判-写”实现状态变迁，推荐HASH结构存储多字段（如status、updated_at、version），通过HGETALL/HSET原子操作，结合redis.call("TIME")获取时间戳、INCR或version校验防越级跳转，返回结构化结果便于业务判断。
-
Redis客户端重连易打挂新主库，因默认“失败即重试”导致连接风暴；需配置指数退避+随机抖动（如Lettuce用ExponentialBackoffRetry.withJitter）、Go端自定义DialContext重试逻辑，并控制初始延迟50–100ms、最大延迟≤3s、重试8–12次。
-
Redis延迟高但CPU正常通常是网络丢包或抖动所致，表现为redis-cli--latency毛刺飙升、ping标准差>10ms或丢包率>0.1%，需用tcpdump抓包分析重传与ACK丢弃，并排查云环境安全组、NAT会话老化及内核TCP参数配置。
-
RedisHash最适合存购物车，因其天然支持按商品ID（field）原子增减、查询、删除；HINCRBY可安全±数量并自动初始化为0，但需应用层校验负数；key为cart:{user_id}，value仅存整数数量，过期用EXPIRE设置。
-
缓存雪崩是大量key集中过期或Redis实例不可用导致请求直击数据库，引发数据库过载崩溃；需通过TTL随机偏移错峰过期、熔断降级、本地缓存兜底及禁用危险命令等手段防御。
-
应使用HSET分字段存储用户资料而非SET存JSON，因其支持原子性单字段操作、避免并发覆盖、节省带宽；字段名须全小写下划线；慎用HGETALL防性能陷阱；Hash无内置TTL，需显式EXPIRE。
-
Redis数据丢失后首先确认是否开启持久化，90%情况实为未启用；需用redis-cliconfigget验证运行时AOF/RDB状态，检查appendfsync模式及AOF文件完整性。
-
redis-cli--hotkeys是基于LFU采样的轻量热Key发现工具，需启用allkeys-lfu/volatile-lfu策略，返回最多32个相对高频key，frequency为归一化值，非实时精确计数，须结合objectfreq、monitor等交叉验证。
-
INFOkeyspace无法反映淘汰情况，因其仅统计存活key数量，不区分已过期未删除或已被淘汰的key，且不记录evicted_keys等关键淘汰指标。
-
RedisLua脚本中不能直接执行SET等命令，必须通过redis.call()或redis.pcall()调用；MULTI/EXEC等事务命令禁用；所有key需显式传入，集群下须同slot；返回值类型需手动判断，避免误判false/0。
-
ZADD的score不能用时间戳，因同分排序不稳定且时间戳递增违背“分数越高名次越靠前”逻辑；应使用业务分数（如积分）并利用ZADD覆盖更新、ZINCRBY原子累加、ZREM安全删除。
-
RedisPub/Sub不适合异步任务处理，因其无确认机制、无持久化、不支持消费者组与积压缓冲；应选用LPUSH+BRPOP或XADD+XREADGROUP(Stream)实现可靠任务队列。
-
RedisLua脚本不能实现真正的分布式事务回滚，仅能通过条件化原子写入预防性拒绝，失败后需业务层设计补偿机制。
-
AOF本质是只追加不修改的文本日志，通过重放命令恢复数据；appendfsync决定落盘策略，everysec为生产默认；SELECT因影响命令作用域被记录；BGREWRITEAOF基于内存快照重生成最小日志；no-appendfsync-on-rewrite可缓解重写时I/O竞争。
-
增大repl-backlog-size能修复断连后全量回滚，因其为主节点提供足够大的环形缓冲区暂存断连期间的写命令；只要从节点重连时请求的slave_repl_offset仍在该缓冲区内（即master_repl_offset−slave_repl_offset≤repl_backlog_histlen），即可触发PARTIALRESYNC实现增量同步，避免FULLRESYNC。
