-
RedisAOF是将写命令追加到文件以实现持久化，但并非所有场景都适用：appendfsync配置影响安全性与性能，everysec是线上折中选择，always性能差，no不可靠；AOF重写可能耗资源，切换时需检查文件完整性、路径及时间戳。
-
切换RedisPython客户端需同步更新依赖和初始化代码，仅安装新包不生效；redis-py不支持集群，redis-py-cluster已停更，应改用redis-py4.0+的RedisCluster；异步场景下aioredisv1与v2接口不兼容。
-
Redis集群通过主从复制、故障转移和一致性哈希保障数据一致性。优化方法包括：1.调整网络配置，提升网络性能；2.合理的数据分片策略，均衡负载；3.采用读写分离，提升读性能和降低主节点压力。
-
RedisCluster故障转移由主节点失联且多数主节点投票确认触发；从节点需满足复制偏移量达标、获多数主节点投票才能当选新主。
-
BITFIELD存储指定宽度和符号性的整数片段（如i8、u16），非完整整数对象；支持位级读写、原子增减及溢出控制，但需注意偏移单位为位、未初始化位返回0、跨字节边界正确处理及客户端解析差异。
-
Redis禁止BGSAVE与BGREWRITEAOF并发执行，是为避免双子进程争抢CPU、I/O、COW内存页及fsync队列；前者返回错误，后者被排队；no-appendfsync-on-rewriteyes可缓解AOF重写时主进程fsync阻塞，但对BGSAVE无效。
-
根本原因是MOVE命令迁移大Key时需原子性搬运整个value并阻塞slot读写；应通过业务层拆分（如SCAN+HSCAN）、人工slot迁移及提前识别大Key来解决，而非依赖reshard。
-
推荐用base64url编码6字节随机数生成短码，冲突概率低且不可预测；需先EXISTS校验再写入，跳转用Lua脚本原子读URL并INCR计数，Redis用String类型存short:{code}→URL，设EX过期，stat:{code}单独存访问量。
-
Redis主从心跳由应用层PING和REPLCONFACK命令维持，主库每秒发PING，从库需立即回ACK；若超repl-timeout（默认60秒）未收到ACK，主库即标记该从库为down。
-
根本原因是Redis集群要求多键操作的key必须位于同一slot，而HashTag（如{user:1}:profile）通过仅哈希花括号内内容实现强制同槽，但需命令本身支持多key且全链路保留括号语义。
-
主节点磁盘满导致bgsave失败，进而使从节点全量同步卡在wait_bgsave状态；需通过df-h查Redis实际dir路径磁盘使用率、日志中“Nospaceleftondevice”报错及infopersistence中rdb_bgsave_in_progress异常确认。
-
不能，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。
