高并发点赞系统设计：异步化与最终一致性实践

1. 百万级点赞系统设计概述

在当今互联网应用中，点赞功能看似简单，但当面对百万级QPS（每秒查询率）时，其背后的技术挑战不容小觑。我曾主导设计过多个千万级日活应用的互动系统，其中点赞功能的设计往往成为系统瓶颈的"重灾区"。一个优秀的点赞系统需要在用户即时反馈、数据一致性、系统可用性和资源利用率之间找到平衡点。

核心设计理念可以归纳为：用户要的是操作成功感，而非实时精确计数。这一认知从根本上改变了我们设计高并发系统的思路。在实际应用中，用户点击点赞按钮后，最关心的是立即看到"已赞"状态变化，而对于点赞总数的更新，秒级延迟是完全可接受的。这种认知解放了我们的设计约束，允许采用更高效的异步处理方案。

2. 需求分析与架构设计

2.1 核心需求拆解

从用户角度看，点赞功能包含两个层次的需求：

1. 强需求：用户操作后必须立即看到状态反馈（已赞/取消）
2. 弱需求：点赞总数的更新可以接受秒级延迟

这种差异化的需求强度为我们设计系统提供了重要依据。基于此，我们可以将系统设计原则确定为：

• 写操作异步化：确保操作成功即可，不阻塞用户
• 读操作缓存化：通过缓存扛住高并发查询
• 计数更新最终一致：通过批量合并减少数据库写入压力

2.2 整体架构设计

系统采用分层解耦架构，各层职责明确：

code复制客户端层 → 接入网关 → 服务层 → 消息队列 → 消费层 → 存储层

这种分层设计的关键优势在于：

1. 每层可以独立扩展
2. 故障可以被隔离在单一层次
3. 各层可以采用最适合的技术方案

3. 关键技术实现细节

3.1 点赞接口设计

点赞接口的核心挑战在于处理高并发写入同时保证数据正确性。我们采用"异步化+幂等"的设计方案：

java复制@PostMapping("/like")
public Result<Void> like(@RequestBody LikeRequest request) {
    // 幂等校验
    String uniqueKey = userId + ":" + videoId;
    if (!idempotentService.tryLock(uniqueKey, 10)) {
        return Result.fail("操作过于频繁");
    }
    
    // 检查当前状态
    Boolean hasLiked = redisTemplate.opsForSet().isMember(likeKey, videoId);
    int delta = hasLiked ? -1 : 1;
    
    // 异步发送到Kafka
    kafkaTemplate.send("like-topic", videoId, event)
        .whenComplete((result, ex) -> {
            if (ex != null) {
                // 降级处理
            }
        });
    
    // 乐观更新Redis
    if (delta > 0) {
        redisTemplate.opsForSet().add(likeKey, videoId);
    } else {
        redisTemplate.opsForSet().remove(likeKey, videoId);
    }
    redisTemplate.opsForHash().increment("video:like:count", videoId, delta);
    
    return Result.ok();
}

这段代码体现了几个关键设计点：

1. 幂等控制防止重复操作
2. 异步消息发送不阻塞主流程
3. 乐观更新Redis提供即时反馈
4. 完善的异常处理机制

3.2 查询接口设计

查询接口面临的主要挑战是高并发读取和缓存一致性问题：

java复制@GetMapping("/like-count/{videoId}")
public Result<Long> getLikeCount(@PathVariable String videoId) {
    // 优先读取Redis
    String countStr = redisTemplate.opsForHash()
        .get("video:like:count", videoId);
    
    if (countStr != null) {
        return Result.ok(Long.parseLong(countStr));
    }
    
    // 缓存穿透保护
    if (bloomFilter.notContains(videoId)) {
        return Result.ok(0L);
    }
    
    // 异步回源
    asyncLoadToCache(videoId);
    return Result.ok(0L);
}

查询接口的关键优化点包括：

1. 99.9%的请求由Redis处理
2. 布隆过滤器防止缓存穿透
3. 异步回源不阻塞用户请求

3.3 消息消费者设计

消费者负责将异步消息最终持久化到数据库，采用批量合并策略显著降低数据库压力：

java复制@KafkaListener(topics = "like-topic", batch = "true", 
               properties = {"max.poll.records=1000", "fetch.max.wait.ms=1000"})
public void consume(List<ConsumerRecord<String, LikeEvent>> records) {
    // 按videoId合并操作
    Map<String, Long> videoDeltaMap = records.stream()
        .collect(Collectors.groupingBy(
            r -> r.value().getVideoId(),
            Collectors.summingLong(r -> r.value().getDelta())
        ));
    
    // 批量更新Redis
    redisTemplate.executePipelined((RedisCallback<Object>) connection -> {
        videoDeltaMap.forEach((videoId, delta) -> {
            connection.hashCommands().hIncrBy(
                "video:like:count".getBytes(), 
                videoId.getBytes(), 
                delta
            );
        });
        return null;
    });
    
    // 批量写入MySQL
    List<VideoLikeCount> entities = videoDeltaMap.entrySet().stream()
        .map(e -> new VideoLikeCount(e.getKey(), e.getValue()))
        .collect(Collectors.toList());
    
    repository.batchUpsert(entities);
}

消费者设计的核心优化：

1. 按视频ID合并操作，减少写次数
2. Redis管道批量操作降低网络开销
3. 数据库批量upsert提高写入效率

4. 关键设计决策与优化

4.1 数据一致性保障

在分布式系统中，我们采用最终一致性模型，通过以下机制保证数据正确性：

1. Kafka分区策略：按videoId分区，保证同一视频的点赞操作顺序处理
2. Redis数据结构：
   • 使用Set存储用户点赞关系，空间效率高且判断复杂度O(1)
   • 使用Hash存储视频点赞计数，支持原子操作
3. 幂等控制：基于userId:videoId的唯一键+分布式锁，防止重复操作
4. 对账机制：定期比对Redis与MySQL数据，修复不一致

4.2 性能优化措施

1. 缓存优化：

   • 多级缓存：本地缓存+Redis集群
   • 缓存预热：热点数据提前加载
   • 缓存淘汰：LRU策略+TTL过期

2. 批量处理：

   • 消息批量消费（1000条或1秒触发）
   • 数据库批量写入（减少IO次数）

3. 异步化设计：

   • 主流程异步非阻塞
   • 失败操作进入重试队列

5. 极端场景应对策略

5.1 热点视频场景

当某视频突然爆火（如明星官宣），可能产生极端流量：

解决方案：

1. 网关层本地聚合：合并短时间内的重复请求
2. 动态分区扩容：为热点视频创建专属处理通道
3. 流量排队：超出处理能力时返回"排队中"状态

5.2 Redis故障处理

当缓存集群不可用时，系统需要优雅降级：

降级方案：

1. 查询降级：显示"点赞数计算中"而非具体数字
2. 写入降级：消息持久化到Kafka，待Redis恢复后回放
3. 计数降级：直接写MySQL（限流保护）

6. 性能指标与评估

经过上述优化，系统可以达到以下性能指标：

7. 实践经验与避坑指南

在实际落地过程中，我们积累了一些宝贵经验：

1. 幂等控制要全面：不仅要防重复提交，还要防消息重复消费
2. 监控体系要完善：特别关注Redis内存使用率和Kafka积压情况
3. 压测要真实：模拟真实用户行为模式，而非均匀分布请求
4. 扩容要有预案：提前规划好各层组件的水平扩展方案

常见问题排查技巧：

1. 点赞数不更新：检查消费者lag和Redis写入日志
2. 接口超时：分析Redis和Kafka的监控指标
3. 数据库负载高：优化批量写入大小和频率

8. 总结与演进方向

百万级点赞系统的核心设计思想可以总结为"四化"：

1. 异步化：写操作不直接落库
2. 缓存化：读操作全部走缓存
3. 批量化：合并操作减少IO
4. 最终一致：接受合理延迟

未来演进方向：

1. 智能化热点预测：提前预热可能的热点内容
2. 更精细的流控：基于用户行为的动态限流
3. 多活架构：支持跨机房部署，提高容灾能力

在实际项目中，我们通过这套架构成功支撑了单日超过10亿次的点赞操作，峰值QPS达到120万，系统保持稳定运行。这证明异步化+最终一致性的设计思路在高并发场景下的有效性。