-
典型现象是Redis从节点反复断连，日志出现“Clientclosedconnectionduetooutputbufferlimit”，INFOreplication中状态在connect→sync→disconnected循环；主节点因输出缓冲区超限（默认slave256MB/64MB/60s）主动断开连接。
-
应先用EXISTS检查key存在，再用TYPE校验类型是否为string，因GET对非string类型会直接报错且无法捕获；TYPE返回值严格区分大小写和拼写，须用==全等比较。
-
notify-keyspace-events开启后会显著增加CPU开销，因其在每个命令执行后强制执行事件广播逻辑，即使无人订阅；高写入场景下DEL、EXPIRE、SET等操作均触发线性增长的事件生成与分发。
-
无盘复制解决了传统主从全量同步中主节点fork+磁盘写入和从节点落盘加载的双重IO瓶颈；它跳过主节点落盘，由子进程直接通过socket发送RDB流，规避磁盘寻道与IO竞争。
-
allkeys-lru可能导致主线程卡顿，因其在内存达maxmemory时需同步遍历键空间淘汰key，在千万级实例下耗时数十毫秒；启用lazyfree-lazy-evictionyes可将释放操作异步化，显著降低延迟。
-
单纯用EXPIRE挡不住缓存击穿，因Redis物理过期会删除key导致并发请求全打到DB；逻辑过期通过value内嵌expireTime时间戳由应用判断数据有效性，配合长TTL防key被清，再用SETNX避免重复更新。
-
allkeys-random策略在内存超限时随机删除任意key，适合一致性要求低的缓存场景；需先配置maxmemory，且不区分key是否设过期时间。
-
Bitmap用1bit存每日签到状态，1万用户年数据仅13KB，String存“1”/“0”需3.6MB；需按年分key、用BITPOS+BITCOUNT算连续天数，offset须为小整数且避免客户端溢出。
-
MAXLEN是RedisStreams唯一实时限长方式，必须与XADD原子配合使用；~N为近似保留，N为严格上限；XTRIM仅作兜底，非实时；语法中MAXLEN须紧随stream名后，错位即报错。
-
用SETBIT而非SET存在线状态，因位图内存仅约12.5MB（1亿用户），支持秒级统计与集合运算；需确保用户ID为非负整数、key带日期并设过期，用BITFIELD批量操作，BITCOUNT统计时注意写入逻辑与精度。
-
volatile-ttl是Redis唯一支持按剩余过期时间优先淘汰的策略，仅作用于ttl>0的已设过期键，每次内存不足时淘汰一个最接近到期的key，非批量清理、不主动扫描、不保证全量精确排序。
-
RedisLua脚本执行失败常因忽略redis.call()返回值，应检查是否为错误表；EVALSHA需确保脚本已重载；redis.log()日志需调高loglevel且查服务端文件；KEYS必须显式声明，禁用KEYS命令。
-
reshard搬的是Slot而非Key，先重分配16384个Slot，再由集群自动触发Key迁移；需待“Allkeystransferred”提示才完成，且新节点须完成注册、握手、身份确认三步并满足网络与配置要求。
-
LTRIM是限制RedisList长度的唯一可靠方式，因其原子性、精准截断和内存即时释放特性；必须配合LPUSH使用，错误参数会清空列表，高并发下推荐Lua脚本保障原子性。
-
哨兵通过“客观下线”（ODOWN）判断主节点真挂了：单个哨兵连不上仅为主观下线（SDOWN），需至少quorum个哨兵达成一致才触发ODOWN；哨兵间用SENTINELis-master-down-by-addr命令确认，非心跳广播，网络分区可能导致结论不一。
