-
生产环境必须组合使用RDB和AOF：RDB作冷备快照，AOF负责实时写入；仅用AOF有崩溃导致启动失败、重放慢、数据丢失风险；仅用RDB则丢失窗口大、fork开销高、无法增量修复。
-
根本原因是sentineldown-after-milliseconds阈值过短，而主库执行耗时Lua脚本导致PING响应超时，哨兵误判为主观下线；典型表现为INFOreplication正常但日志频繁出现+sdown又快速恢复。
-
RedisLua脚本无法实现SCAN分页，因脚本无状态且无法维护游标；唯一可行方案是客户端驱动SCAN分页，Lua仅负责单次结果的模式匹配与截取。
-
正确做法是用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。
-
<p>MySQL数据库创建的完整流程包括规划、命名、创建数据库、创建表、权限管理和最佳实践。1.规划时需考虑数据类型、规模、访问频率和扩展性。2.命名应简洁明了并与项目一致，如"projectx_db"。3.使用SQL命令创建数据库并设置字符集和排序规则，如CREATEDATABASEprojectx_dbCHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ci;。4.创建表时遵循规范化设计，避免数据冗余，如CREATETABLEusers(idINTAUTO_
-
Redis不内置BloomFilter，需借助Redisson等第三方实现；EXISTS和空值缓存无法有效防穿透，因前者不拦截非法ID、后者易致缓存污染；布隆过滤器以极小空间开销提供高效存在性否定判断。
-
ZREVRANGEBYSCORE不适用于超时任务检测，因其按score降序返回，而超时检测需升序查找score≤当前时间戳的任务；正确做法是用ZRANGEBYSCOREtasks-inf[current_timestamp]配合Lua原子执行扫描与删除，并确保score为高精度到期时间戳以避免排序混乱和堆积性能问题。
-
redis-cli--clusterinfo仅提供槽位、键数和从节点数的粗粒度分布，无法反映真实CPU/内存负载；需结合INFOmemory、SLOWLOG和INFOstats交叉验证，因slot均匀不等于负载均匀。
