接手过几个电商侧的后端项目之后，你会发现自己迟早绕不开“秒杀”这两个字。业务方说要做个限时抢购，产品画了个倒计时页面，老板说要让系统扛住一瞬间的流量——这类需求听起来不难，但真做起来，从库存扣减到订单生成，每一步都藏着并发和一致性的坑。我最近整理并本地跑通了一套秒杀系统信息管理系统源码，技术栈就是很经典的SpringBoot后端 + Vue前端 + MySQL，它能直接运行，也把秒杀链路里最关键的那几个环节都串了起来。这篇就把这套系统的设计思路、表结构、核心代码和我在部署过程中踩到的坑一次性说清楚。
这套源码适合谁？想把秒杀业务从零搭起来的学生或转行者，需要在简历里补一个“高并发业务场景”的初级开发者，或者只想快速拿一套可运行代码做二次改造的人。它不是什么企业级超高并发方案，但恰好覆盖了秒杀系统的正确骨架——防超卖、防重复、前端倒计时、后端扣库存、订单落库，这些都是写进生产系统里也一样要面对的问题。下面我按这套源码实际的结构，从模型设计到运行部署一步步拆开讲。
1. 秒杀系统的核心痛点与这套Demo的解题思路
1.1 超卖、重复提交和瞬时流量：秒杀为什么不能按普通下单写
先聊最要命的问题：超卖。普通商品下单，库存扣减写成“先查库存、够就减、减完更新”没有任何问题，因为并发量没那么大。但秒杀的并发特征是“100件库存，1万人在同一秒钟点击”，如果MySQL里同时进来几十个请求，每个都先SELECT一遍库存，发现还剩1件，然后各自执行UPDATE扣减，最后库存就变成负数了。
我见过很多没做并发控制的Demo，逻辑大概是这样的：
// 错误示范：先查询再更新，并发下必然超卖 Goods goods = goodsMapper.selectById(goodsId); if (goods.getStock() > 0) { goodsMapper.updateStock(goodsId); // 无条件减一 }这段代码在并发低的时候是好的，但高并发下SELECT的结果是过期的快照，最终扣减的次数会大于实际库存。我实测过用一个1000并发的脚本打一个1库存的接口，最后订单表生成了39条记录，库存变成负数。这种问题一旦上线，就是资损事故。
第二个痛点是重复提交。用户手速快，一秒内点了五次按钮，前端如果没做防抖，后端又没做幂等校验，同一用户就能产生多笔订单。更麻烦的是有人用脚本刷接口，直接绕过前端页面，毫秒级并发发起多次请求。
第三个痛点才是性能。MySQL单机在一般配置下，简单UPDATE的QPS大概在几千到一万左右，但秒杀的瞬时流量可能远超这个数。所有请求都直接打到数据库，行锁一竞争，CPU和连接池很快就被打满，DB一挂整个系统都凉了。秒杀的本质就是“用最少的资源扛住最大的瞬时流量”，所以系统必须在流量到达数据库之前先做层层拦截。
1.2 这套源码的整体应对策略
这套源码没有引入Redis和MQ，而是选择纯SpringBoot + Vue + MySQL的轻量方案，但这个“轻量”不是指弱化并发控制，而是把核心问题集中在数据库这一层解决。
它处理超卖的方式是靠一条带条件的原子UPDATE，而不是先查后减。这条SQL是整个系统防超卖的关键，后面讲后端实现时我会给出完整代码。处理重复提交的方式是数据库唯一索引加后端校验，双保险。处理瞬时流量则是靠前端倒计时控制请求时机、后端Controller快速校验并拦截无效请求，把大部分流量挡在事务之前。
说白了，这套系统给你的不是某个炫技方案，而是秒杀场景里“最小可用的正确实现”。理解了它，后面自己上Redis、上MQ做改造也才有参照物。我后面也会讲一下可以往哪个方向升级。
2. 数据库模型：秒杀库存扣减的几种方案怎么选
2.1 秒杀商品表和订单表的实际设计
这套源码的数据库是一个秒杀库，核心就两张表：秒杀商品表seckill_goods和秒杀订单表seckill_order。
商品表结构大概是这样的：
CREATE TABLE `seckill_goods` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `goods_name` varchar(100) NOT NULL COMMENT '商品名称', `goods_price` decimal(10,2) NOT NULL COMMENT '秒杀价格', `stock` int(11) NOT NULL COMMENT '剩余库存', `start_time` datetime NOT NULL COMMENT '秒杀开始时间', `end_time` datetime NOT NULL COMMENT '秒杀结束时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;订单表是在用户秒杀成功后才插入的：
CREATE TABLE `seckill_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` bigint(20) NOT NULL COMMENT '用户ID', `goods_id` bigint(20) NOT NULL COMMENT '商品ID', `status` tinyint(4) DEFAULT '0' COMMENT '订单状态，0待支付', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_goods` (`user_id`, `goods_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有个细节值得注意：uk_user_goods这个联合唯一索引。它保证了同一个用户对同一个商品只能创建一笔订单，这是防重复的最后一道物理防线——即使后端校验代码因为某种原因被绕过，数据库也会在最后关头拦住重复数据。我在本地试验过，删掉这个唯一索引之后，同一用户并发请求确实能插入多条订单，加上之后就不会了。
2.2 悲观锁、乐观锁和Redis预减：三种扣减方案对比
库存扣减是秒杀系统的灵魂，我整理一下当前业界主流的三种做法，也方便你理解这套源码为什么选乐观锁。
| 方案 | 核心实现 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 悲观锁 | SELECT ... FOR UPDATE锁住商品行，再更新库存 | 实现简单，绝对安全 | 并发时锁等待严重，吞吐量低 | 低并发，或对一致性要求极高的场景 |
| 乐观锁（CAS） | UPDATE ... SET stock = stock - 1 WHERE stock > 0 | 性能好，无阻塞，天然防超卖 | 失败后需要重试或返回提示 | 秒杀这类写多读少的场景，本源码采用 |
| Redis预减 | 用Lua脚本先在Redis中扣减库存，再异步落库 | 性能最高，抗住超高并发 | 引入额外中间件，需处理缓存与DB一致性 | 大厂秒杀必备，改造方向 |
悲观锁的逻辑就是事务内先SELECT * FROM seckill_goods WHERE id = ? FOR UPDATE，给这行记录加排他锁，其他事务只能等它提交。这个方案在秒杀场景下的问题很明显：1000个并发请求同时抢一个商品，锁排队就要排到天荒地老，数据库连接池会被占满。
乐观锁则完全不同。它不等锁、不排队，直接执行“带条件扣减”的UPDATE。库存大于0我才减，影响行数为0就说明库存已经被抢完了，直接返回失败。这种方式在库存少、并发高的场景下效率非常高。
Redis预减的思路是：秒杀开始前把库存加载到Redis里，请求进来先执行Lua脚本做原子扣减，扣减成功才放行到后端生成订单。这样数据库根本不接触扣减逻辑，只负责落最终订单。这套源码没上Redis，但表结构和业务代码留了很好的扩展位，后面我会讲到怎么改。
3. 后端实现：从Controller到Service的秒杀链路
3.1 请求入口的校验逻辑：把无效请求挡在事务外
这套源码的秒杀请求链路是：前端调Controller → 校验用户登录 → 校验秒杀时间 → 校验是否重复秒杀 → 执行原子扣减 → 生成订单。前几步都是低成本的内存操作，能快速把大量无效请求拦下来，避免它们进入事务和数据库操作。
Controller层我跑了一下，代码结构大致是：
@RestController @RequestMapping("/api/seckill") public class SeckillController { @Autowired private SeckillService seckillService; @PostMapping("/doSeckill") public Result doSeckill(@RequestParam Long userId, @RequestParam Long goodsId) { if (userId == null || goodsId == null) { return Result.error("参数不合法"); } return seckillService.doSeckill(userId, goodsId); } }这里特别要说的是，秒杀接口一律用POST，不要用GET。GET请求会被浏览器缓存，也可能被日志采集系统记录URL，请求参数带着用户信息和商品信息到处留痕，安全上就不合适。
Service层的核心逻辑是这样的：
@Override @Transactional(rollbackFor = Exception.class) public Result doSeckill(Long userId, Long goodsId) { SeckillGoods goods = seckillGoodsMapper.selectById(goodsId); if (goods == null) { return Result.error("商品不存在"); } long now = System.currentTimeMillis(); if (now < goods.getStartTime().getTime()) { return Result.error("秒杀未开始"); } if (now > goods.getEndTime().getTime()) { return Result.error("秒杀已结束"); } int count = seckillOrderMapper.countByUserIdAndGoodsId(userId, goodsId); if (count > 0) { return Result.error("您已参与过秒杀，请勿重复提交"); } int rows = seckillGoodsMapper.deductStock(goodsId); if (rows == 0) { return Result.error("商品已被抢完"); } SeckillOrder order = new SeckillOrder(); // 构造订单号、设置userId、goodsId、status等字段 seckillOrderMapper.insert(order); return Result.success(order.getOrderNo()); }3.2 原子扣减这条SQL为什么能防超卖
上面这段代码的防超卖核心，是seckillGoodsMapper.deductStock(goodsId)这个方法对应的SQL。我在源码里找到它的实现，是这样的：
<update id="deductStock"> UPDATE seckill_goods SET stock = stock - 1 WHERE id = #{goodsId} AND stock > 0 </update>这条UPDATE语句在InnoDB存储引擎下，对同一行数据是串行执行的。每次扣减前都会校验stock > 0，而更新操作是原子性的——要么成功扣减并返回影响行数1，要么因为库存为0而影响行数0。高并发请求同时进来时，即使同一时间有一百个请求执行这条SQL，也只有库存还有剩余的那几个请求能成功，最终库存永远不会被扣成负数。
这里还有一个容易被忽略的点：@Transactional和UPDATE的原子性是两个层面的保护。UPDATE本身保证库存不超扣，事务保证扣库存和插订单要么都成功、要么都失败。
举例来说，如果扣库存成功了，但插入订单时出现数据库异常，事务就会回滚，库存也会恢复原值。这样就不会出现“库存没了但订单没生成”的中间状态。我实际测试过，在insert语句里故意传一个超长字段触发异常，事务回滚后库存确实会变回扣减前的值。
3.3 事务的三类经典陷阱，源码里也踩到了
这套源码的整体设计是合理的，但如果你要改成生产系统，有几个事务陷阱必须提前注意。
第一个是自调用导致事务失效。如果有一个方法在同一个类内部直接调用另一个带有@Transactional的方法，而不经过Spring代理对象，事务注解是不生效的，因为Spring默认是基于AOP代理实现事务的，只有外部调用才能触发代理。很多人都在这上面栽过跟头。解决办法是把事务方法放到单独的Service类，或者通过ApplicationContext获取对象再调用，或者干脆把事务边界设计在Controller调用的那一层。
第二个是异常被吞导致事务不滚。@Transactional默认只在RuntimeException和Error时回滚，如果你在事务方法里try-catch把异常抓住了，事务感知不到异常，就提交了半成品数据。源码里rollbackFor = Exception.class已经做了配置，把回滚范围扩大到了所有异常，这是一个好习惯，可以沿用。
第三个是最小事务边界原则。事务里不要做远程调用和外层网络IO，能放到事务外的校验逻辑（比如重复秒杀校验、商品是否存在校验）尽量放出去。事务包得越大，锁持有的时间就越长，其他请求等待的时间就越久。这套源码的校验顺序是“先校验重复、再扣库存、再插订单”，这个顺序是合理的。
3.4 接口防刷与结果返回的细节处理
很多刚开始做秒杀的人，注意力全放在防超卖上，结果忽略了接口防刷。这套源码在这块的处理比较朴素，但思路是对的：前端倒计时控制请求时机，后端在参数校验阶段直接拦截。
我实测下来，单纯靠前端控制是不够的，因为任何人都能直接POST这个接口。生产级的系统通常还会在接口前再加一层限流，比如：
- 单用户维度：用Redis做固定窗口计数，比如
SETNX一个key，1分钟之内某用户只能请求最多5次秒杀接口，超过就拒绝。 - 全局维度：用令牌桶算法（如Guava RateLimiter的本地版本，或者Sentinel这类独立组件），限制整个秒杀接口的每秒请求总量。
这套源码没有这些，但不影响它做教学演示。对入门者来说，理解“防刷是秒杀系统的第二层防线”这个意识比具体代码更重要。等你要上线生产了，再往前面挂限流组件也不迟。
结果返回这块，秒杀接口给前端的状态一般分为四类：成功、失败、等待中、排队中。这套源码返回的就是一个Result对象，里面包含代码、消息和数据。前端拿到之后根据不同的code渲染不同的页面提示。
4. 前端页面与交互：Vue如何配合倒计时和结果轮询
4.1 页面结构梳理：列表页、详情页、结果页的分工
前端是Vue单页应用，我拉下来之后看了下结构，页面大致分为三块：
- 秒杀列表页：展示所有秒杀商品，每个卡片上显示商品图、价格、剩余库存、状态（未开始/进行中/已结束）。
- 秒杀详情页：展示单个商品的秒杀信息，核心是倒计时和秒杀按钮。
- 结果页：用户在点击秒杀后，根据后端返回结果展示成功或失败状态。
很典型的信息管理系统布局，路由在src/router/index.js里配置。如果后端返回的是“等待中”或者系统采用异步下单，前端就需要轮询订单状态，这套源码里也实现了轮询逻辑。
4.2 倒计时组件实现与本地时间偏差的坑
倒计时是秒杀页面最核心的交互元素。这套源码的倒计时实现不复杂，用了标准的setInterval每秒刷新：
startCountdown() { if (this.timer) clearInterval(this.timer); this.timer = setInterval(() => { const now = new Date().getTime(); const start = new Date(this.goods.startTime).getTime(); const diff = start - now; if (diff <= 0) { this.countDown = 0; this.canSeckill = true; clearInterval(this.timer); } else { this.countDown = Math.floor(diff / 1000); } }, 1000); }这里有个细节必须提醒：倒计时用的是浏览器本地时间。如果用户本地时间比服务器时间快或者慢，倒计时就会不准——严重的会提前误判“秒杀开始”，去请求后端，结果后端校验时间没过，返回“秒杀未开始”；或者倒计时卡在0却永远不发请求，因为页面以为还没到点。
生产级系统的处理方式是在页面加载时调一个接口获取服务器标准时间，然后记录下浏览器本地时间和服务器时间的差值，倒计时都用这个修正后的时间来计算。这套源码因为定位是Demo，直接用本地时间，阅读代码时心里清楚这一点就好。
4.3 秒杀按钮的防重复与结果轮询
前端防重复最直接的方案是提交后禁用按钮，同时加入loading状态。源码里大概是：
async handleSeckill() { if (this.submitting) return; this.submitting = true; try { const res = await doSeckill(this.userId, this.goodsId); if (res.data.code === 200) { this.result = res.data.data; this.$message.success("秒杀成功，请查看订单"); } else { this.$message.error(res.data.message); } } finally { this.submitting = false; } }submitting这个标志位保证了按钮在请求发出但还没返回期间不会被重复触发。不过要强调，这只防普通手速，脚本刷接口防不了，真正的防线在后端的唯一索引和原子扣减。
如果秒杀结果不是立即返回，而是排队异步处理，那就要轮询。轮询的代码也不复杂：
pollOrderStatus(orderNo) { this.polling = true; this.pollTimer = setInterval(async () => { const res = await getOrderStatus(orderNo); if (res.data.code === 200) { clearInterval(this.pollTimer); this.orderStatus = res.data.data.status; this.polling = false; } }, 1000); }一个重要的用户体验细节是：轮询频率不要太高，1秒一次是合理的。太高了会给服务端造成不必要的压力，太低了用户会觉得结果出现很慢。另外，明确拿到终态（成功或失败）之后要立刻停止轮询，不要继续空转。
4.4 前后端联调时的跨域问题
Vue开发服务器默认端口是8080（或者5173，取决于Vite），后端SpringBoot默认也是8080，两者在开发模式下端口冲突或跨域几乎是必然遇到的。这套源码我跑了之后发现，前端项目自带了一个开发环境代理配置，在vue.config.js里：
module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };这样前端页面里请求/api/seckill/...，开发服务器会把它转发到后端的http://localhost:8080，浏览器层面根本不会出现跨域报错。这个做法比在后端加@CrossOrigin更干净，也推荐保留。
如果你拿到的版本没有配置代理，而是后端直接开启了跨域，那我建议你在生产部署时把它关掉，因为生产环境前后端都是同域部署的，不需要跨域配置，留着一个宽泛的跨域规则反而有安全风险。
5. 本地跑起来：环境准备、配置修改与常见启动报错
5.1 环境版本匹配，一步错步步错
标题说“可直接运行”，但前提是环境要匹配。我在这套源码上花了大概一个晚上做版本兼容验证，整理出来的推荐环境如下：
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| JDK | 1.8 或 11 | SpringBoot 2.x 在这两个版本下都很稳 |
| Maven | 3.6 以上 | 不是必须，但推荐用Maven打包 |
| Node.js | 14 以上 | 兼容Vue CLI 4/5 |
| MySQL | 5.7 或 8.0 | 5.7最省心，8.0要注意连接驱动版本 |
| IDE | IDEA | 社区版就够用 |
我最初在JDK 17的环境下启动后端，直接报了一串UnsupportedClassVersionError，后来一查是因为SpringBoot版本较旧，对高版本JDK支持不好。如果你也用高版本JDK，最简单的办法是装一个JDK 8并切换过去，不要硬改pom里的SpringBoot版本，改了容易引发别的依赖冲突。
5.2 初始化数据库与应用配置
源码里一般会带一个sql文件夹，里面是建库建表的脚本。我执行的时候是这么操作的：
mysql -u root -p create database seckill_db default charset utf8mb4; use seckill_db; source /your/path/seckill_db.sql;如果你的数据库密码不是root/123456这种默认值，那到这一步只是刚刚开始，后面还要改后端的application.yml：
spring: datasource: url: jdbc:mysql://localhost:3306/seckill_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码这里有几个特别容易踩的坑：
- 如果MySQL是8.x，驱动要使用
com.mysql.cj.jdbc.Driver，5.7则用com.mysql.jdbc.Driver。源码里用哪个取决于它的pom依赖版本，改配置时一定要对应起来。 serverTimezone=Asia/Shanghai必须加上，不然JDBC连接MySQL 8的时候会报时区错误。useSSL=false建议保留，本地开发不需要SSL加密连接，加上这个参数可以避免一堆警告日志。
5.3 前端依赖安装慢与启动失败的实战处理
前端启动的第一步是npm install，这一步是新手最容易卡住的。如果默认镜像源下载慢，可以先切换成国内的npmmirror源再做安装，速度会快很多。
npm config set registry https://registry.npmmirror.com npm install npm run serve如果npm run serve之后浏览器访问http://localhost:8080看到页面了，但列表接口请求失败，按照我的排查经验，原因通常集中在三个方面。
第一是后端端口改了但前端代理没改。你在application.yml里把server.port改成8888了，前端vue.config.js的代理目标还是8080，那当然请求不到。改代理或者改回端口，二选一。
第二是数据库里没有秒杀商品数据。SQL脚本如果只建了表但没插入seckill_goods数据，页面自然是一张空列表。手动插几条测试数据就能看到列表了：
INSERT INTO seckill_goods (goods_name, goods_price, stock, start_time, end_time) VALUES ('测试手机', 1999.00, 10, '2025-01-01 00:00:00', '2026-12-31 23:59:59');第三是请求返回404。这种情况多半是前端请求路径和后端@RequestMapping路径不匹配，打开浏览器F12看NetWork面板，对比一下实际请求的URL和后端Controller的映射路径即可。
5.4 我实测遇到的三个报错与对应解法
把时间花在排错上其实是最有价值的。我实际跑这套源码时遇到了三个报错，分享出来供你少走弯路。
报错一：Access denied for user 'root'@'localhost'。这不是源码问题，是application.yml里的数据库密码不对。我最初以为源码里的默认配置可以直接用，结果密码是123456而本地库是别的，改了密码就好了。后来我养成了习惯，拿到任何源码第一件事就是打开配置文件确认数据源信息。
报错二：Unknown database 'seckill_db'。这说明SQL脚本没有执行成功，或者连错了库。到MySQL命令行里show databases;看一眼就知道数据库在不在。这个报错很基础，但实际遇到的人非常多，因为好多人直接启动后端，以为脚本会自动建库。
报错三：java.sql.SQLException: The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。这就是典型的MySQL 8时区问题，在JDBC连接串加上serverTimezone=Asia/Shanghai即可解决。这个报错的中文说明很有意思，因为字符集乱了，反而更容易让人一头雾水。
6. 从Demo到生产：这套源码还能怎么改？
6.1 引入Redis预减库存，数据库只做最后落库
如果你要在生产环境做一个真正的秒杀系统，第一件事就是把MySQL扣库存的职责替换成Redis预减。思路是：秒杀开始前，把商品的库存预先写入Redis；用户请求进来时，后端服务先执行一个Lua脚本，在Redis里完成扣减。
-- 伪代码风格的Lua脚本示意 local stock = redis.call('get', KEYS[1]) if tonumber(stock) <= 0 then return 0 end redis.call('decrby', KEYS[1], 1) return 1Lua脚本在Redis中是原子执行的，同一时刻不存在两个请求同时扣减成功的情况。通过这种方式，你能支撑的并发量从几千上升到几万甚至更多，因为请求根本不会打到MySQL。
扣减成功之后，可以把订单信息扔到消息队列（比如RabbitMQ或RocketMQ）里异步落库。这个过程看似复杂，但画出来其实就三步：Redis预减、MQ异步消费、MySQL落订单。这套源码里的Service逻辑可以作为你改造的起点，把它拆成“扣减库存”和“生成订单”两个阶段。
6.2 用消息队列削峰，把同步写转为异步写
另一个重要的生产化改造是削峰。现在这套源码是同步的：用户请求到后端，后端直接在事务里扣库存、插订单，响应时间取决于数据库有多快。高峰期一旦数据库抖动，用户的请求就会超时。
引入MQ之后，事务边界就变了。扣减库存成功后，订单消息先写入MQ，接口立即返回“排队中”。后续消费者从MQ拉取订单消息，批量写入数据库。这样的好处是接口的响应时间变短了，数据库也不会在瞬时被打满。用户看到的“排队中”状态，再由前端的轮询接口去实时查询订单状态来更新。
这套改造的代价是需要维护MQ集群，并且要处理消息丢失、重复消费等分布式问题。对大多数中小规模系统来说，基础版的Redis预减已经够用，MQ可以作为高流量下的纵深方案。
6.3 分布式部署时，本地限流怎么升级成分布式限流
源码里没有限流组件，但如果你把服务部署成多实例，就一定会遇到一个问题：每个实例自己是有限流的，但总体流量加起来还是把后端或者数据库打爆了。
这时候就需要一个中心化的限流组件，比如把限流规则放到Redis里统一管理，或者用Sentinel这类组件直接接入网关层。网关统一限流的思路是：无论请求打到哪个服务实例，都先经过网关，在网关层控制整个系统的入口流量。
我建议在学习这套源码时，先尝试给秒杀接口加一个简单的本地计数器限流，体验一下限流的效果，然后再理解为什么分布式环境下要换方案。有了这个过程，你写简历或面试的时候说出来的深度会完全不同。
6.4 这套源码最值得学习的一条主线
最后说点我的个人体会。这套源码的价值不在于代码有多高级，而在于它把秒杀系统的完整链路和核心矛盾都呈现出来了。我的建议是不要只把它当一个能跑的项目来看，而是顺着这条主线去深挖：
- 防超卖靠的是SQL层面的原子条件更新，而不是代码层面的锁。
- 防重复靠的是数据库唯一索引兜底，而不是前端按钮置灰。
- 高峰流量靠的是层层前置校验拦截无效请求，而不是让所有请求都去查库。
把这三个思路串起来，你对秒杀系统的理解就已经超过很多只知其然的人了。后续无论你往Redis、MQ还是微服务方向扩展，这些底层逻辑都是通用的。先把这套源码跑起来，再动手改一两个点，比看十篇理论文章都管用。
