-
appendfsynceverysec仍可能阻塞主线程，是因为当后台fsync未完成而缓冲区有新数据时，主线程会同步等待；根本原因是磁盘慢导致单次fsync超1秒，触发安全兜底机制。
-
MySQL实现读写分离的核心逻辑是将写操作（INSERT、UPDATE、DELETE）发到主库，读操作（SELECT）分散到从库。其原理基于主从复制机制，主库处理写请求并将数据变更同步至从库，应用层或中间件负责路由请求；实现方式主要有两种：一是手动编码控制，适合小项目，如通过MyBatis拦截器切换数据源；二是使用中间件自动分流，适合中大型项目，可统一处理连接池、负载均衡、故障转移等问题；常用的中间件包括MyCat、ShardingSphere、MaxScale和ProxySQL，各自具备不同特点和适用场
-
LPUSH+BRPOP不能直接做可靠循环队列，因为BRPOP阻塞等待导致无法自动重入，需外部调度；且List缺乏状态跟踪、幂等支持和消费确认机制，易丢任务或重复消费。
-
RedisStream消费组重试需手动干预：XPENDING加范围与消费者参数定位卡点，XCLAIM配FORCE和MIN-IDLE-TIME安全转移消息，XACK须在业务真正成功后调用，Redis5.0.5需自行轮询XPENDING实现自动重试。
-
SENTINELFAILOVER无反应大概率因哨兵未达成共识或主节点状态不满足切换前提：需至少3个哨兵在线且通信正常，目标master必须存在于SENTINELMASTER列表且角色为master，quorum值不可高于实际哨兵数；命令返回OK不代表切换完成，须依次验证哨兵failover_in_progress标志、新主role:master且无master_host、旧主已变为slave并指向新主；手动触发不模拟真实故障路径，无法检测发现延迟、重连失败及客户端重定向问题；演练前须调大down-afte
-
主从复制必须开启AOF，否则从节点重启后数据丢失；从节点需配置appendonlyyes和appendfsynceverysec，主节点也建议开启AOF；切换前须等待aof_pending_bio_fsync为0再开放VIP。
-
不能直接用RedisPub/Sub做缓存一致性保障，因其不保证消息可达，订阅者离线时消息丢失，无重试、ACK或持久化机制；必须结合RedisStream落地事件+数据库状态校验实现最终一致。
-
网卡PPS打满是吞吐量上不去的常见原因，尤其在小key/value场景下，单请求虽仅60–100字节却生成独立TCP包，易使网卡达到硬件上限。
-
Redis的WATCH+Lua无法实现可靠乐观锁，因WATCH不监控Lua脚本执行，脚本内读-改-写仍存在竞态；真正可靠的是将“读-校验-写”全部封装进单个原子Lua脚本中完成。
-
BITFIELD存储指定宽度和符号性的整数片段（如i8、u16），非完整整数对象；支持位级读写、原子增减及溢出控制，但需注意偏移单位为位、未初始化位返回0、跨字节边界正确处理及客户端解析差异。
-
PUBSUBNUMSUB命令可实时获取指定频道的活跃订阅者数量，返回整数（无人订阅时为0），支持多频道批量查询，但不区分SUBSCRIBE/PSUBSCRIBE，且在RedisCluster中需直连对应节点执行。
-
UPDATE语句用于修改表中数据，基本语法为UPDATE表名SET字段=新值WHERE条件；更新时需谨慎使用WHERE避免误改，可更新单条或多条记录、多字段或使用表达式，建议结合SELECT验证条件并备份数据。
-
PUBSUBCHANNELS命令返回当前至少有一个订阅者的活跃频道，不保留历史记录；频道非键空间成员，故KEYS/SCAN无法查到；支持pattern过滤，结果需手动decode。
-
appendfsyncalways会让Redis卡在磁盘上，因其每条命令都强制调用fsync()等待硬件确认落盘，使QPS被钉死在磁盘IOPS天花板；而everysec通过后台线程批量刷盘解耦主线程与I/O，大幅降低IOPS压力但引入秒级延迟毛刺。
-
RedisPub/Sub不支持消息过期机制，因其是纯内存即时广播通道，消息不存储、无TTL、不落盘；需改用SET+EXPIRE、STREAM配合定时清理或ZSET实现带有效期的消息。
