-
直接引入spring-session-data-redis即可，它自动适配SpringBoot2.7+的Lettuce；避免手动引入jedis、错误配置redis属性、使用默认JDK序列化，需改用GenericJackson2JsonRedisSerializer，并确保Redis高可用与Cookie正确隔离。
-
根本原因是复制积压缓冲区（repl-backlog）持续增长：失联从节点未被及时清理时，主节点仍向共享的环形缓冲区追加命令，导致内存只增不减；repl-diskless-sync仅影响全量同步传输方式，不控制增量缓存，真正关键的是repl-timeout与client-output-buffer-limitslave协同配置以主动断连并释放内存。
-
RDB和AOF不能防止雪崩，仅决定宕机后数据能否快速完整恢复；RDB加载失败主因是路径、权限、版本不兼容或未启用；AOF截断需设aof-load-truncatedyes临时解决；Redis优先用AOF恢复；加载后keyTTL已过期，须配合缓存预热。
-
哨兵通过“客观下线”（ODOWN）判断主节点真挂了：单个哨兵连不上仅为主观下线（SDOWN），需至少quorum个哨兵达成一致才触发ODOWN；哨兵间用SENTINELis-master-down-by-addr命令确认，非心跳广播，网络分区可能导致结论不一。
-
必须用Lua脚本做抢红包，因其能原子执行读取余额、扣减金额、写入中奖记录、更新过期时间等操作；客户端多步命令易因并发或网络中断导致脏数据。
-
MySQL内存优化的核心是合理配置关键参数以提升性能。1.调整innodb_buffer_pool_size至物理内存的50%~80%，如32GB服务器可设为24GB，并结合多实例减少争用。2.控制连接内存，thread_stack建议不低于192KB，sort_buffer_size设为1MB~2MB，避免内存浪费。3.配置全局内存参数tmp_table_size和max_heap_table_size至128M，避免临时表落盘。4.通过SHOWENGINEINNODBSTATUS及监控工具持续观察内存
-
RedisPub/Sub不适合用户级一对一聊天，因其消息不持久、无离线保障、无ACK机制、不支持点对点推送、无权限控制且无法保证消息顺序。
-
单靠DECR会超卖，因其校验库存是否>0与扣减是两步非原子操作，高并发下多个客户端可能同时读到库存=1后均执行DECR导致负数；必须用Lua脚本将判断与扣减封装为单次原子执行。
-
Redis集群原生不支持灰度发布，需通过Proxy（如Predixy）或客户端SDK实现key前缀路由，注意代理高可用、跨集群事务拦截、连接池隔离及日志打标。
-
Redis集群写入失败需先确认是否真不可写：常见原因是客户端连只读节点或未处理ASK/MOVED重定向；检查CLUSTERNODES中fail?（疑似下线）或fail（客观下线）状态；CLUSTERFAILOVER仅在从节点、主节点在线、偏移量合规且非CLUSTERDOWN时生效；主节点宕机且无自动转移时，才需在健康从节点执行CLUSTERFAILOVERFORCE，并对旧主执行CLUSTERRESETHARD。
-
双重检查是为防缓存击穿：第一次检查过滤命中请求，第二次检查在锁内确认避免重复查库；必须配合空值缓存防穿透、Lua脚本删锁保原子性。
-
先看INFOCPU中used_cpu_sys是否单独飙升，若是则为连接层压力；若user和sys同步涨，再查cluster中migrating_slots/importing_slots是否非零，并结合客户端重试日志与抓包定位根因。
-
RedisPubSub不支持批量publish，因协议层限制且pipeline无法减少网络往返；可行方案是业务层聚合消息为结构化数据（如JSON数组）后单次发送，并合理控制聚合窗口与消息体积。
-
allkeys-lru可能导致主线程卡顿，因其在内存达maxmemory时需同步遍历键空间淘汰key，在千万级实例下耗时数十毫秒；启用lazyfree-lazy-evictionyes可将释放操作异步化，显著降低延迟。
-
应先用EXISTS检查key存在，再用TYPE校验类型是否为string，因GET对非string类型会直接报错且无法捕获；TYPE返回值严格区分大小写和拼写，须用==全等比较。
