实际生产开发到底怎么用锁？单体本地锁/数据库锁/Redis分布式锁 真实场景

前言：别再瞎加锁！生产用锁只看「场景+部署环境」

很多新手学完并发、学完各种锁概念，依然不会写代码。核心通病就一个：背了一堆乐观锁、悲观锁、死锁八股，到了实际开发，不知道什么时候该加锁、该加哪种锁。

我做了多年Java后端，从单体SpringBoot做到SpringCloud微服务集群，线上从没乱加过锁，也从没出过并发数据错乱、超卖、重复扣款事故。今天不讲晦涩底层原理、不深挖AQS、不讲锁升级源码，只讲生产开发唯一有用的核心事：什么样的业务场景、什么样的服务器部署环境，必须用哪种锁，直接匹配场景、附上错误翻车代码、生产可直接上线可用代码。

看完这篇你就彻底搞懂所有生产锁核心问题：

• ✅ 普通简单CRUD业务为啥一辈子不用加任何锁

• ✅ 单体项目内存简单计数、本地监控用什么锁最合适

• ✅ 电商下单扣库存、余额扣款防超卖核心业务用什么锁兜底

• ✅ 微服务集群秒杀、分布式定时任务防重复执行用什么锁最优

先记住生产终极锁选型口诀，全篇围绕这个核心落地：

单实例、内存临时计数 → 用Java本地锁；集群核心账务扣库存 → 用数据库锁；微服务集群高并发、分布式任务 → 用Redis分布式锁。

一、第一种锁：Java单体本地锁（synchronized+Atomic原子类）

1.1 精准适用生产场景（只有这种情况才用，多一概不碰）

✅ 同时满足两个条件，无脑直接用本地锁，性价比最高：

1. 项目是单体SpringBoot单实例部署，无集群、无多台服务器负载均衡、无微服务拆分；

2. 业务仅为内存临时统计、本地接口热度限流、内存瞬时计数器，不跨服务调用、不涉及核心资金账务、不做库存扣减、无需持久化存储。

❌ 绝对禁止使用场景：集群分布式环境、微服务跨服务业务、下单扣款核心交易、秒杀库存扣减、分布式定时任务防重。本地锁仅作用于单JVM内存，集群多实例下完全失效，并发数据错乱必翻车。

1.2 真实生产业务案例

开发单体项目接口访问次数实时统计功能，无需频繁读写数据库，仅在内存累计接口瞬时访问量，用于后台简单监控接口调用热度、排查接口异常波动，无需长久持久化、无需跨实例共享数据。

1.3 ❌ 错误写法（不加锁，并发必计数错乱）

多用户多线程同时访问接口，普通成员变量自增存在线程安全问题，计数互相覆盖丢失数据，统计结果永远不准确，监控功能直接失效。

@RestController@RequestMapping("/monitor")publicclassMonitorController{// 成员变量共享，多线程并发修改必出现数据覆盖错乱privateintvisitCount=0;@GetMapping("/visit")publicStringvisit(){// 线程不安全自增操作，高并发下必丢计数数据visitCount++;return"接口当前累计访问次数："+visitCount;}}

1.4 ✅ 生产正确写法1：synchronized本地锁（新手简单首选，零学习成本）

单实例环境下完美生效，通过JVM层面保证同一时间只允许一个线程执行计数逻辑，并发排队串行执行，计数数据绝对准确，代码改动极小、上手无门槛。

@RestController@RequestMapping("/monitor")publicclassMonitorController{privateintvisitCount=0;// 加本地锁，单实例并发线程排队执行，彻底解决计数错乱问题@GetMapping("/visit")publicsynchronizedStringvisit(){visitCount++;return"【synchronized本地锁】累计访问次数："+visitCount;}}

1.5 ✅ 生产正确写法2：AtomicLong原子类（性能更好，计数专用生产推荐）

基于无锁CAS自旋操作实现线程安全，无重量级锁阻塞开销，比synchronized同步锁性能高出数倍，是生产内存计数、本地轻度限流的首选方案。

@RestController@RequestMapping("/monitor")publicclassMonitorController{// 原子类天然线程安全，替代普通int变量，无需手动加锁privatefinalAtomicLongvisitTotal=newAtomicLong(0);@GetMapping("/visit/atomic")publicStringvisitAtomic(){// 原子自增方法，高并发计数永不丢失、无数据覆盖longcurrent=visitTotal.incrementAndGet();return"【Atomic原子类本地锁】累计访问次数："+current;}}

1.6 实操核心答疑：单体计数场景，直接用Redis不加锁代替Java本地锁可以吗？

很多新手都会纠结：单体项目做接口访问计数、本地临时统计，不想用synchronized、Atomic本地锁，直接把计数放Redis里，不加任何锁，能不能直接用？

生产标准答案：语法能跑、并发安全，但生产绝不推荐，纯属杀鸡用牛刀。

1、为啥Redis不加锁也能计数安全？

Redis核心底层是单线程模型执行核心读写命令，所有increment、get、set等操作串行排队执行，天然具备并发安全特性。单体项目计数直接用Redis自增命令increment，多线程同时访问也不会出现计数覆盖、数据错乱，不需要手动加任何锁。

// Redis不加锁实现单体计数，并发安全但生产不推荐使用@RestController@RequestMapping("/monitor")publicclassRedisCountController{@AutowiredprivateStringRedisTemplateredisTemplate;privatestaticfinalStringCOUNT_KEY="local:monitor:visit:count";@GetMapping("/visit/redis")publicStringvisitRedis(){// Redis自增，单线程串行执行，天然安全无需手动加锁Longcount=redisTemplate.opsForValue().increment(COUNT_KEY,1);return"【Redis无锁计数】累计访问次数："+count;}}

2、为啥生产单体计数不用Redis，非要用Java本地锁？

• 性能差距巨大：Atomic本地内存计数是纳秒级响应，Redis计数需要额外网络IO、数据序列化、网络往返开销，性能慢几十上百倍，高频监控计数差距极其明显；

• 架构冗余没必要：只是单体临时内存统计，不需要数据持久化、不需要跨服务共享数据，没必要额外依赖Redis中间件，增加架构复杂度；

• 运维徒增风险：Java本地锁不依赖任何第三方组件，Redis一旦宕机、网络波动、集群超时，计数监控功能直接失效，徒增线上故障风险。

生产最终选择：单体纯本地临时计数、无需持久化场景，优先用AtomicLong/Java本地锁；只有计数需要跨服务共享、长久持久化归档，才用Redis无锁计数。

二、第二种锁：数据库锁（悲观锁for update+乐观锁版本号，生产核心账务核心）

原基础内容仅提供了数据库悲观锁、乐观锁实操代码，缺少MySQL数据库锁核心底层划分维度、引擎适配规则、锁层级权责划分，这也是很多开发加锁后依然出现锁失效、超卖、数据库死锁、性能卡顿的核心原因。下面先补充生产开发必须掌握的数据库锁四大核心划分维度，打通原理和实操关联，再衔接原有生产案例和落地代码，做到懂原理、会写代码、不踩坑。

2.1 数据库锁生产四大核心划分维度（必懂，锁生效与否全靠这个）

MySQL数据库锁不是单一形态，生产使用、代码加锁、故障排查都要按四大维度精准区分，不同维度组合决定锁的生效范围、性能高低、并发能力，绝非简单只分悲观锁和乐观锁。

维度一：按并发控制策略划分（开发日常最常用，核心设计思想层面）

这是业务开发层面最常讨论的锁分类，核心区别在于对待并发冲突的预判态度，也是我们代码实操悲观锁、乐观锁的核心依据，直接对应库存扣减、账务扣款业务选型。

• 悲观锁：默认认为并发一定会出现数据修改冲突，提前提前加锁锁住资源，其他线程/服务必须排队等待，当前事务执行完毕释放锁后才能操作。核心追求数据绝对一致性，牺牲部分并发性能，适合核心账务、库存扣款不容出错的业务。

• 乐观锁：默认认为并发数据修改冲突概率极低，不上锁不阻塞线程，仅在数据更新时校验数据是否被其他线程修改过，冲突则直接更新失败，可代码重试处理。核心追求高并发高性能，容忍少量冲突重试，适合并发量大、冲突少、非极致强一致的业务。

维度二：按锁定粒度划分（锁影响范围，决定并发性能高低）

锁定粒度指加锁后锁住的数据库资源范围，粒度越小并发性能越好，粒度越大锁冲突越多、性能越差，核心和MySQL存储引擎强绑定，InnoDB和MyISAM引擎默认粒度完全不同。

• 行锁：InnoDB引擎默认支持，仅锁住当前操作的单条数据行，其他数据行不受影响，并发互不干扰，粒度最小、并发性能最好，生产扣库存、单条账务修改必须用行锁；

• 表锁：MyISAM引擎默认锁粒度，加锁直接锁住整张数据表，所有读写操作全部阻塞排队，粒度最大、并发极差，仅适合静态数据、极少修改的字典表，核心业务绝对禁用；

• 页锁：MySQL中间过渡锁粒度，锁住数据库数据页（多行数据），性能和并发介于行锁和表锁之间，生产开发几乎不用，无需业务层面手动关注。

维度三：按读写模式划分（MySQL InnoDB底层真实锁实现，锁生效底层核心）

这是MySQL引擎底层实际运行的锁类型，我们代码写的悲观锁、行锁，底层都是基于这几类读写锁实现，不懂这个就会出现明明加锁却锁失效、锁升级为表锁的隐形问题。

• 共享锁（S锁）：读锁，多个线程可同时加共享锁、并行读数据，互不阻塞；但加了共享锁后，任何线程都无法加排他锁修改数据，保证读数据期间数据不被篡改；

• 排他锁（X锁）：写锁，也就是我们悲观锁for update底层用到的核心锁，同一时间只允许一个线程加排他锁读写数据，其他所有线程读写全部阻塞排队，保证数据修改期间绝对独占；

• 意向锁（IS/IX意向共享/意向排他锁）：InnoDB自动维护、无需代码手动加，是表级辅助锁，作用是快速判断数据表是否有行锁冲突，避免全表遍历校验，优化锁判断效率，开发无需手动操作，只需了解存在即可。

维度四：按作用层级划分（区分谁管锁、谁写代码，锁权责核心）

核心区分锁能力来自数据库引擎，还是业务代码架构设计，彻底搞懂锁是全自动生效，还是需要程序员手动编码实现，告别锁失效不知道原因的问题。

• 数据库引擎锁：锁的核心能力由MySQL底层引擎提供，锁的加锁、释放、排队机制由数据库自动管控，程序员只需代码触发即可。典型代表：悲观锁for update，数据库提供行锁、事务锁能力，代码只需要开启事务、手写加锁SQL，事务提交/回滚后数据库自动释放锁；

• 应用层锁（代码/架构锁）：数据库仅作为数据存储“计算器”，不提供任何锁机制，所有锁校验、冲突判断、重试逻辑全部由业务代码手动实现。典型代表：乐观锁版本号机制，数据库只负责存储version版本字段，加锁校验、冲突重试、版本更新全靠代码编写，数据库不做任何自动锁管控。

2.2 精准适用生产场景（核心账务必用，不分单体集群）

✅ 满足以下场景，无脑用数据库锁兜底，稳定性拉满：

1. 项目集群部署、微服务SpringCloud多实例负载均衡环境，本地锁完全失效；

2. 核心资金账务业务：电商下单扣商品库存、用户账户余额扣款、订单防重复创建、资金对账核算；

3. 业务要求数据绝对强一致性，零容忍超卖、重复扣款、数据错乱、账务不平事故。

核心优势：不管部署多少台服务器集群，数据库锁全局唯一生效，依托InnoDB引擎行级锁机制，数据兜底稳定性拉满，无需额外运维Redis等中间件，核心账务生产首选兜底方案。

2.3 真实生产业务案例

电商平台下单扣商品库存业务，服务集群多实例部署，高并发下单场景下，必须保证商品库存绝不超卖、扣减数据精准无误，哪怕并发量不算极高，核心账务也必须加数据库锁兜底防护。

2.4 ❌ 错误写法（不加锁，集群必超卖，锁维度不配置直接翻车）

多台服务实例同时查询库存、判断库存、执行扣减，无任何锁管控，并发逻辑直接绕过业务判断，库存被扣成负数，出现严重超卖、资损事故，哪怕后续补数据也无法挽回线上影响。

// 危险代码：无锁扣库存，集群环境必超卖，生产严禁使用@TransactionalpublicvoiddeductStock(LonggoodsId){// 多线程多实例同时查询，拿到同一个库存数值，并发判断全部绕过Stockstock=stockMapper.selectById(goodsId);if(stock.getStockNum()>0){// 并发同时执行扣减，数据互相覆盖，库存直接扣成负数超卖stock.setStockNum(stock.getStockNum()-1);stockMapper.updateById(stock);}}

2.5 ✅ 生产写法1：数据库悲观锁 for update（强一致首选，底层行级排他锁兜底）

基于InnoDB引擎**行级排他锁（X锁）**实现，查询库存时手动加for update悲观锁，精准锁住当前商品单条数据行，其他服务线程自动排队等待，当前事务执行完毕提交后，数据库引擎自动释放锁，彻底杜绝超卖，强一致业务首选。

第一步：Mapper自定义手写悲观锁查询SQL（触发数据库引擎行锁，框架无自带方法）

// 数据库悲观锁查询：精准锁住当前数据行，集群全局生效，底层加行级排他锁@Select("select * from stock where goods_id = #{goodsId} for update")StockselectStockForUpdate(@Param("goodsId")LonggoodsId);

第二步：Service业务扣减代码（事务加持+引擎自动锁管控）

@ServicepublicclassStockService{@AutowiredprivateStockMapperstockMapper;// 事务必须开启，悲观锁生效完全依赖数据库事务，事务结束自动释放排他锁@Transactional(rollbackFor=Exception.class)publicvoiddeductStockPessimistic(LonggoodsId){// 悲观锁查询，InnoDB引擎加行级排他锁，其他线程排队阻塞Stockstock=stockMapper.selectStockForUpdate(goodsId);if(stock!=null&&stock.getStockNum()>0){// 独占资源安全扣减，绝对不会超卖、数据覆盖stock.setStockNum(stock.getStockNum()-1);stockMapper.updateById(stock);System.out.println("悲观锁扣库存成功，行锁已释放");}}}

2.6 ✅ 生产写法2：数据库乐观锁（版本号机制，应用层代码锁，高性能优选）

属于应用层代码锁范畴，数据库仅存储version版本号字段，无任何引擎自动锁机制，所有并发冲突校验、版本比对、失败重试全部由业务代码实现。无数据库锁阻塞开销，并发性能更好，适合并发量大、数据修改冲突概率低的库存业务。

第一步：库存表手动新增version版本号字段（数据库仅做存储，无锁逻辑）

第二步：代码层面实现版本号校验更新，匹配成功才扣减，冲突直接失败

@TransactionalpublicvoiddeductStockOptimistic(LonggoodsId){// 查询库存数据和当前版本号，数据库无任何加锁操作Stockstock=stockMapper.selectById(goodsId);if(stock.getStockNum()>0){// 更新核心条件：商品id匹配 + 版本号一致（证明数据未被其他线程修改）introws=stockMapper.updateStock(goodsId,stock.getVersion(),stock.getStockNum()-1,stock.getVersion()+1);// 更新行数为0，说明数据已被修改，并发冲突，可代码手动重试下单if(rows==0){thrownewRuntimeException("库存更新冲突，重试下单");}}}

2.7 数据库锁核心实操三连答疑（生产必懂，规避锁失效坑）

答疑1：数据库加锁，是代码加SQL还是数据库提前配置？锁谁管控？

**一句话死记：数据库无任何自动锁配置，所有悲观锁、乐观锁全靠程序员代码手动实现。**MySQL数据库本身不会自动上锁、自动防超卖、自动处理并发冲突，仅提供锁底层能力：悲观锁能力在数据库引擎，触发在代码SQL；乐观锁全在代码架构层，数据库只当数据存储计算器。代码不写锁逻辑，数据库裸奔运行，该超卖照样超卖。

答疑2：selectStockForUpdate是框架自带方法？

**明确答复：完全自己手写，Mybatis、Mybatis-Plus无任何自带for update锁查询方法。**框架自带查询都是普通无锁查询，想要InnoDB行级悲观锁，必须自定义Mapper方法、手写带for update的SQL，否则锁完全不生效。

答疑3：悲观锁、乐观锁是MySQL自动处理还是代码处理？

MySQL只提供底层锁能力，所有业务逻辑、冲突处理全靠代码：悲观锁MySQL负责加行锁、事务结束释锁，代码负责开事务、写加锁SQL；乐观锁MySQL负责存版本号，代码负责加字段、校验版本、处理冲突重试，无全自动托管锁。

三、第三种锁：Redis分布式锁（SpringCloud微服务集群高并发生产标配）

前面讲的Java本地锁、数据库锁，都有各自的场景边界：Java本地锁仅适用于单JVM单体实例，集群环境完全失效；数据库锁强一致性拉满，但基于磁盘IO和事务日志，高并发秒杀、高频防重场景性能瓶颈明显。而Redis分布式锁是微服务集群高并发场景下的核心并发协调方案，专门解决跨JVM、跨服务多实例之间的资源互斥访问问题，也是生产高并发业务必不可少的核心组件。

很多新手只知道用Redis加锁，但压根不懂Redis锁本质、不会区分锁类型、手写锁各种隐形bug频发、线上经常出现锁过期误删、死锁、业务超卖等问题。下面系统拆解Redis分布式锁核心概念、分类演进、精准选型、底层归属、代码实操、生产避坑，和前面数据库锁四大维度对应对齐，看完既能写代码、又能懂原理、线上绝不踩坑。

3.1 什么是Redis分布式锁？核心本质必懂

Redis分布式锁核心定义：基于Redis高性能内存读写特性、单命令原子执行机制，在Java应用代码层面自行封装实现的分布式协调互斥机制。

核心核心作用只有三个，精准对标生产痛点：

• 解决跨JVM、跨微服务多实例的同一资源并发抢占问题，统一集群全局互斥规则；

• 防止分布式定时任务重复执行、接口重复提交、秒杀商品超卖、缓存击穿等高并发线上事故；

• 仅做应用层并发协调，不替代数据库事务强一致性，只负责流量拦截和并发互斥。

生产关键切记：Redis本身没有原生内置“锁”专属数据结构和锁命令！分布式锁不是Redis自带功能，是开发者利用Redis原子命令、过期特性组合封装的代码设计模式，所有锁逻辑、互斥规则全靠代码实现。

3.2 Redis分布式锁常见类型（按生产能力演进，按需选用）

Redis锁不是只有一种简单排他锁，根据业务复杂度、并发需求、调用场景分为五类，生产99%业务只用基础排他锁和可重入锁，复杂框架Redisson已全部封装，无需手写底层。

生产选型铁律：永远不要手写各类Redis锁底层！直接使用Redisson客户端，所有锁类型、原子性、续期、防误删逻辑已全部封装，开箱即用稳定可靠。

3.3 精准适用生产场景+与数据库锁核心选型对比（再也不选错）

很多开发纠结到底用Redis锁还是数据库锁，核心记住：Redis锁管高并发协调拦截，数据库锁管核心资金数据强一致兜底，两者经常搭配使用，各司其职。

生产黄金选型口诀：跨实例高并发协调拦截用Redis锁，单库核心账务强一致兜底用数据库锁；Redis挡99%无效并发，数据库兜底100%数据安全。

3.4 核心实操答疑：Redis锁是原生自带？改数据库还是改Redis配置？

和数据库锁逻辑对齐，统一搞懂锁的归属、配置位置、生效原理，避免配置改错、锁不生效。

• **Redis是否原生自带分布式锁？**❌ 完全没有！Redis只提供SET、DEL、Lua脚本等基础命令，锁的互斥逻辑、过期释放、所有权校验全是代码封装；

• **在哪里配置和触发锁？**✅ 完全在Java业务代码中实现，通过Redisson、RedisTemplate客户端发送命令，无需修改数据库任何配置；

• **需要额外改Redis核心配置吗？**无需特殊配置，仅建议基础优化：开启AOF持久化防锁Key丢失、调整内存淘汰策略避免锁Key被LRU误删；

• **锁数据存在哪里？**存储在Redis内存中，结构为：锁Key（业务唯一标识）、锁Value（线程唯一ID防误删）、TTL自动过期时间防死锁。

3.5 Java代码两种实现方式（手写懂原理，生产只用Redisson）

3.5.1 手写极简版Redis锁（仅学习理解原理，生产绝对禁止上线）

新手必须看懂手写版踩坑点，明白为啥生产不能自己造轮子，核心要保证加锁原子性、解锁校验所有权、防止误删他人锁。

// ❌ 错误致命写法：加锁和设置过期时间分两步，非原子，服务宕机必死锁if(redisTemplate.opsForValue().setIfAbsent("distribute:lock:task","lock")){redisTemplate.expire("distribute:lock:task",30,TimeUnit.SECONDS);// 非原子，极易死锁try{/* 业务逻辑 */}finally{redisTemplate.delete("distribute:lock:task");}}// ✅ 正确原子手写版（仅学习，生产不用）@ServicepublicclassTaskLockService{@AutowiredprivateStringRedisTemplateredisTemplate;privatestaticfinalStringTASK_LOCK_KEY="distribute:lock:schedule:task";publicvoidrunScheduleTask(){// 定义唯一标识，防止误删其他线程锁StringlockUuid=UUID.randomUUID().toString();// 原子加锁：不存在则设置+自动过期30秒，一步完成防死锁BooleanlockSuccess=redisTemplate.opsForValue().setIfAbsent(TASK_LOCK_KEY,lockUuid,30,TimeUnit.SECONDS);// 加锁失败直接跳过任务，防止重复执行if(!Boolean.TRUE.equals(lockSuccess)){System.out.println("其他服务正在执行定时任务，本机跳过");return;}try{// 上锁成功执行业务定时任务逻辑System.out.println("本机获取分布式锁成功，开始执行定时统计任务");// 此处替换真实业务：数据统计、订单对账、批量数据同步等}finally{// 解锁必须校验当前线程所有权，绝不误删别人的锁StringcurrentUuid=redisTemplate.opsForValue().get(TASK_LOCK_KEY);if(lockUuid.equals(currentUuid)){redisTemplate.delete(TASK_LOCK_KEY);System.out.println("任务执行完成，释放分布式锁");}}}}

3.5.2 生产标准唯一写法：Redisson分布式锁（线上直接复制上线）

手写锁存在锁续期、可重入、公平调度、异常容错等无数短板，生产统一使用Redisson，内置看门狗自动续期、锁所有权校验、可重入机制、异常自动释锁，零踩坑。

第一步：引入Maven依赖

<!-- Redisson分布式锁核心依赖，SpringBoot无缝整合 --><dependency><groupId>org.redisson</groupId><artifactId>redisson-spring-boot-starter</artifactId><version>3.25.0</version></dependency>

第二步：生产业务落地代码（自带看门狗防锁过期，无需手动续期）

@ServicepublicclassRedissonTaskLockService{// 注入Redisson核心客户端，自动装配无需手动配置@AutowiredprivateRedissonClientredissonClient;// 按业务维度定义全局唯一锁Key，业务隔离避免误锁privatestaticfinalStringTASK_LOCK_KEY="distribute:lock:schedule:task:statistic";publicvoidrunScheduleTask(){// 获取可重入分布式锁实例RLocklock=redissonClient.getLock(TASK_LOCK_KEY);try{// 阻塞抢占锁，默认开启看门狗机制，业务未执行完自动续期30秒，防止锁提前过期lock.lock();// 上锁成功，仅一台服务执行业务逻辑System.out.println("Redisson分布式锁获取成功，单机执行定时对账统计任务");// 核心业务逻辑：订单对账、数据批量同步、库存预热、定时统计等}finally{// 安全解锁：仅当前线程持有锁才解锁，防止误删、重复解锁报错if(lock.isHeldByCurrentThread()){lock.unlock();System.out.println("任务执行完毕，安全释放Redisson分布式锁");}}}}

3.6 生产Redis分布式锁避坑指南&最佳实践（线上必看，杜绝故障）

3.7 架构师终极总结

Redis分布式锁不是Redis原生功能，是应用层代码实现的分布式协调工具；高并发集群防重、秒杀限流用Redis锁扛流量，核心资金账务、库存扣款用数据库锁做兜底；生产坚决摒弃手写Redis锁，统一使用Redisson开箱即用，配合看门狗续期、所有权校验规避所有线上隐形坑，Redis锁拦并发、数据库锁保数据双锁架构，是微服务生产最稳最优方案。

四、生产终极锁选型对照表（新手直接查表，永不选错）

五、老开发最终一句话总结（牢记不踩锁所有坑）

1. 普通简单CRUD业务，只用局部变量，一辈子不用加任何锁，画蛇添足易出问题；

2. 单体项目内存临时计数，就用Java本地锁，简单够用、性能拉满、无冗余依赖；

3. 集群环境核心账务扣库存、资金扣款，就用数据库锁，InnoDB行锁兜底、稳定不超卖；

4. 微服务集群高并发秒杀、分布式定时任务，就用Redis分布式锁，性能最优、集群互斥。