-
PUBSUBCHANNELS命令返回当前至少有一个订阅者的活跃频道，不保留历史记录；频道非键空间成员，故KEYS/SCAN无法查到；支持pattern过滤，结果需手动decode。117 收藏 -
appendfsyncalways会让Redis卡在磁盘上，因其每条命令都强制调用fsync()等待硬件确认落盘，使QPS被钉死在磁盘IOPS天花板；而everysec通过后台线程批量刷盘解耦主线程与I/O，大幅降低IOPS压力但引入秒级延迟毛刺。112 收藏 -
Redis内存爆满主因是业务接口批量生成无TTL垃圾Key，需在防火墙层限流新建连接并绑定127.0.0.1监听，禁用公网暴露与弱密码。112 收藏 -
RedisPub/Sub不支持消息过期机制，因其是纯内存即时广播通道，消息不存储、无TTL、不落盘；需改用SET+EXPIRE、STREAM配合定时清理或ZSET实现带有效期的消息。111 收藏 -
Pub/Sub是无存储的实时广播机制，消息断连即丢，适合允许丢失的在线通知；Stream是带ACK的持久化消息队列，支持回溯、消费者组和精确控制，但需手动管理XACK与MAXLEN。111 收藏 -
JedisPool不自动处理主从切换或断连重连，需应用层干预；卡住主因是连接池耗尽或失效连接未剔除，而非未重连。111 收藏 -
Redisbgsave时内存翻倍并非复制业务数据，而是fork触发COW：内核仅复制页表，写入时才拷贝物理页，导致RSS暴涨；典型信号是used_memory_rss/used_memory比值骤升至2.5+且latest_fork_usec>500ms。110 收藏 -
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 收藏 -
红包拆解必须用RedisLua脚本实现原子操作，通过线段切割法生成严格满足总和与最小值约束的随机金额，并配合EVALSHA调用、兜底校验及集群哈希标签设计确保资金安全与高并发正确性。106 收藏 -
不能，RLock仅提供分布式锁功能，不解决缓存击穿；需结合双检、空值缓存、合理锁超时与降级策略才能有效防护。103 收藏 -
AOF重写阻塞主线程的根本原因是fork()系统调用引发的页表复制与copy-on-write冲突；高频key修改导致大量脏页拷贝，使fork耗时飙升。100 收藏
