lol道聚城项目实战：从0到1的保姆级教程
是不是刚学完Python或Java基础，对着空白的编辑器发呆？知道for循环怎么写，知道类怎么继承，但一旦要做一个像样点的项目，脑子就一片空白。这种“手残”感太常见了。今天这篇保姆级教程，我们不讲虚的，直接拿lol道聚城这个经典电商案例开刀。我们要把底层原理拆碎了揉进代码里，让你明白一个高并发商城是怎么跑起来的。别被名字吓到，核心逻辑就是“商品展示+购物车+下单支付”，把这套流程吃透，面试时你就有底气说“我做过项目”。
一句话原理：高并发下的库存扣减与状态流转
在lol道聚城这类系统中，最核心的痛点不是怎么把皮肤图显示出来，而是高并发下的库存一致性。想象一下，S级皮肤“至臻系列”上架瞬间，几万人同时点击购买。如果代码写得不好，就会出现“超卖”（卖了100件，库存只有80件）或者“少卖”（有人付款成功，但订单状态卡在初始化）。
底层原理其实很简单：CAS（Compare-And-Swap）原子操作配合分布式锁或Redis预扣减。数据库直接扣减太慢，必须把热点数据搬到内存（Redis），在内存里做快速判断和扣减，然后再异步同步到MySQL数据库。这就是为什么电商架构里，Redis的地位举足轻重。
类比解释：超市收银台与货架模型
为了让你秒懂，我们用一个线下超市的类比。
假设lol道聚城的服务器是一个大型超市。MySQL数据库是仓库深处的货架。每次去仓库拿货，都要走很远的路，而且仓库管理员（DBA）很谨慎，每次只能处理一单，速度极慢。
Redis缓存是收银台旁边的展示柜。商品就摆在手边，伸手就能拿，速度极快。普通写法（直接操作MySQL）：
用户点击购买 - 请求到达收银台 - 收银员跑去仓库查库存 - 确认有货 - 跑去仓库扣减库存 - 回来告诉用户成功。
如果100个人同时买同一款皮肤，收银员就得跑100趟仓库。仓库门口堵死，系统崩溃。
高并发写法（Redis预扣减）：
用户点击购买 - 请求到达收银台 - 收银员先看展示柜（Redis）有没有货 - 如果有，直接在展示柜划掉一件（原子操作） - 告诉用户“扣减成功，正在后台处理” - 后台线程慢慢去仓库（MySQL）同步数据。
这样，收银台的压力被分散了，仓库也不会瞬间拥堵。这就是lol道聚城项目中最经典的缓存穿透、击穿、雪崩防护机制的实际应用场景。
源码/伪代码片段：Redis原子扣减的核心逻辑
很多初学者以为扣减库存就是stock - 1，这在Java里是非原子操作。在多线程环境下，两个线程同时读到stock=1，同时执行减1，结果都写回0，但实际卖出了2件。
下面是一段基于Java + Redisson（Redis客户端框架）的lol道聚城库存扣减核心逻辑伪代码。注意看compareAndSet和Lua脚本的原子性保证。
/*** lol道聚城 核心库存服务类* 技术栈: Spring Boot + Redisson + MySQL*/
@Service
public class InventoryService {@Autowiredprivate RedissonClient redissonClient;/*** 尝试扣减库存* @param itemId 商品ID (例如: lol-skin-10086)* @param amount 扣减数量* @return true: 扣减成功; false: 库存不足*/public boolean tryDeductStock(Long itemId, int amount) {String stockKey = lol_daoju_city:stock: + itemId;// 1. 获取分布式锁，防止同一用户并发重复下单（可选，通常结合业务ID做幂等）// 这里我们演示更底层的Lua原子扣减，性能优于加锁// 2. 使用Lua脚本保证“判断”和“扣减”的原子性String luaScript = local stock = tonumber(redis.call('get', KEYS[1])) +if (stock ~= nil) and (stock = tonumber(ARGV[1])) then + redis.call('decrby', KEYS[1], ARGV[1]) + return 1 +else + return 0 +end;RScript script = redissonClient.getScript();// 3. 执行脚本// KEYS[1]: 商品库存Key// ARGV[1]: 需要扣减的数量Long result = script.eval(RScript.Mode.READ_WRITE, luaScript, RScript.ReturnType.INTEGER, Collections.singletonList(stockKey), amount);// 4. 判断结果return result != null result == 1L;}/*** 初始化库存（商品上架时调用）*/public void initStock(Long itemId, int initialStock) {String stockKey = lol_daoju_city:stock: + itemId;// 设置过期时间，防止死数据，比如24小时未售出自动清理缓存redissonClient.getBucket(stockKey).set(initialStock, 24, TimeUnit.HOURS);}
}逐行讲解关键点：redis.call('get', KEYS[1]): 在Redis服务端获取当前库存。
if (stock = tonumber(ARGV[1])): 在内存中判断库存是否足够。这一步避免了频繁访问数据库。
redis.call('decrby', KEYS[1], ARGV[1]): 如果足够，直接原子性地减少库存。Redis的decrby命令本身是原子的，不会丢失更新。
为什么不用if-else在Java代码里写？ 因为Java的if判断和Redis的decrby是两次网络往返。在两次操作之间，其他线程可能已经扣减了库存，导致超卖。Lua脚本让Redis把这些指令打包成一个整体执行，中间不会有其他命令插入。流程描述：从点击购买到支付成功的完整链路
理解了原子扣减，我们来看lol道局城整个交易的全景流程图。这是一个典型的最终一致性方案。用户请求：用户在网页点击“立即购买”，前端发送POST请求到API网关。
参数校验与幂等性检查：网关层校验Token，并检查订单号是否已存在（防止用户手抖双击提交）。
预扣减库存：调用上述tryDeductStock方法。如果返回false，直接返回前端“库存不足”，流程结束。
如果返回true，继续下一步。创建订单：在MySQL中创建一条状态为WAIT_PAY（待支付）的订单记录。此时不扣减MySQL库存，只记录订单快照（价格、商品ID、用户ID）。
发送MQ消息：将订单信息发送到消息队列（如RabbitMQ或Kafka），Topic为order-created。
异步处理：服务A（库存同步服务）：消费order-created消息，真正去MySQL执行UPDATE stock SET count = count - 1 WHERE id = ?。如果MySQL扣减失败（比如库存真的没了），则触发补偿机制。
服务B（通知服务）：消费消息，发送短信或站内信通知用户。支付回调：用户支付成功，第三方支付平台（如支付宝）回调通知。
订单状态更新：将MySQL订单状态改为PAID（已支付）。
发货/发卡：如果是虚拟商品（lol皮肤），直接发放到账号邮箱或客户端；如果是实物，生成物流单。关键细节：为什么第4步不直接扣MySQL？
因为MySQL的写性能远低于Redis。如果在高并发下，10万个请求都走到MySQL去扣库存，数据库连接池会瞬间耗尽。通过Redis预扣减，我们可以拦截掉99%的无效请求（库存不足的请求），只有真正扣减成功的少量请求才会进入数据库。
实战验证：如何避免“超卖”与“少卖”
在lol道局城的实际开发中，光有Redis扣减还不够，必须处理异常场景。
场景一：Redis扣减成功，但MySQL写入失败（网络抖动）后果：用户以为买到了，但订单没生成，或者订单生成了但库存没扣。
解决方案：引入事务消息或本地消息表。在创建订单时，先在MySQL事务里插入订单（状态INIT）和一条消息记录（状态PENDING）。
事务提交后，发送MQ消息。
如果MQ发送失败，定时任务扫描PENDING状态的消息进行重发。
保证“订单创建”和“消息发送”的原子性。场景二：支付超时，订单取消后果：Redis里的库存被预扣减了，但用户没付款，库存被“锁定”了。
解决方案：延迟队列。下单时，向MQ发送一条延迟30分钟的消息。
30分钟后，消费者检查订单状态。如果仍是WAIT_PAY，则取消订单，并调用addStock方法，将Redis和MySQL的库存加回去。
这里要注意，回补库存也要考虑并发，最好也用Lua脚本或incrby原子操作。Stack Overflow上的经典争议：
在Stack Overflow上，关于“Redis扣减后MySQL回滚”的问题讨论极多。很多开发者初期喜欢用try-catch包裹MySQL操作，如果失败就redis.incr回补。但这有个隐患：如果程序在redis.decr和mysql.update之间崩溃（比如服务器断电），库存就永久丢失了。
更稳健的做法是：以MySQL为准，Redis只是加速层。Redis扣减成功。
发MQ消息。
消费者去MySQL扣减。
如果MySQL扣减失败，不直接回补Redis，而是记录一条“异常流水”。
后台定时任务对比Redis库存和MySQL库存，发现不一致时，以MySQL为准修正Redis，并报警。
这种“最终一致性”方案在金融级和电商级项目中更为常见，因为它能容忍短暂的不一致，但能保证数据最终准确。进阶技巧与避坑指南缓存预热：
lol道局城在皮肤上新前，必须提前将库存加载到Redis。如果冷启动，第一个请求可能穿透到MySQL，导致缓存击穿。可以在应用启动时，或者通过定时任务，将热销商品库存同步到Redis。热点Key检测：
如果某个S级皮肤特别火，Redis的单线程可能成为瓶颈。可以使用本地缓存（Caffeine） + Redis的两级缓存结构。本地缓存负责挡住99%的读请求，Redis负责写操作和全局一致性。前端防抖与限流：
在lol道局城的前端代码中，按钮点击后要立即置灰，防止用户狂点。同时，网关层（Nginx或Sentinel）要配置限流规则，比如每个IP每秒最多10次请求。数据一致性监控：
写一个简单的脚本，每5分钟比对一次Redis和MySQL的库存。如果差异超过阈值（比如5件），立即告警。这是线上运维的保命符。面试高频问题预警：
面试官很可能会问：“你的lol道局城项目里，Redis和MySQL数据不一致怎么办？”
如果你能答出：“采用最终一致性方案，通过MQ异步同步，结合定时任务比对修正，并设置告警机制”，这比背诵八股文要有说服力得多。
这个知识点你面试被问过吗？留言说说 lol道聚城项目实战：从0到1的保姆级教程
lol道聚城项目实战：从0到1的保姆级教程
是不是刚学完Python或Java基础，对着空白的编辑器发呆？知道for循环怎么写，知道类怎么继承，但一旦要做一个像样点的项目，脑子就一片空白。这种“手残”感太常见了。今天这篇保姆级教程，我们不讲虚的，直接拿lol道聚城这个经典电商案例开刀。我们要把底层原理拆碎了揉进代码里，让你明白一个高并发商城是怎么跑起来的。别被名字吓到，核心逻辑就是“商品展示+购物车+下单支付”，把这套流程吃透，面试时你就有底气说“我做过项目”。
一句话原理：高并发下的库存扣减与状态流转
在lol道聚城这类系统中，最核心的痛点不是怎么把皮肤图显示出来，而是高并发下的库存一致性。想象一下，S级皮肤“至臻系列”上架瞬间，几万人同时点击购买。如果代码写得不好，就会出现“超卖”（卖了100件，库存只有80件）或者“少卖”（有人付款成功，但订单状态卡在初始化）。
底层原理其实很简单：CAS（Compare-And-Swap）原子操作配合分布式锁或Redis预扣减。数据库直接扣减太慢，必须把热点数据搬到内存（Redis），在内存里做快速判断和扣减，然后再异步同步到MySQL数据库。这就是为什么电商架构里，Redis的地位举足轻重。
类比解释：超市收银台与货架模型
为了让你秒懂，我们用一个线下超市的类比。
假设lol道聚城的服务器是一个大型超市。MySQL数据库是仓库深处的货架。每次去仓库拿货，都要走很远的路，而且仓库管理员（DBA）很谨慎，每次只能处理一单，速度极慢。
Redis缓存是收银台旁边的展示柜。商品就摆在手边，伸手就能拿，速度极快。普通写法（直接操作MySQL）：
用户点击购买 - 请求到达收银台 - 收银员跑去仓库查库存 - 确认有货 - 跑去仓库扣减库存 - 回来告诉用户成功。
如果100个人同时买同一款皮肤，收银员就得跑100趟仓库。仓库门口堵死，系统崩溃。
高并发写法（Redis预扣减）：
用户点击购买 - 请求到达收银台 - 收银员先看展示柜（Redis）有没有货 - 如果有，直接在展示柜划掉一件（原子操作） - 告诉用户“扣减成功，正在后台处理” - 后台线程慢慢去仓库（MySQL）同步数据。
这样，收银台的压力被分散了，仓库也不会瞬间拥堵。这就是lol道聚城项目中最经典的缓存穿透、击穿、雪崩防护机制的实际应用场景。
源码/伪代码片段：Redis原子扣减的核心逻辑
很多初学者以为扣减库存就是stock - 1，这在Java里是非原子操作。在多线程环境下，两个线程同时读到stock=1，同时执行减1，结果都写回0，但实际卖出了2件。
下面是一段基于Java + Redisson（Redis客户端框架）的lol道聚城库存扣减核心逻辑伪代码。注意看compareAndSet和Lua脚本的原子性保证。
/*** lol道聚城 核心库存服务类* 技术栈: Spring Boot + Redisson + MySQL*/
@Service
public class InventoryService {@Autowiredprivate RedissonClient redissonClient;/*** 尝试扣减库存* @param itemId 商品ID (例如: lol-skin-10086)* @param amount 扣减数量* @return true: 扣减成功; false: 库存不足*/public boolean tryDeductStock(Long itemId, int amount) {String stockKey = lol_daoju_city:stock: + itemId;// 1. 获取分布式锁，防止同一用户并发重复下单（可选，通常结合业务ID做幂等）// 这里我们演示更底层的Lua原子扣减，性能优于加锁// 2. 使用Lua脚本保证“判断”和“扣减”的原子性String luaScript = local stock = tonumber(redis.call('get', KEYS[1])) +if (stock ~= nil) and (stock = tonumber(ARGV[1])) then + redis.call('decrby', KEYS[1], ARGV[1]) + return 1 +else + return 0 +end;RScript script = redissonClient.getScript();// 3. 执行脚本// KEYS[1]: 商品库存Key// ARGV[1]: 需要扣减的数量Long result = script.eval(RScript.Mode.READ_WRITE, luaScript, RScript.ReturnType.INTEGER, Collections.singletonList(stockKey), amount);// 4. 判断结果return result != null result == 1L;}/*** 初始化库存（商品上架时调用）*/public void initStock(Long itemId, int initialStock) {String stockKey = lol_daoju_city:stock: + itemId;// 设置过期时间，防止死数据，比如24小时未售出自动清理缓存redissonClient.getBucket(stockKey).set(initialStock, 24, TimeUnit.HOURS);}
}逐行讲解关键点：redis.call('get', KEYS[1]): 在Redis服务端获取当前库存。
if (stock = tonumber(ARGV[1])): 在内存中判断库存是否足够。这一步避免了频繁访问数据库。
redis.call('decrby', KEYS[1], ARGV[1]): 如果足够，直接原子性地减少库存。Redis的decrby命令本身是原子的，不会丢失更新。
为什么不用if-else在Java代码里写？ 因为Java的if判断和Redis的decrby是两次网络往返。在两次操作之间，其他线程可能已经扣减了库存，导致超卖。Lua脚本让Redis把这些指令打包成一个整体执行，中间不会有其他命令插入。流程描述：从点击购买到支付成功的完整链路
理解了原子扣减，我们来看lol道局城整个交易的全景流程图。这是一个典型的最终一致性方案。用户请求：用户在网页点击“立即购买”，前端发送POST请求到API网关。
参数校验与幂等性检查：网关层校验Token，并检查订单号是否已存在（防止用户手抖双击提交）。
预扣减库存：调用上述tryDeductStock方法。如果返回false，直接返回前端“库存不足”，流程结束。
如果返回true，继续下一步。创建订单：在MySQL中创建一条状态为WAIT_PAY（待支付）的订单记录。此时不扣减MySQL库存，只记录订单快照（价格、商品ID、用户ID）。
发送MQ消息：将订单信息发送到消息队列（如RabbitMQ或Kafka），Topic为order-created。
异步处理：服务A（库存同步服务）：消费order-created消息，真正去MySQL执行UPDATE stock SET count = count - 1 WHERE id = ?。如果MySQL扣减失败（比如库存真的没了），则触发补偿机制。
服务B（通知服务）：消费消息，发送短信或站内信通知用户。支付回调：用户支付成功，第三方支付平台（如支付宝）回调通知。
订单状态更新：将MySQL订单状态改为PAID（已支付）。
发货/发卡：如果是虚拟商品（lol皮肤），直接发放到账号邮箱或客户端；如果是实物，生成物流单。关键细节：为什么第4步不直接扣MySQL？
因为MySQL的写性能远低于Redis。如果在高并发下，10万个请求都走到MySQL去扣库存，数据库连接池会瞬间耗尽。通过Redis预扣减，我们可以拦截掉99%的无效请求（库存不足的请求），只有真正扣减成功的少量请求才会进入数据库。
实战验证：如何避免“超卖”与“少卖”
在lol道局城的实际开发中，光有Redis扣减还不够，必须处理异常场景。
场景一：Redis扣减成功，但MySQL写入失败（网络抖动）后果：用户以为买到了，但订单没生成，或者订单生成了但库存没扣。
解决方案：引入事务消息或本地消息表。在创建订单时，先在MySQL事务里插入订单（状态INIT）和一条消息记录（状态PENDING）。
事务提交后，发送MQ消息。
如果MQ发送失败，定时任务扫描PENDING状态的消息进行重发。
保证“订单创建”和“消息发送”的原子性。场景二：支付超时，订单取消后果：Redis里的库存被预扣减了，但用户没付款，库存被“锁定”了。
解决方案：延迟队列。下单时，向MQ发送一条延迟30分钟的消息。
30分钟后，消费者检查订单状态。如果仍是WAIT_PAY，则取消订单，并调用addStock方法，将Redis和MySQL的库存加回去。
这里要注意，回补库存也要考虑并发，最好也用Lua脚本或incrby原子操作。Stack Overflow上的经典争议：
在Stack Overflow上，关于“Redis扣减后MySQL回滚”的问题讨论极多。很多开发者初期喜欢用try-catch包裹MySQL操作，如果失败就redis.incr回补。但这有个隐患：如果程序在redis.decr和mysql.update之间崩溃（比如服务器断电），库存就永久丢失了。
更稳健的做法是：以MySQL为准，Redis只是加速层。Redis扣减成功。
发MQ消息。
消费者去MySQL扣减。
如果MySQL扣减失败，不直接回补Redis，而是记录一条“异常流水”。
后台定时任务对比Redis库存和MySQL库存，发现不一致时，以MySQL为准修正Redis，并报警。
这种“最终一致性”方案在金融级和电商级项目中更为常见，因为它能容忍短暂的不一致，但能保证数据最终准确。进阶技巧与避坑指南缓存预热：
lol道局城在皮肤上新前，必须提前将库存加载到Redis。如果冷启动，第一个请求可能穿透到MySQL，导致缓存击穿。可以在应用启动时，或者通过定时任务，将热销商品库存同步到Redis。热点Key检测：
如果某个S级皮肤特别火，Redis的单线程可能成为瓶颈。可以使用本地缓存（Caffeine） + Redis的两级缓存结构。本地缓存负责挡住99%的读请求，Redis负责写操作和全局一致性。前端防抖与限流：
在lol道局城的前端代码中，按钮点击后要立即置灰，防止用户狂点。同时，网关层（Nginx或Sentinel）要配置限流规则，比如每个IP每秒最多10次请求。数据一致性监控：
写一个简单的脚本，每5分钟比对一次Redis和MySQL的库存。如果差异超过阈值（比如5件），立即告警。这是线上运维的保命符。面试高频问题预警：
面试官很可能会问：“你的lol道局城项目里，Redis和MySQL数据不一致怎么办？”
如果你能答出：“采用最终一致性方案，通过MQ异步同步，结合定时任务比对修正，并设置告警机制”，这比背诵八股文要有说服力得多。
这个知识点你面试被问过吗？留言说说