-
不能，RLock仅提供分布式锁功能，不解决缓存击穿；需结合双检、空值缓存、合理锁超时与降级策略才能有效防护。
-
Redis自动快照由save指令控制，需满足“指定时间内发生指定次数写操作”才触发，如save9001表示900秒内至少1次修改；仅注释或修改redis.conf不生效，必须重启或重载配置，且CONFIGSET无法动态修改save参数。
-
必须配合日期动态生成key，因Bitmap无时间维度，共用key会丢失日期信息且导致单key膨胀、RDB/AOF暴增、主从延迟；用户ID须映射为非负整数offset，避免直接强转；BITCOUNT偏高多因key未清理或offset错位；5000万DAU下Bitmap体积约6.25MB，但需防ID稀疏浪费内存。
-
RedisRDB不支持并行拉取切片，因其为单文件顺序写入二进制快照，无分片格式与元数据索引；并行只能在实例粒度实现，即多master同时BGSAVE。
-
必须显式配置client-output-buffer-limit，否则普通客户端无输出缓冲区上限，易致内存耗尽；需为normal、pubsub等类型分别设置hard/soft限制，尤其pubsub缓冲区最易失控。
-
SAVE命令会阻塞Redis主进程同步写入RDB文件，期间不处理任何请求；适用于停机前且可接受中断的场景，但生产环境应优先用BGSAVE，配合AOF才能保障数据不丢。
-
LFU频率计数器非线性增长，由lfu-log-factor和lfu-decay-time共同调控：访问按概率递增且增幅随当前值增大而衰减，初始值为5、上限255；衰减每lfu-decay-time分钟执行一次右移1位。
-
正确做法是用EVAL执行Lua脚本保证原子性，结合PTTL和TIME实现毫秒级令牌补充，避免客户端时间依赖；Redis6.2+可用CL.THROTTLE简化实现。
-
常用的Redis性能监控工具包括Redis自带的INFO命令、慢查询日志、RedisInsight、Prometheus和Grafana组合以及Redis-benchmark。1.INFO命令适合快速诊断问题，但数据粒度较粗。2.慢查询日志有助于优化性能，但配置需谨慎。3.RedisInsight提供直观的监控和分析功能，但需考虑资源消耗。4.Prometheus和Grafana组合适用于大规模集群监控和长期趋势分析，部署复杂。5.Redis-benchmark用于测试性能极限，需结合实际业务场景分析。
-
Redis分布式锁高并发下饿死请求的根本原因是续期机制与过期时间不匹配、客户端异常未释放锁，且重试无退避和超时兜底；须用随机退避、总等待超时、Lua原子删锁，单节点自动续期锁比Redlock更稳。
-
Redis内存过载时jemalloc拒绝分配，是因内部碎片或保留页不足主动返回NULL触发OOMerror，与LinuxOOMKiller无关；关键看INFOmemory中allocator_allocated、active、mapped的剪刀差而非used_memory。
-
XDEL对已消费消息无效，因其仅逻辑删除未被任何消费者组读取的消息；已入PEL的消息调用XDEL会静默返回0，必须用XACK释放再XTRIM裁剪。
-
优先用redis-check-aof--fix自动修复尾部无效数据，若失败则需结合RDB回滚或从节点同步；切勿手动编辑或截断，避免破坏RESP协议完整性。
-
用iptables模拟Redis哨兵网络分区需双向封禁节点间通信（INPUT+OUTPUT），匹配6379/26379端口，确保Quorum计算失效；恢复时须精准删除规则而非清空链，避免锁死服务器。
-
红包拆解必须用RedisLua脚本实现原子操作，通过线段切割法生成严格满足总和与最小值约束的随机金额，并配合EVALSHA调用、兜底校验及集群哈希标签设计确保资金安全与高并发正确性。
