Redis分布式锁对比悲观/乐观锁：Ticketmaster场景下的优势疑问

你忽略的核心点：高并发下的数据库瓶颈 #

票务系统（比如Ticketmaster）的核心场景是瞬时超高并发——比如热门演唱会开票时，每秒可能有上万甚至十万级的请求同时抢同一批座位。这时候数据库锁的问题会被无限放大：

• 数据库的悲观锁（SELECT FOR UPDATE）是基于行级锁，但高并发下会导致大量请求阻塞，数据库连接池被迅速占满，甚至引发数据库雪崩。而且数据库的锁粒度如果控制不好（比如锁了整张表或者大范围的行），阻塞会更严重。
• 乐观锁（比如版本号/时间戳）虽然不会阻塞，但冲突率极高的时候，大量请求会因为版本冲突失败重试，不仅浪费资源，用户体验也极差（反复刷新还是抢不到）。

而Redis分布式锁的优势恰恰是在这种高并发场景下：

• Redis是纯内存操作，响应速度比数据库快几个数量级，能扛住更高的并发请求。
• Redis锁的粒度可以更细（比如按座位ID单独加锁），不会像数据库锁那样因为行锁竞争导致连锁阻塞。
• 可以通过Redis的集群/哨兵模式保证高可用，避免单点故障。

关于SELECT FOR UPDATE的实际表现 #

SELECT FOR UPDATE并非完全不行，但只适合低并发、小规模的票务场景，比如小型剧场的售票：

• 在高并发下，它会导致大量事务等待锁释放，数据库的事务日志和连接池都会成为瓶颈，甚至引发死锁（比如两个用户同时锁定对方需要的座位）。
• 数据库的锁是基于事务的，事务未提交前锁不会释放，如果某个请求因为网络问题卡住，锁会一直占用，进一步加剧阻塞。
• 跨数据库/分库分表场景下，SELECT FOR UPDATE的行级锁无法跨节点生效，而Redis锁可以轻松支持分布式环境。

为什么Redis锁的复杂度和延迟是可接受的？ #

你提到的Redis的网络延迟和复杂度确实存在，但在大型票务系统中是可以通过优化抵消的：

• 网络延迟：Redis通常部署在和应用服务器同区域的机房，延迟一般在1-5ms以内，相比数据库的几十到上百ms延迟，其实反而更快。而且可以通过本地缓存+Redis锁的方式进一步减少请求次数。
• 复杂度：现在有成熟的Redis锁实现（比如Redisson），已经封装好了锁的自动续期、释放、高可用逻辑，不需要自己从零实现，引入成本并不高。而且相比数据库锁在高并发下的稳定性问题，这点复杂度是值得的。

总结 #

• 如果是小型票务系统，SELECT FOR UPDATE或乐观锁完全够用，不需要引入Redis。
• 但像Ticketmaster这种超大规模的票务平台，Redis分布式锁是更优的选择，因为它能扛住瞬时高并发，避免数据库成为瓶颈。
• 你忽略的核心是高并发场景下数据库锁的性能瓶颈和扩展性问题，这才是大型系统选择Redis锁的关键原因。

内容的提问来源于stack exchange，提问作者bornfree