困难 · 高频 5/5
Redis 分布式锁加在事务外面还是里面？
通常应先获取分布式锁，再开启数据库事务，让锁保护完整的业务临界区；如果锁放在事务内，事务提交后的并发窗口可能导致一致性问题。
简短答案
通常应先获取分布式锁，再开启数据库事务，让锁保护完整的业务临界区；如果锁放在事务内，事务提交后的并发窗口可能导致一致性问题。
详细解析
锁的位置取决于你要保护的资源。如果要保护从校验到写入的完整业务过程，锁应覆盖事务开始前的读校验和事务提交。
同时要注意锁超时、续期、释放校验和事务耗时。长事务会扩大锁持有时间，影响吞吐。
面试回答模板
我的默认做法是锁在事务外，获取锁后再进入事务，提交或回滚后释放锁。这样能保护完整业务临界区，但要控制事务时间，并保证释放锁时校验 value，避免误删其他线程的锁。
易错点
- 只背结论，不解释原理和边界。
- 忽略真实生产环境中的容量、延迟、一致性和失败重试。
- 没有结合项目经验说明为什么这样设计。
常见追问
- 这个方案在高并发下有什么风险？
- 如果数据规模扩大十倍，你会如何调整？
- 线上出现异常时，你会先看哪些指标？