-
正确做法是用EVAL执行Lua脚本保证原子性，结合PTTL和TIME实现毫秒级令牌补充，避免客户端时间依赖；Redis6.2+可用CL.THROTTLE简化实现。
-
Redis集群节点宕机是否自动恢复，取决于它是不是主节点、有没有足够多的主节点在线投票，以及从节点是否满足参选资格；不是所有宕机都会触发转移，更不是宕机后立刻切换。
-
Bitmap用1bit存每日签到状态，1万用户年数据仅13KB，String存“1”/“0”需3.6MB；需按年分key、用BITPOS+BITCOUNT算连续天数，offset须为小整数且避免客户端溢出。
-
会，大量key同时过期会引发CPU尖峰、内存延迟释放和请求抖动；Redis通过每100ms随机抽样检查过期key，超25%过期则连续多轮高强度扫描删除，导致延迟飙升甚至超时。
-
Redis主从心跳由应用层PING和REPLCONFACK命令维持，主库每秒发PING，从库需立即回ACK；若超repl-timeout（默认60秒）未收到ACK，主库即标记该从库为down。
-
查哨兵进程资源需用ps和top实时监控CPU与内存，关注RSS突增、%CPU峰值及线性上涨；结合日志分析+sdown/+odown频次、INFOSENTINEL状态（如sentinel_tilt、sentinel_running_scripts）定位真实压力源。
-
常用的Redis性能监控工具包括Redis自带的INFO命令、慢查询日志、RedisInsight、Prometheus和Grafana组合以及Redis-benchmark。1.INFO命令适合快速诊断问题，但数据粒度较粗。2.慢查询日志有助于优化性能，但配置需谨慎。3.RedisInsight提供直观的监控和分析功能，但需考虑资源消耗。4.Prometheus和Grafana组合适用于大规模集群监控和长期趋势分析，部署复杂。5.Redis-benchmark用于测试性能极限，需结合实际业务场景分析。
-
--cluster-replicas必须加且数值需准确，它表示每个主节点配几个从节点；若节点总数不能被(replicas+1)整除，则报错ERRInvalidclusterconfiguration。
-
Redis不内置BloomFilter，需借助Redisson等第三方实现；EXISTS和空值缓存无法有效防穿透，因前者不拦截非法ID、后者易致缓存污染；布隆过滤器以极小空间开销提供高效存在性否定判断。
-
ZREVRANGEBYSCORE不适用于超时任务检测，因其按score降序返回，而超时检测需升序查找score≤当前时间戳的任务；正确做法是用ZRANGEBYSCOREtasks-inf[current_timestamp]配合Lua原子执行扫描与删除，并确保score为高精度到期时间戳以避免排序混乱和堆积性能问题。
-
redis-cli--clusterinfo仅提供槽位、键数和从节点数的粗粒度分布，无法反映真实CPU/内存负载；需结合INFOmemory、SLOWLOG和INFOstats交叉验证，因slot均匀不等于负载均匀。
-
appendfsyncalways会让Redis卡在磁盘上，因其每条命令都强制调用fsync()等待硬件确认落盘，使QPS被钉死在磁盘IOPS天花板；而everysec通过后台线程批量刷盘解耦主线程与I/O，大幅降低IOPS压力但引入秒级延迟毛刺。
-
ZREM不能直接删除Geo数据，因为它只删除ZSET中的member名称，而非按经纬度范围删除；必须先用GEORADIUS等命令查询出目标member，再调用ZREM精确删除。
-
ShedLock通过Redis的SETkeyvalueEXsecondsNX原子命令实现加锁，键为shedlock:{任务名}，值为节点标识，TTL由lockAtMostFor控制；重复执行主因是Redis配置不一致、集群未适配、绕过AOP或TTL过短。
-
LPUSH+BRPOP构成FIFO阻塞队列，兼容Redis2.0+；但消费失败会导致消息丢失，适合允许少量丢失的场景，强可靠性需求应改用Stream。
