Redis乐观锁与悲观锁应用解析，并发控制策略与实战技巧

Redis乐观锁利用WATCH命令监视数据变更，在事务提交时检查版本（如时间戳或计数器），若被改动则事务失败重试，适用于读多写少场景；悲观锁通过SETNX或Redlock等直接加锁，确保独占访问，适用于写多读少或强一致性场景；并发控制策略需根据业务权衡性能与安全，结合重试机制和锁超时避免死锁，实战中常用Lua脚本保证原子性。

乐观锁怎么用？其实很简单

乐观锁就像你去超市买东西，先看看标签价格，结账时再确认一下有没有变。在Redis里，你可以用WATCH命令盯住一个键，比如商品库存。然后你开始一个事务，在事务里修改数据，比如减库存。最后执行EXEC提交事务。如果提交时发现那个键被别人改过了（比如库存已经变了），事务就会失败，你需要重新尝试。这适合很多人同时看商品但只有少数人真正买的场景，因为大部分时候不会冲突，效率高。

悲观锁更直接，先锁住再说

悲观锁就像你进厕所先锁门，确保没人打扰。在Redis里，最简单的办法是用SETNX命令，比如设置一个锁键，只有设置成功才能操作数据，操作完再删除锁。但要注意设置超时时间，防止程序崩溃后锁永远不释放。对于更复杂的系统，可以用Redlock算法，它通过多个Redis实例来加锁，更安全可靠。这适合写操作很频繁的情况，比如秒杀抢购，因为锁能保证同一时间只有一个人能修改数据。

实战技巧：别让锁坑了你

第一，用乐观锁时，失败后要重试，但别无限重试，加个次数限制比如3次，超过就报错。第二，用悲观锁时，超时时间要设合理，太短可能没做完就超时，太长又容易死锁。第三，尽量用Lua脚本，因为Redis执行Lua脚本是原子的，能打包多个操作，比如检查并修改库存，一步到位。第四，监控锁的争用情况，如果老失败，说明并发太高，可能需要调整策略。

并发控制策略：选对方法省大事

如果业务对数据一致性要求不高，比如点赞数，可以用乐观锁，性能更好。如果要求很强，比如支付扣款，最好用悲观锁，避免出错。有时候可以混合用，比如先用乐观锁试，如果冲突多了再切到悲观锁。记住，没有完美的方法，只有适合你业务场景的。

FAQ

问：乐观锁和悲观锁哪个更快？
答：一般来说，乐观锁更快，因为它只在提交时检查，平时不加锁，适合读多写少；悲观锁更慢，因为它一直占着锁，但写多时更安全。

问：Redis锁超时时间设多少合适？
答：看你的操作耗时，比如业务逻辑需要1秒，那就设2-3秒，留点余量。太短容易误释放，太长可能阻塞其他请求。

问：怎么避免锁被误删？
答：每个锁设置唯一值（比如UUID），删除时检查是不是自己的锁。用Lua脚本能保证原子性，避免检查后被别人删除。

引用来源： Redis官方文档（https://redis.io/docs/manual/transactions/）、Redlock算法说明（https://redis.io/topics/distlock）、社区实践案例分享。