Redis第六篇

分布式锁用Redis怎么实现？

就用SET key value NX EX 30，NX保证互斥，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+事务的方式可以实现乐观锁的效果

缓存预热

本质上，它是‘空间换时间’的典型应用，用启动时的额外开销和内存，去交换服务稳态下的低延迟，核心解决缓存冷启动时的性能坍塌。
在落地策略上，我把它分为两类：
第一，全量预热，适用于数据量小、命中率要求极高的场景，比如基础配置、黑名单库。代价是启动慢、内存占用大
第二，热点预热，适用于海量数据的缓存，比如内容平台的热门推荐。依赖对热点数据的精准预测，成本低但预测不准时效果会打折扣
预热必须配套过期策略与更新机制，否则会引入脏数据风险