-
不能直接用RedisPub/Sub做缓存一致性保障，因其不保证消息可达，订阅者离线时消息丢失，无重试、ACK或持久化机制；必须结合RedisStream落地事件+数据库状态校验实现最终一致。129 收藏 -
网卡PPS打满是吞吐量上不去的常见原因，尤其在小key/value场景下，单请求虽仅60–100字节却生成独立TCP包，易使网卡达到硬件上限。125 收藏 -
Redis的WATCH+Lua无法实现可靠乐观锁，因WATCH不监控Lua脚本执行，脚本内读-改-写仍存在竞态；真正可靠的是将“读-校验-写”全部封装进单个原子Lua脚本中完成。124 收藏 -
BITFIELD存储指定宽度和符号性的整数片段（如i8、u16），非完整整数对象；支持位级读写、原子增减及溢出控制，但需注意偏移单位为位、未初始化位返回0、跨字节边界正确处理及客户端解析差异。123 收藏 -
PUBSUBNUMSUB命令可实时获取指定频道的活跃订阅者数量，返回整数（无人订阅时为0），支持多频道批量查询，但不区分SUBSCRIBE/PSUBSCRIBE，且在RedisCluster中需直连对应节点执行。121 收藏 -
appendfsyncalways会让Redis卡在磁盘上，因其每条命令都强制调用fsync()等待硬件确认落盘，使QPS被钉死在磁盘IOPS天花板；而everysec通过后台线程批量刷盘解耦主线程与I/O，大幅降低IOPS压力但引入秒级延迟毛刺。112 收藏 -
RedisPub/Sub不支持消息过期机制，因其是纯内存即时广播通道，消息不存储、无TTL、不落盘；需改用SET+EXPIRE、STREAM配合定时清理或ZSET实现带有效期的消息。111 收藏 -
Pub/Sub是无存储的实时广播机制，消息断连即丢，适合允许丢失的在线通知；Stream是带ACK的持久化消息队列，支持回溯、消费者组和精确控制，但需手动管理XACK与MAXLEN。111 收藏 -
JedisPool不自动处理主从切换或断连重连，需应用层干预；卡住主因是连接池耗尽或失效连接未剔除，而非未重连。111 收藏 -
Redis集群通过主从复制、故障转移和一致性哈希保障数据一致性。优化方法包括：1.调整网络配置，提升网络性能；2.合理的数据分片策略，均衡负载；3.采用读写分离，提升读性能和降低主节点压力。110 收藏 -
<p>用户ID转位偏移量需统一减1，即offset=user_id-1；负数、字符串或过大ID（>2³²）不合法，分库分表/UUID/Snowflake等非连续ID须先映射为连续整数。</p>110 收藏 -
SCRIPTKILL只能终止未执行写命令的脚本；一旦调用redis.call('set')等写操作，脚本变为UNKILLABLE，因Redis为保障原子性禁止中途终止，否则可能导致数据不一致。109 收藏 -
主从节点淘汰策略必须完全一致，否则必然导致数据不一致；需统一maxmemory-policy、maxmemory值，确保read_only开启，并避免从节点写操作及运行时配置变更。107 收藏 -
不能，RLock仅提供分布式锁功能，不解决缓存击穿；需结合双检、空值缓存、合理锁超时与降级策略才能有效防护。103 收藏
