MyBatisPlus性能优化：应对高并发下Token扣减延迟问题

MyBatisPlus性能优化：应对高并发下Token扣减延迟问题

在电商大促、秒杀抢购这类高并发场景中，系统常常面临一个看似简单却极具挑战的问题：如何在成千上万用户同时请求时，准确、快速地完成资源的原子性扣减？比如发放优惠券、扣除积分、限制接口调用频率等操作背后的“Token机制”，一旦处理不当，轻则响应延迟、用户体验下降，重则出现超发、数据不一致，甚至引发资损。

而当我们使用 MyBatisPlus 这类开发效率极高的 ORM 框架时，很容易陷入一种错觉——既然 CRUD 都能自动生成，那高频更新也应该没问题。但现实是，在没有针对性优化的情况下，原地执行update ... set count = count - 1的方式很快就会成为瓶颈。数据库锁竞争加剧、事务等待时间拉长、RT（响应时间）飙升至几百毫秒，完全无法满足高并发下的实时性要求。

那么，我们该如何打破这个困局？

从一次真实的性能瓶颈说起

曾经在一个抽奖活动中，团队直接基于 MyBatisPlus 实现了 Token 扣减逻辑：

UpdateWrapper<Token> wrapper = new UpdateWrapper<>(); wrapper.eq("id", tokenId) .gt("token_count", 0) .setSql("token_count = token_count - 1"); int rows = tokenMapper.update(null, wrapper);

初看简洁明了，测试环境也一切正常。可上线后发现：当并发量达到 2000+ QPS 时，平均响应时间从 5ms 直接跃升到 380ms，且数据库 CPU 居高不下。进一步排查发现，InnoDB 正在为同一行记录频繁加排他锁（X锁），大量事务排队等待，形成了典型的“热点行更新”问题。

这说明了一个关键点：ORM 的便捷性不能掩盖底层数据库的物理限制。我们需要的不只是“能跑通”的代码，而是真正具备高并发承载能力的设计。

为什么乐观锁 + MyBatisPlus 不一定够用？

很多人会说：“我用了乐观锁啊！”确实，MyBatisPlus 内置了@Version注解和插件支持，理论上可以通过版本号控制并发修改：

@Version private Integer version; // 更新条件包含 version 字段 wrapper.eq("version", current.getVersion());

但在极端高并发场景下，这种“先查后更”的模式反而可能加剧问题：

• 读写分离破坏原子性：selectById()和update()是两个独立操作，中间存在窗口期；
• 失败重试带来额外开销：每次冲突都需要重新查询最新状态，网络往返和 GC 压力陡增；
• 重试风暴风险：若多个线程持续失败并快速重试，可能导致雪崩效应。

换句话说，乐观锁适合“低频冲突”场景，但对于像秒杀这种几乎所有人都在争抢同一个资源的情况，它更像是“事后补救”，而非根本解决方案。

真正高效的路径：把压力从 DB 移出去

要解决高并发 Token 扣减的核心思路只有一条：让绝大多数请求根本不触达数据库。

这就引出了最有效的架构分层策略——引入 Redis 作为前置缓存层，承担高频读写压力。

Redis 如何实现毫秒级原子扣减？

Redis 提供了天然线程安全的原子操作，例如DECR和INCR，其内部由单线程事件循环保证执行顺序，无需任何额外锁机制。

我们可以将 Token 数量加载到 Redis 中，格式如：

token:1001 → 100

然后通过一条命令完成安全扣减：

Long remaining = redisTemplate.opsForValue().decrement("token:1001"); if (remaining >= 0) { // 成功，继续业务流程 } else { // 已耗尽 }

整个过程在微秒级别完成，即使面对数万 QPS 也能轻松应对。

更重要的是，Redis 的原子性确保了不会出现“超扣”问题——这是单纯依赖数据库也无法完全避免的风险（尤其在网络抖动或事务异常时）。

缓存与数据库的一致性怎么保障？

当然，把数据放进了内存，并不意味着可以忽略持久化。我们必须回答一个问题：如果服务宕机，Redis 数据丢失怎么办？

答案是采用“缓存预热 + 异步回写 + 最终一致性”的组合策略。

1. 缓存预热

系统启动时，从数据库批量加载所有有效 Token 到 Redis：

SELECT id, token_count FROM t_token WHERE status = 1;

并通过管道（pipeline）一次性写入 Redis，避免逐条网络通信开销。

2. 异步落库

不要每扣一次就同步写数据库。那样等于把压力又引回了 DB。

正确的做法是：
- 使用定时任务（如每 5 秒）扫描 Redis 中发生变化的 Key；
- 将差值通过UPDATE ... SET token_count = token_count - ?同步回 MySQL；
- 或者更优的方式——发送消息到 MQ（如 Kafka），由消费者异步合并更新。

这样既能保证数据最终一致，又能极大降低数据库写入频率。

3. 宕机恢复容灾

为防 Redis 故障，建议：
- 开启 AOF + RDB 持久化；
- 使用 Redis Cluster 部署，避免单点；
- 关键业务可结合 ZooKeeper 或 Etcd 记录“已发放总数”，重启后校准。

数据库层面也不能掉以轻心

虽然大部分流量被挡在了缓存层，但我们仍需做好数据库自身的优化，以防缓存失效或降级时系统崩溃。

主键索引必须存在

这是最基本的要求。假设你的表结构如下：

CREATE TABLE t_token ( id BIGINT PRIMARY KEY, token_count INT NOT NULL, version INT DEFAULT 0, updated_time DATETIME ) ENGINE=InnoDB;

务必确保id是主键，否则每次更新都会导致全表扫描加锁，性能呈指数级下降。

合理设置事务隔离级别

默认的REPEATABLE READ虽然安全，但在高并发更新时容易产生间隙锁（Gap Lock），增加死锁概率。

对于纯点查更新场景，可考虑调整为READ COMMITTED：

spring: datasource: url: jdbc:mysql://localhost:3306/db?characterEncoding=utf8&useSSL=false&serverTimezone=GMT%2B8&transactionIsolation=2

注：transactionIsolation=2对应Connection.TRANSACTION_READ_COMMITTED

此举可显著减少锁范围，提升并发吞吐能力。

连接池配置要合理

推荐使用 HikariCP，并根据实际负载调整参数：

hikari: maximum-pool-size: 30 minimum-idle: 10 connection-timeout: 3000 max-lifetime: 1800000 idle-timeout: 600000

过小的连接池会在高峰时造成获取连接阻塞；过大则浪费资源且可能压垮数据库。

更进一步：Lua 脚本实现复合判断

有时候，Token 扣减不仅仅是“减一”这么简单，还涉及多种前置条件，例如：
- 用户今日是否已达上限？
- 是否满足特定活动规则？

这时可以直接在 Redis 中执行 Lua 脚本，实现原子化的多条件判断与操作：

-- KEYS[1]: token key, ARGV[1]: user limit key, ARGV[2]: max count local token = redis.call('GET', KEYS[1]) if tonumber(token) <= 0 then return -1 end local userCount = redis.call('GET', ARGV[1]) or 0 if tonumber(userCount) >= tonumber(ARGV[2]) then return -2 end redis.call('DECR', KEYS[1]) redis.call('INCR', ARGV[1]) return 0

Java 中调用：

DefaultRedisScript<Long> script = new DefaultRedisScript<>(luaScript, Long.class); redisTemplate.execute(script, Arrays.asList("token:1001"), "user:123:limit", "5");

Lua 脚本在 Redis 中是原子执行的，完美解决了“检查再操作”带来的竞态问题。

如何应对缓存穿透、击穿与雪崩？

当我们将核心逻辑依赖于缓存时，也必须防范常见的缓存异常问题。

示例：防止缓存击穿的模板方法

public String getTokenWithMutex(Long tokenId) { String key = "token:" + tokenId; String value = redisTemplate.opsForValue().get(key); if (value != null) { return value; } String lockKey = key + ":lock"; Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofSeconds(3)); if (Boolean.TRUE.equals(locked)) { try { // 重新从 DB 加载 Token dbToken = tokenMapper.selectById(tokenId); if (dbToken != null) { redisTemplate.opsForValue().set(key, String.valueOf(dbToken.getTokenCount()), Duration.ofMinutes(10 + Math.random() * 10)); // 随机过期 } return String.valueOf(dbToken.getTokenCount()); } finally { redisTemplate.delete(lockKey); } } else { // 其他线程等待短暂时间后重试 Thread.sleep(50); return getTokenWithMutex(tokenId); } }

架构演进：走向分布式协同体系

最终的理想架构应当是一个多层协作的系统：

graph TD A[客户端] --> B[API网关] B --> C[微服务集群] C --> D[Redis Cluster] D --> E[(MySQL 主从)] D --> F[Kafka] F --> G[异步消费服务] G --> E G --> H[监控告警平台] style D fill:#f9f,stroke:#333 style E fill:#bbf,stroke:#333,color:#fff

在这个体系中：
-Redis Cluster承担高并发读写；
-MySQL提供最终数据落地；
-Kafka实现削峰填谷与解耦；
-异步服务负责数据核对、审计日志、补偿任务等；
-监控平台实时观察缓存命中率、QPS、延迟等指标。

这样的设计不仅抗得住瞬时洪峰，还能在故障时优雅降级——例如当 Redis 不可用时，临时启用数据库直连模式并配合限流策略，保障核心功能可用。

写在最后：技术选型的本质是权衡

MyBatisPlus 本身并没有错，它的价值在于提升开发效率。但在高并发场景下，我们必须清醒认识到：ORM 只是工具，真正的性能优化来自于架构设计。

单纯依靠数据库 + 乐观锁的方案，在百万级请求面前注定不堪一击。唯有将缓存前置、异步化、原子操作、索引优化、连接池调优等一系列手段有机结合，才能构建出稳定可靠的 Token 管理系统。

这套“Redis 缓存先行 + 数据库最终一致 + 异步回写 + 多级防护”的模式，已在多个大型项目中验证有效，无论是秒杀、抽奖还是接口限流，都能将响应时间稳定控制在毫秒级，系统吞吐量提升数十倍以上。

它不一定是最炫酷的技术方案，但一定是最经得起生产考验的选择。