-
Redis内存淘汰策略由maxmemory-policy配置决定，不设则默认noeviction导致写入失败；需结合数据TTL、访问模式及一致性要求选择volatile-lru、allkeys-lru等策略，并确保maxmemory非零、淘汰触发条件满足。
-
Redis集群无法在入口统一配置slowlog，因其去中心化架构决定slowlog是节点级内存缓冲区，仅记录本节点命令，CONFIGSET等配置不跨节点生效，必须逐节点独立启用、采集和聚合。
-
Redis发布订阅卡顿主因是客户端消费能力不足或连接资源耗尽，而非Redis服务端性能瓶颈；需隔离连接池、改用异步驱动+批处理+超时熔断，并在需可靠性时迁移到Stream。
-
应使用Redis的Hash或ZSet维护用户会话映射，新登录时先获取并删除旧会话缓存及黑名单，配合事务或Lua脚本保证并发安全，而非仅依赖EXPIRE。
-
Redis7.0的String类型未新增任何操作指令，所有内存优化均源于SDS编码策略的自动演进，如按长度动态选用sdshdr8/sdshdr16及预分配冗余空间，无需用户干预。
-
RedisPubSub不支持批量publish，因协议层限制且pipeline无法减少网络往返；可行方案是业务层聚合消息为结构化数据（如JSON数组）后单次发送，并合理控制聚合窗口与消息体积。
-
SpringBoot中@Cacheable不支持动态过期时间，因SpringCache抽象层仅支持全局TTL配置；需通过RedisTemplate手动设expire、多CacheManager配置或自定义RedisCacheWriter实现差异化TTL。
-
应通过aof_rewrite_in_progress、aof_pending_rewrite、aof_last_bgrewrite_status三字段组合判断AOF重写是否真正完成：前两者为0且后者为ok才表示成功；仅凭aof_last_rewrite_time_sec或单个字段易误判。
-
Bitmap签到本质是将日期转为从基准日开始的天数差作为offset，用SETBIT操作位；需统一UTC时区、避免手算闰年、单用户单key（如sign:uid:12345）、按月分key更实用，查连续签到须结合日期范围校验offset。
-
单靠DECR会超卖，因其校验库存是否>0与扣减是两步非原子操作，高并发下多个客户端可能同时读到库存=1后均执行DECR导致负数；必须用Lua脚本将判断与扣减封装为单次原子执行。
-
<p>MySQL数据库创建的完整流程包括规划、命名、创建数据库、创建表、权限管理和最佳实践。1.规划时需考虑数据类型、规模、访问频率和扩展性。2.命名应简洁明了并与项目一致，如"projectx_db"。3.使用SQL命令创建数据库并设置字符集和排序规则，如CREATEDATABASEprojectx_dbCHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ci;。4.创建表时遵循规范化设计，避免数据冗余，如CREATETABLEusers(idINTAUTO_
-
dump.rdb文件越积越多是因为Redis默认不自动清理旧快照，每次bgsave生成新文件但保留旧文件，需依赖外部脚本按时间戳安全清理。
-
Redis不设maxmemory时不会触发淘汰机制，因默认策略noeviction且不启动任何淘汰逻辑，内存持续增长直至OOMKiller强杀进程。
-
SDIFF不能直接找出“新增关注”，因其仅执行集合差运算且不记录时间顺序；需先构建两个语义明确的快照集合（如按日期命名），再用SDIFF计算差集，否则易因键名错误、空键或客户端处理问题导致结果异常。
-
Redis6+集群启用TLS需版本≥6.0且编译时启用OpenSSL（makeBUILD_TLS=yes），OpenSSL≥1.1.1，所有节点共用同一CA证书，配置必须包含tls-cert-file、tls-key-file、tls-ca-cert-file、tls-clusteryes、tls-replicationyes，客户端需指定--cacert，证书更新须滚动重启。
