分布式锁用Redis怎么实现就用SET key value NX EX 30NX保证互斥EX设过期防止死锁。一定要SET和EX原子操作别分两步不然刚SET完就挂了锁永远不释放为什么要用Lua脚本它是用来解决Redis单命令原子性不能满足的组合操作竞态问题的锁的有效时长怎么控制根据业务执行时间预估一般设个30秒左右。但有个坑业务没跑完锁过期了怎么办搞一个看门狗线程定期检查业务没完就延长锁时间Redisson就是这么干的锁续期自动续redission实现的分布式锁Redisson基于Redis通过 “Hash数据结构 Lua原子脚本 看门狗(Watchdog)自动续期” 三大机制提供了一个安全、可重入且语义清晰的企业级分布式锁。它根除了手写SETNX实现中的锁过期、不可重入和误删三大痛点通过 lock,tryLock 等语义化API平衡了可靠性与高性能可重入锁什么意思怎么实现同一个线程可以多次拿同一把锁不会自己卡死自己。Redis实现就是在value里存个线程标识和计数器加锁的时候判断是不是自己是自己就计数加1解锁计数减1减到0才真释放主从一致性在分布式锁里有什么问题主库加锁还没同步到从库主库挂了从库升主但是锁丢了其他线程又能加了解决方案是RedLock通过向多个独立Redis实例加锁超过半数成功才算拿到显著提高了数据安全性。但需要提醒的是它在极端网络场景下并非绝对一致。对于普通业务Redisson的单实例加主从哨兵模式基本够用对于金融级场景建议直接用ZooKeeper或etcd这类基于Raft算法的强一致性锁Redis为什么单线程还那么快四大原因。纯内存操作纳秒级单线程无锁竞争无上下文切换IO多路复用一个线程管上万连接数据结构专门优化过。总结就是内存快、无切换、复用IO、结构精大key有什么问题怎么找到怎么处理大key就是单个key的value太大删了会导致Redis阻塞读写也慢内存分布不均。怎么找用redis-cli --bigkeys扫一遍或者用memory usage key看大小。怎么处理优雅的删法是用UNLINK key(异步删除)但大key删还是会卡更好的办法是分批渐进式删。设计阶段就拆分大key把一个大哈希表拆成多个小哈希表热key怎么判定怎么处理热key就是某一个key被大量请求打爆了。怎么发现用redis-cli --hotkeys或者提前用redis-cli的monitor观察热点或者客户端侧做统计。怎么处理热点key重建用互斥锁只让一个线程查库其他等着缓存预热就是提前把热点数据加载好别等用户来了再查。还有一个办法是二级缓存本地缓存扛一层Redis扛下一层Redis有事务吗原理是什么有但它的事务很简单核心是MULTI、EXEC、DISCARD。MULTI开启事务把命令排队EXEC一起执行DISCARD取消。注意两点它不支持回滚中间某条命令语法错了全不执行但运行时出错别的照样执行如果是Watch事务的方式可以实现乐观锁的效果缓存预热本质上它是‘空间换时间’的典型应用用启动时的额外开销和内存去交换服务稳态下的低延迟核心解决缓存冷启动时的性能坍塌。在落地策略上我把它分为两类第一全量预热适用于数据量小、命中率要求极高的场景比如基础配置、黑名单库。代价是启动慢、内存占用大第二热点预热适用于海量数据的缓存比如内容平台的热门推荐。依赖对热点数据的精准预测成本低但预测不准时效果会打折扣预热必须配套过期策略与更新机制否则会引入脏数据风险