高并发计数器设计：从数据库行锁到Redis原子操作的实战演进

最近在开发一个基于Spring Boot的在线音乐平台时，遇到了一个非常典型的分布式环境下的数据一致性问题。具体场景是：当用户A在收藏一首歌的同时，用户B可能正在取消对同一首歌的收藏，后台需要实时、准确地更新这首歌的“收藏数”。在高并发请求下，简单的数据库更新操作极易导致最终计数不准，也就是我们常说的“超卖”或“数据覆盖”问题。这不仅仅是收藏功能，点赞数、库存扣减、积分增减等业务场景都面临同样的挑战。

本文将围绕如何在高并发场景下，实现类似“收藏数”这类计数器的强一致性与高性能更新，提供一个从理论到实战的完整解决方案。我们会从最基础的数据库行锁开始，逐步深入到更优雅的分布式锁和Redis原子操作，并最终给出一个基于Redis Lua脚本的生产级方案。无论你是正在处理类似业务难题的开发者，还是希望深入理解并发控制的同学，都能从本文中获得可直接复用的代码和清晰的解决思路。

1. 背景与核心概念：为什么简单的“UPDATE”会出问题？

在深入解决方案之前，我们必须先理解问题产生的根源。很多初级开发者可能会写出如下SQL来实现收藏数的增减：

-- 用户收藏歌曲 UPDATE song SET favorite_count = favorite_count + 1 WHERE id = 123; -- 用户取消收藏歌曲 UPDATE song SET favorite_count = favorite_count - 1 WHERE id = 123;

在单线程或极低并发下，这段代码工作良好。但在高并发场景下，问题就暴露出来了。

核心问题：数据库的UPDATE操作本身是原子的，但一个完整的“业务操作”通常包含多个步骤：查询当前状态、业务逻辑判断、执行更新。在高并发下，多个请求可能几乎同时读取到同一个favorite_count值（例如100），然后各自在其基础上进行+1或-1计算，并写回数据库。最终，后写入的操作会覆盖前一个操作的结果，导致数据丢失。

例如：

1. 请求A（收藏）和请求B（取消收藏）同时读取到favorite_count = 100。
2. 请求A计算：100 + 1 = 101。
3. 请求B计算：100 - 1 = 99。
4. 请求B先将99写入数据库。
5. 请求A再将101写入数据库，覆盖了99。
6. 最终结果favorite_count = 101，但正确结果应为100。一次取消收藏的操作被丢失了。

这就是典型的并发写冲突。要解决它，我们需要确保对同一个计数器数据的“读-改-写”这一系列操作成为一个不可分割的原子操作，即在操作完成前，其他请求必须等待。

2. 环境准备与版本说明

本文将使用一个简化的Spring Boot项目来演示所有方案。你可以跟随步骤搭建环境，也可以直接关注核心代码逻辑。

基础环境：

• 操作系统: macOS/Linux/Windows (WSL2推荐)
• JDK: 11 或以上 (本文使用 Amazon Corretto 11)
• 构建工具: Maven 3.6+
• IDE: IntelliJ IDEA 或 VS Code

主要依赖 (Spring Boot 2.7.x)：核心依赖是Spring Boot Web、Spring Data JPA (连接MySQL)、以及Spring Data Redis。

<!-- pom.xml 关键依赖 --> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.redisson</groupId> <artifactId>redisson-spring-boot-starter</artifactId> <version>3.17.7</version> <!-- 用于分布式锁方案 --> </dependency> </dependencies>

数据库与中间件：

• MySQL: 8.0+，用于存储歌曲信息及计数器。
• Redis: 6.2+，用于缓存和原子操作。

项目结构预览：

src/main/java/com/example/musiccounter/ ├── entity/ │ └── Song.java # 歌曲实体类 ├── repository/ │ └── SongRepository.java # JPA仓库 ├── service/ │ └── FavoriteService.java # 收藏业务服务 └── controller/ └── FavoriteController.java # 收藏接口

3. 解决方案一：数据库悲观锁（行锁）

这是最直接、利用数据库自身能力的方案。通过SELECT ... FOR UPDATE语句，在事务中锁定目标数据行，直到当前事务提交或回滚，其他试图读取该行的事务会被阻塞。

3.1 原理与实现

我们在Service层的方法上使用@Transactional注解，并在查询时使用@Lock(LockModeType.PESSIMISTIC_WRITE)。

// 文件路径：src/main/java/com/example/musiccounter/service/FavoriteService.java @Service @RequiredArgsConstructor public class FavoriteService { private final SongRepository songRepository; /** * 使用数据库行锁实现收藏 * @param songId 歌曲ID */ @Transactional(rollbackFor = Exception.class) public void favoriteWithPessimisticLock(Long songId) { // 1. 使用悲观写锁查询歌曲，此行已被锁定 Song song = songRepository.findSongByIdForUpdate(songId); // 2. 业务逻辑判断（例如是否已收藏，此处简化） // 3. 更新计数器 song.setFavoriteCount(song.getFavoriteCount() + 1); // 4. 保存，事务提交后锁释放 songRepository.save(song); } /** * 使用数据库行锁实现取消收藏 * @param songId 歌曲ID */ @Transactional(rollbackFor = Exception.class) public void unfavoriteWithPessimisticLock(Long songId) { Song song = songRepository.findSongByIdForUpdate(songId); if (song.getFavoriteCount() > 0) { song.setFavoriteCount(song.getFavoriteCount() - 1); songRepository.save(song); } } }

对应的Repository需要定义特定的查询方法：

// 文件路径：src/main/java/com/example/musiccounter/repository/SongRepository.java @Repository public interface SongRepository extends JpaRepository<Song, Long> { /** * 使用悲观写锁查询歌曲 * @param id 歌曲ID * @return 歌曲实体 */ @Lock(LockModeType.PESSIMISTIC_WRITE) @Query("SELECT s FROM Song s WHERE s.id = :id") Optional<Song> findSongByIdForUpdate(@Param("id") Long id); }

3.2 优缺点分析

优点：

• 强一致性：绝对保证数据正确，由数据库本身保证。
• 实现简单：利用JPA注解即可，无需引入额外组件。

缺点：

• 性能瓶颈：锁是数据库级别的，并发量高时大量线程会阻塞在数据库，导致连接池耗尽、响应时间飙升。
• 死锁风险：如果多个业务需要按不同顺序锁定多行数据，可能引发死锁。
• 不适合分布式：如果应用是多实例部署，数据库锁依然有效，但性能压力会集中在数据库。

适用场景：并发量不高、对数据一致性要求极其严格、且业务逻辑简单的场景。

4. 解决方案二：基于Redis的分布式锁

当应用是分布式部署时，我们需要一个所有实例都能访问的锁服务，Redis因其高性能和原子性命令成为首选。这里我们使用成熟的Redisson客户端。

4.1 原理与实现

Redisson的RLock实现了Java的Lock接口，并提供了看门狗（Watchdog）机制自动续期，防止业务未执行完锁过期，同时保证了锁的可重入性。

首先，配置Redisson：

# application.yml spring: redis: host: localhost port: 6379 database: 0 redisson: config: | singleServerConfig: address: "redis://${spring.redis.host}:${spring.redis.port}" database: ${spring.redis.database}

然后实现服务：

// 在FavoriteService中注入RedissonClient并新增方法 @Service @RequiredArgsConstructor public class FavoriteService { // ... 其他依赖 private final RedissonClient redissonClient; /** * 使用Redisson分布式锁实现收藏 * @param songId 歌曲ID */ public void favoriteWithDistributedLock(Long songId) { // 1. 为每个歌曲ID创建独立的锁对象，锁粒度更细，性能更好 String lockKey = "LOCK:SONG_FAVORITE:" + songId; RLock lock = redissonClient.getLock(lockKey); // 2. 尝试加锁，最多等待3秒，锁持有时间10秒（看门狗会自动续期） try { boolean isLocked = lock.tryLock(3, 10, TimeUnit.SECONDS); if (!isLocked) { throw new RuntimeException("获取锁失败，请稍后重试"); } // 3. 执行业务逻辑 Song song = songRepository.findById(songId).orElseThrow(); song.setFavoriteCount(song.getFavoriteCount() + 1); songRepository.save(song); // 4. 业务完成，锁会在finally块中释放 } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException("锁等待被中断", e); } finally { // 5. 释放锁（只释放自己加的锁） if (lock.isHeldByCurrentThread()) { lock.unlock(); } } } }

4.2 优缺点分析

优点：

• 分布式友好：完美支持多实例部署。
• 高性能：相比数据库行锁，Redis锁的获取和释放速度极快。
• 功能完善：Redisson提供了可重入锁、公平锁、联锁、红锁等多种锁类型，以及自动续期机制。

缺点：

• 系统复杂度增加：需要引入和维护Redis集群及Redisson客户端。
• 非绝对强一致：Redis主从异步复制下，主节点崩溃可能导致锁信息丢失（可用RedLock算法缓解，但更复杂）。
• 锁粒度管理：锁的key设计需要仔细，粒度过粗影响并发，过细增加管理成本。

适用场景：分布式系统，对性能要求高，可以接受极低概率锁失效的场景。

5. 解决方案三：Redis原子操作（INCR/DECR）

如果我们把计数器本身从数据库迁移到Redis，就可以利用Redis单线程和原子命令的特性，从根本上避免并发问题。这是性能最高的方案。

5.1 原理与实现

Redis的INCR和DECR命令是原子性的，意味着执行增减时不会被其他命令打断。我们将歌曲的收藏数存储在Redis的String或Hash结构中。

方案A：使用String类型

@Service @RequiredArgsConstructor public class FavoriteService { // ... 其他依赖 private final StringRedisTemplate stringRedisTemplate; private static final String FAV_COUNT_KEY_PREFIX = "song:fav:count:"; /** * 使用Redis原子INCR实现收藏 * @param songId 歌曲ID */ public void favoriteWithRedisAtomic(Long songId) { String key = FAV_COUNT_KEY_PREFIX + songId; // INCR命令：如果key不存在，会先初始化为0再+1 Long newCount = stringRedisTemplate.opsForValue().increment(key); // 这里可以记录日志或触发其他事件，newCount就是最新的收藏数 log.info("歌曲{}收藏数更新为：{}", songId, newCount); // 可选：异步将数据写回数据库，保证最终一致性 // asyncUpdateDatabase(songId, newCount); } /** * 使用Redis原子DECR实现取消收藏 * @param songId 歌曲ID */ public void unfavoriteWithRedisAtomic(Long songId) { String key = FAV_COUNT_KEY_PREFIX + songId; // DECR命令：如果key不存在，会先初始化为0再-1，得到-1。需要业务判断。 Long newCount = stringRedisTemplate.opsForValue().decrement(key); if (newCount != null && newCount < 0) { // 如果减到负数，说明数据有问题，可以回滚或告警 stringRedisTemplate.opsForValue().increment(key); // 回滚 throw new RuntimeException("收藏数不能为负"); } log.info("歌曲{}收藏数更新为：{}", songId, newCount); } /** * 获取收藏数（优先从Redis读） * @param songId 歌曲ID * @return 收藏数 */ public Long getFavoriteCount(Long songId) { String key = FAV_COUNT_KEY_PREFIX + songId; String countStr = stringRedisTemplate.opsForValue().get(key); if (countStr != null) { return Long.parseLong(countStr); } else { // Redis没有，从数据库加载并预热到Redis Song song = songRepository.findById(songId).orElseThrow(); stringRedisTemplate.opsForValue().set(key, String.valueOf(song.getFavoriteCount())); return song.getFavoriteCount(); } } }

方案B：使用Hash类型（管理多个计数器）如果一首歌有多个需要原子更新的计数（如收藏、点赞、播放），使用Hash更高效。

public void favoriteWithRedisHash(Long songId) { String key = "song:counters:" + songId; // HINCRBY 同样具有原子性 Long newCount = stringRedisTemplate.opsForHash().increment(key, "favorite", 1); log.info("歌曲{}收藏数更新为：{}", songId, newCount); }

5.2 数据同步与最终一致性

纯Redis方案面临一个核心问题：数据在Redis里，如何与源数据库同步？我们通常采用异步写回的策略保证最终一致性。

1. 写操作路径：用户操作 → Redis原子更新 → 发送MQ消息或记录Binlog → 异步消费者更新数据库。
2. 读操作路径：优先读Redis → Redis无数据则读数据库并回填Redis。
3. 容灾考虑：Redis重启或崩溃，可以从数据库重新加载计数。为防止重启后数据为0，可以考虑定期将Redis数据持久化快照，或使用AOF。

这是一个简单的异步更新示例（使用Spring Event或MQ）：

@Component @RequiredArgsConstructor public class CounterUpdateListener { private final SongRepository songRepository; @Async // 异步执行 @EventListener public void handleCounterUpdateEvent(CounterUpdateEvent event) { // 这里可以批量更新，减少数据库压力 songRepository.updateFavoriteCount(event.getSongId(), event.getNewCount()); } } // 在favoriteWithRedisAtomic方法中发布事件 // applicationEventPublisher.publishEvent(new CounterUpdateEvent(songId, newCount));

5.3 优缺点分析

优点：

• 性能极致：Redis内存操作，单线程原子命令，吞吐量极高。
• 实现简洁：无需显式加锁，代码更清晰。
• 扩展性好：易于实现计数器的分片和集群化。

缺点：

• 数据一致性模型变化：从事务强一致变为最终一致，业务需要接受短暂的数据延迟。
• 系统架构复杂化：需要设计可靠的数据同步机制，引入了消息队列或定时任务。
• 缓存穿透/雪崩：需要处理Redis缓存失效的问题。

适用场景：高并发、对实时一致性要求不是绝对严格（允许秒级延迟）、计数查询频繁的场景。如微博点赞、视频播放量、热点文章阅读数等。

6. 终极方案：Redis Lua脚本保证原子性与业务逻辑

对于更复杂的业务逻辑（例如：每人每天只能点赞一次，点赞同时增加积分），单纯的INCR不够用，而“先查后改”在分布式锁下也有风险。此时，Redis Lua脚本是终极武器。Lua脚本在Redis中执行时是原子的，相当于把整个业务逻辑打包成一个原子命令。

6.1 实战：使用Lua脚本实现“每日首次收藏奖励积分”

假设业务规则：用户收藏歌曲，歌曲收藏数+1。如果用户是当天第一次收藏该歌曲，则额外奖励10积分。

@Service public class FavoriteService { private final StringRedisTemplate stringRedisTemplate; // Lua脚本：收藏并检查每日首次 private static final String FAVORITE_LUA_SCRIPT = "local songKey = KEYS[1] -- 歌曲收藏数key，例如 'song:fav:count:123' \n" + "local userDailyKey = KEYS[2] -- 用户每日记录key，例如 'user:daily:fav:456:20240520' \n" + "local userId = ARGV[1] \n" + " \n" + "-- 1. 增加歌曲收藏数 \n" + "local newFavCount = redis.call('INCR', songKey) \n" + " \n" + "-- 2. 检查用户今天是否已收藏过这首歌 \n" + "local hasFavToday = redis.call('SETNX', userDailyKey, 1) \n" + " \n" + "-- 3. 如果是首次收藏（SETNX返回1），设置key过期时间为当天剩余秒数，并返回奖励标记 \n" + "local rewardPoints = 0 \n" + "if hasFavToday == 1 then \n" + " redis.call('EXPIREAT', userDailyKey, tonumber(ARGV[2])) -- ARGV[2]是当天23:59:59的时间戳 \n" + " rewardPoints = 10 \n" + "end \n" + " \n" + "-- 4. 返回结果：新的收藏数、是否奖励积分 \n" + "return {newFavCount, rewardPoints}"; private final DefaultRedisScript<List> favoriteScript; public FavoriteService(StringRedisTemplate stringRedisTemplate) { this.stringRedisTemplate = stringRedisTemplate; this.favoriteScript = new DefaultRedisScript<>(); this.favoriteScript.setScriptText(FAVORITE_LUA_SCRIPT); this.favoriteScript.setResultType(List.class); } public Map<String, Object> favoriteWithLuaScript(Long songId, Long userId) { String songKey = "song:fav:count:" + songId; // 用户每日记录key，包含用户ID和当天日期 String today = LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE); String userDailyKey = "user:daily:fav:" + userId + ":" + today; // 计算当天结束的时间戳 long endOfDay = LocalDateTime.now().with(LocalTime.MAX).toEpochSecond(ZoneOffset.UTC); // 执行Lua脚本 List<Long> result = stringRedisTemplate.execute( favoriteScript, Arrays.asList(songKey, userDailyKey), userId.toString(), String.valueOf(endOfDay) ); Long newFavCount = result.get(0); Long rewardPoints = result.get(1); Map<String, Object> response = new HashMap<>(); response.put("newFavoriteCount", newFavCount); response.put("rewardPoints", rewardPoints); response.put("message", rewardPoints > 0 ? "收藏成功，获得" + rewardPoints + "积分！" : "收藏成功！"); // 异步处理积分奖励到数据库 if (rewardPoints > 0) { asyncAddUserPoints(userId, rewardPoints); } // 异步同步收藏数到数据库 asyncUpdateSongFavoriteCount(songId, newFavCount); return response; } }

6.2 方案优势

• 绝对的原子性：整个“判断-更新-奖励”流程在Redis服务器端一次性完成，无并发干扰。
• 高性能：一次网络通信，减少多次命令的往返延迟（RTT）。
• 减少锁竞争：完全避免了分布式锁的争用。
• 业务逻辑封装：复杂的业务规则可以封装在脚本中，客户端调用简单。

7. 方案对比与选型指南

选型建议：

1. 追求极致性能与高并发：首选Redis原子操作 (INCR/DECR)+ 异步同步方案。这是互联网公司处理点赞、收藏、阅读数的标准做法。
2. 业务逻辑复杂且需原子性：选择Redis Lua脚本。它将复杂逻辑原子化，性能优于分布式锁。
3. 已有分布式锁框架且业务复杂：使用Redis分布式锁 (Redisson)。它对代码侵入小，能处理跨多个资源或服务的复杂事务场景。
4. 传统项目、并发量低、强一致性优先：使用数据库悲观锁。简单直接，但必须密切监控数据库压力。

8. 生产环境注意事项与最佳实践

无论选择哪种方案，以下几点对于生产系统都至关重要：

1. 监控与告警：

   • 数据库行锁：监控数据库活跃连接数、锁等待时间。设置慢查询告警。
   • Redis分布式锁：监控Redis连接数、内存使用、锁等待超时次数。
   • Redis计数器：监控内存使用率、Key数量增长趋势，防止无限增长。

2. Key设计规范：

   • 使用清晰的命名空间，如业务:类型:标识(song:fav:count:123)。
   • 为计数器Key设置合理的TTL，即使有异步同步，也避免无用数据常驻内存。可以设置一个较长的TTL（如7天），并由同步程序刷新TTL。

3. 降级与容灾：

   • Redis不可用：设计降级策略，例如快速失败返回默认值，或临时切换为基于数据库的悲观锁方案（需有流量开关控制）。
   • 数据同步失败：消息队列需保证可靠性（持久化、重试、死信队列）。定期运行补偿任务，核对Redis与数据库的数据差异。

4. 防止恶意刷：

   • 在接口层增加频率限制（Rate Limiting），例如使用Redis的INCR和EXPIRE实现滑动窗口限流。
   • 对关键操作进行用户行为验证（如验证码、token）。

5. 代码健壮性：

   • 分布式锁一定要在finally块中释放，并判断当前线程是否持有锁。
   • Lua脚本应尽量简洁，避免长时间运行的脚本阻塞Redis。
   • 所有异步操作（如发MQ、更新DB）都要有完善的错误处理和日志记录。

9. 常见问题排查清单

从数据库行锁的强一致保障，到Redis原子操作的高性能巅峰，再到Lua脚本对复杂业务原子性的完美封装，解决高并发计数问题的技术路径是清晰的。对于大多数互联网应用，“Redis原子操作 + 异步最终一致”是平衡性能、复杂度与一致性的最佳选择。在引入任何方案时，务必结合自身业务的并发量、数据一致性要求和技术栈现状来做决策，并配以完善的监控、告警和降级措施。