一、前言高并发场景下多个请求同时修改同一行数据若无并发控制机制会出现数据覆盖、状态错乱、统计数值不准、库存超卖等脏数据问题。 关系型数据库提供两套原生并发控制方案悲观锁、乐观锁二者设计思路完全相反适配不同并发争抢场景。除此之外嵌入式数据库、分布式集群还有专属锁实现方案下文一并完整拆解。并发锁是一类并发控制机制的统称。在多线程、多进程、多服务并发场景下多个请求同时读写同一份共享数据时用来协调访问顺序、防止并发修改造成脏数据、数据覆盖、状态错乱的方案。后端开发中常见实现方案包含悲观锁、乐观锁、SQLite 操作系统文件锁、Redis 分布式锁。 不同锁底层实现、生效范围、并发能力差异巨大需要结合部署架构单机 / 分布式、业务并发压力选型。二、悲观锁强一致性锁2.1 核心设计思想默认并发一定会产生资源冲突操作数据前先主动锁定目标资源整个事务全程持有锁事务提交 / 回滚后才释放其余请求必须阻塞排队等待锁释放后才能操作数据。2.2 核心特点数据安全性极高完全杜绝并发修改覆盖问题存在线程阻塞、排队等待逻辑资源争抢激烈时整体并发吞吐大幅下降依赖数据库原生行锁、表锁机制实现仅 MySQL、PostgreSQL 这类服务型数据库支持长事务会长期占用锁极易引发锁等待超时、接口雪崩。2.3 基础 SQL 示例-- 开启事务并对目标行加悲观行锁 BEGIN; SELECT * FROM table WHERE id 1 FOR UPDATE; -- 执行更新逻辑 UPDATE table SET num num - 1 WHERE id 1; COMMIT;2.4 适用场景高并发写入、资源争抢频率极高、零脏数据容忍的核心流程库存扣减、资金交易、订单核销、账务结算等业务。三、乐观锁高性能无阻塞锁3.1 核心设计思想默认日常并发冲突极少不提前上锁直接执行业务查询与更新逻辑更新操作前通过版本号 version、更新时间戳 update_time 校验当前数据是否被其他请求修改校验失败则判定冲突执行放弃或重试逻辑。3.2 核心特点全程无阻塞、无锁等待系统并发吞吐性能更高仅依靠普通字段判断实现无数据库行锁资源开销冲突发生后需要业务层手动编写重试逻辑极端高频争抢场景会产生大量重试消耗 CPU 资源。3.3 通用实现 SQL 模板1.建表增加版本字段CREATE TABLE demo( id INT PRIMARY KEY, count INT, version INT DEFAULT 0 );2.更新时校验版本UPDATE demo SET count count - 1, version version 1 WHERE id 1 AND version 1;执行后判断受影响行数等于 0 代表数据已被其他线程修改触发冲突重试。3.4 适用场景低并发修改、读多写少业务基础信息修改、普通表单更新、静态统计数据录入、配置更新等冲突概率极低的场景。四、悲观锁 vs 乐观锁完整对比表对比维度悲观锁乐观锁执行逻辑先上锁、后操作、事务结束释放锁先查询操作、更新前校验版本冲突重试并发性能低高争抢场景大量请求阻塞排队高全程无锁阻塞数据安全能力极高完全避免并发数据覆盖较高依赖版本字段校验兜底数据库资源开销高长期占用行锁资源极低仅普通条件判断高频争抢场景适配适合无无限重试损耗不适合大量冲突重试消耗 CPU事务依赖强依赖事务锁生命周期绑定事务不强制依赖完整事务单条 UPDATE 即可实现五、SQLite 专属操作系统文件锁前面两种锁均基于服务型数据库行锁嵌入式 SQLite 无行锁、表锁能力底层依靠操作系统文件锁实现并发隔离属于特殊锁机制。底层原理 SQLite 数据库为单一磁盘文件区分两种文件锁共享锁读、排他锁写。1.读请求加共享锁多进程可同时读取写请求加排他锁同一时间全局仅允许一个写入操作。即使开启 WAL 读写分离优化也只能做到读写不互斥写入操作依旧串行执行2.致命缺陷仅支持单机本地文件NFS、SMB 共享磁盘下文件锁失效直接造成数据错乱多进程高频写入频繁抛出database is locked锁超时异常锁粒度是整个数据库文件无法精准锁定单行数据。3.通用规避方案 开启 WAL 模式、延长 busy_timeout 锁等待时间、批量合并写入、上层增加写入重试逻辑多服务共用 SQLite 文件架构不推荐长期使用。六、Redis 分布式锁跨机器集群专用悲观锁、乐观锁、SQLite 文件锁全部仅在单台服务器、单个数据库实例内生效微服务、多节点分布式架构下需要全局锁控制并发此时采用 Redis 分布式锁。1.实现核心原理 利用 Redis 单命令原子性抢占锁SET lock_key unique_id NX EX 30NXkey 不存在时才创建代表抢占锁成功EX设置锁自动过期时间防止进程崩溃永久死锁unique_id客户端唯一标识避免释放其他线程的锁。2.优势与短板优势跨服务器、跨服务全局互斥适配分布式集群高并发场景短板依赖 Redis 服务可用性需要处理主从切换丢锁、任务未完成锁过期等边界问题。3.适用场景 多实例微服务、多服务器部署、定时任务防重复执行、分布式库存扣减等单机锁无法覆盖的场景。对比维度悲观锁MySQL/PG乐观锁版本号SQLite 文件锁Redis 分布式锁生效范围单机数据库实例内单机数据库实例内仅限单台本机✅ 跨机器、分布式集群锁粒度行级 / 表级逻辑行级业务层整库文件自定义业务 Key阻塞特性阻塞等待争抢会排队无阻塞冲突后重试写操作全局串行阻塞抢占模式抢不到可重试并发写入上限较高行锁互不干扰高冲突依赖重试很低同一时刻只能一个写高全局互斥依赖组件MySQL/PostgreSQL任意关系数据库SQLite OS 文件锁Redis 服务典型缺陷长事务易引发锁等待、死锁超高并发场景大量重试消耗 CPU共享盘 (NFS/SMB) 锁失效、频繁database is locked需要处理锁过期、主从切换丢锁、防误释放典型适用场景单机核心交易、库存、资金业务读多写少、配置、普通表单更新单机小型工具、低并发本地存储微服务、多服务器集群、定时任务防重复七、落地选型完整判断标准单机 MySQL/PostgreSQL、高争抢核心交易、不允许脏数据 → 悲观锁单机服务、读多写少、修改频次低 → 乐观锁单机嵌入式工具、使用 SQLite 存储数据 → 依靠文件锁 重试兜底不适合高并发写入多服务器、微服务分布式集群单机锁失效 → Redis 分布式锁补充建议SQLite 无行锁能力长期迭代、多进程项目建议迁移 PostgreSQL从底层规避锁竞争问题。八、总结并发锁是统称用来解决多请求同时修改共享资源引发的数据冲突根据单机、分布式场景衍生出悲观锁、乐观锁、文件锁、分布式锁多种实现。悲观锁以牺牲并发性能换取绝对数据安全是核心资金、库存业务首选乐观锁无阻塞、吞吐更高适合查询为主、极少修改的通用业务SQLite 文件锁是嵌入式数据库妥协方案存在天生并发上限仅适合低流量单机工具分布式多节点架构单机数据库锁完全失效必须引入 Redis 分布式锁实现全局并发控制锁架构选型不能一概而论需要结合部署架构单机 / 分布式、业务修改频次、数据容错要求综合判断避免前期架构埋坑。
一、前言高并发场景下多个请求同时修改同一行数据若无并发控制机制会出现数据覆盖、状态错乱、统计数值不准、库存超卖等脏数据问题。 关系型数据库提供两套原生并发控制方案悲观锁、乐观锁二者设计思路完全相反适配不同并发争抢场景。除此之外嵌入式数据库、分布式集群还有专属锁实现方案下文一并完整拆解。并发锁是一类并发控制机制的统称。在多线程、多进程、多服务并发场景下多个请求同时读写同一份共享数据时用来协调访问顺序、防止并发修改造成脏数据、数据覆盖、状态错乱的方案。后端开发中常见实现方案包含悲观锁、乐观锁、SQLite 操作系统文件锁、Redis 分布式锁。 不同锁底层实现、生效范围、并发能力差异巨大需要结合部署架构单机 / 分布式、业务并发压力选型。二、悲观锁强一致性锁2.1 核心设计思想默认并发一定会产生资源冲突操作数据前先主动锁定目标资源整个事务全程持有锁事务提交 / 回滚后才释放其余请求必须阻塞排队等待锁释放后才能操作数据。2.2 核心特点数据安全性极高完全杜绝并发修改覆盖问题存在线程阻塞、排队等待逻辑资源争抢激烈时整体并发吞吐大幅下降依赖数据库原生行锁、表锁机制实现仅 MySQL、PostgreSQL 这类服务型数据库支持长事务会长期占用锁极易引发锁等待超时、接口雪崩。2.3 基础 SQL 示例-- 开启事务并对目标行加悲观行锁 BEGIN; SELECT * FROM table WHERE id 1 FOR UPDATE; -- 执行更新逻辑 UPDATE table SET num num - 1 WHERE id 1; COMMIT;2.4 适用场景高并发写入、资源争抢频率极高、零脏数据容忍的核心流程库存扣减、资金交易、订单核销、账务结算等业务。三、乐观锁高性能无阻塞锁3.1 核心设计思想默认日常并发冲突极少不提前上锁直接执行业务查询与更新逻辑更新操作前通过版本号 version、更新时间戳 update_time 校验当前数据是否被其他请求修改校验失败则判定冲突执行放弃或重试逻辑。3.2 核心特点全程无阻塞、无锁等待系统并发吞吐性能更高仅依靠普通字段判断实现无数据库行锁资源开销冲突发生后需要业务层手动编写重试逻辑极端高频争抢场景会产生大量重试消耗 CPU 资源。3.3 通用实现 SQL 模板1.建表增加版本字段CREATE TABLE demo( id INT PRIMARY KEY, count INT, version INT DEFAULT 0 );2.更新时校验版本UPDATE demo SET count count - 1, version version 1 WHERE id 1 AND version 1;执行后判断受影响行数等于 0 代表数据已被其他线程修改触发冲突重试。3.4 适用场景低并发修改、读多写少业务基础信息修改、普通表单更新、静态统计数据录入、配置更新等冲突概率极低的场景。四、悲观锁 vs 乐观锁完整对比表对比维度悲观锁乐观锁执行逻辑先上锁、后操作、事务结束释放锁先查询操作、更新前校验版本冲突重试并发性能低高争抢场景大量请求阻塞排队高全程无锁阻塞数据安全能力极高完全避免并发数据覆盖较高依赖版本字段校验兜底数据库资源开销高长期占用行锁资源极低仅普通条件判断高频争抢场景适配适合无无限重试损耗不适合大量冲突重试消耗 CPU事务依赖强依赖事务锁生命周期绑定事务不强制依赖完整事务单条 UPDATE 即可实现五、SQLite 专属操作系统文件锁前面两种锁均基于服务型数据库行锁嵌入式 SQLite 无行锁、表锁能力底层依靠操作系统文件锁实现并发隔离属于特殊锁机制。底层原理 SQLite 数据库为单一磁盘文件区分两种文件锁共享锁读、排他锁写。1.读请求加共享锁多进程可同时读取写请求加排他锁同一时间全局仅允许一个写入操作。即使开启 WAL 读写分离优化也只能做到读写不互斥写入操作依旧串行执行2.致命缺陷仅支持单机本地文件NFS、SMB 共享磁盘下文件锁失效直接造成数据错乱多进程高频写入频繁抛出database is locked锁超时异常锁粒度是整个数据库文件无法精准锁定单行数据。3.通用规避方案 开启 WAL 模式、延长 busy_timeout 锁等待时间、批量合并写入、上层增加写入重试逻辑多服务共用 SQLite 文件架构不推荐长期使用。六、Redis 分布式锁跨机器集群专用悲观锁、乐观锁、SQLite 文件锁全部仅在单台服务器、单个数据库实例内生效微服务、多节点分布式架构下需要全局锁控制并发此时采用 Redis 分布式锁。1.实现核心原理 利用 Redis 单命令原子性抢占锁SET lock_key unique_id NX EX 30NXkey 不存在时才创建代表抢占锁成功EX设置锁自动过期时间防止进程崩溃永久死锁unique_id客户端唯一标识避免释放其他线程的锁。2.优势与短板优势跨服务器、跨服务全局互斥适配分布式集群高并发场景短板依赖 Redis 服务可用性需要处理主从切换丢锁、任务未完成锁过期等边界问题。3.适用场景 多实例微服务、多服务器部署、定时任务防重复执行、分布式库存扣减等单机锁无法覆盖的场景。对比维度悲观锁MySQL/PG乐观锁版本号SQLite 文件锁Redis 分布式锁生效范围单机数据库实例内单机数据库实例内仅限单台本机✅ 跨机器、分布式集群锁粒度行级 / 表级逻辑行级业务层整库文件自定义业务 Key阻塞特性阻塞等待争抢会排队无阻塞冲突后重试写操作全局串行阻塞抢占模式抢不到可重试并发写入上限较高行锁互不干扰高冲突依赖重试很低同一时刻只能一个写高全局互斥依赖组件MySQL/PostgreSQL任意关系数据库SQLite OS 文件锁Redis 服务典型缺陷长事务易引发锁等待、死锁超高并发场景大量重试消耗 CPU共享盘 (NFS/SMB) 锁失效、频繁database is locked需要处理锁过期、主从切换丢锁、防误释放典型适用场景单机核心交易、库存、资金业务读多写少、配置、普通表单更新单机小型工具、低并发本地存储微服务、多服务器集群、定时任务防重复七、落地选型完整判断标准单机 MySQL/PostgreSQL、高争抢核心交易、不允许脏数据 → 悲观锁单机服务、读多写少、修改频次低 → 乐观锁单机嵌入式工具、使用 SQLite 存储数据 → 依靠文件锁 重试兜底不适合高并发写入多服务器、微服务分布式集群单机锁失效 → Redis 分布式锁补充建议SQLite 无行锁能力长期迭代、多进程项目建议迁移 PostgreSQL从底层规避锁竞争问题。八、总结并发锁是统称用来解决多请求同时修改共享资源引发的数据冲突根据单机、分布式场景衍生出悲观锁、乐观锁、文件锁、分布式锁多种实现。悲观锁以牺牲并发性能换取绝对数据安全是核心资金、库存业务首选乐观锁无阻塞、吞吐更高适合查询为主、极少修改的通用业务SQLite 文件锁是嵌入式数据库妥协方案存在天生并发上限仅适合低流量单机工具分布式多节点架构单机数据库锁完全失效必须引入 Redis 分布式锁实现全局并发控制锁架构选型不能一概而论需要结合部署架构单机 / 分布式、业务修改频次、数据容错要求综合判断避免前期架构埋坑。
