亿级日活背后的技术挑战：如何构建高并发通用计数系统？------《亿级流量系统架构设计与实战》
引言
在刷短视频或社交媒体时，你可能随手就会点个赞。看似简单的"+1"动作，在亿级用户规模的系统中，背后隐藏着巨大的技术挑战。点赞数、转发数、粉丝数......这些具有累计性质的计数数据，如果处理不当，极易成为系统的瓶颈。
今天，我们就来深度解析计数服务的存储选型与架构设计。
一、 计数数据的业务画像
计数数据广泛存在于各类互联网产品中：
- 作品维度： 点赞数、分享数、评论数、转发数、收藏数。反映作品的受欢迎程度。
- 用户维度： 关注数、粉丝数、作品数、热度。直观展示用户的活跃度与影响力。
这些数据与银行余额等"强金融属性"数据不同，它们具有以下四个显著特点：
- 读写请求量巨大： 属于典型的高并发双重压力场景。
- 非产品绝对强依赖： 极端情况下，计数的短暂延迟或缺失不会导致核心功能不可用。
- 精确性要求与数值大小成反比： 用户在意前10个点赞，但在意的是10万还是10万零1个点赞。
- 可推导性： 计数值通常可以由底层的流水记录（如点赞记录表）反向审计得出。
二、 关系型数据库（MySQL）的困境
初学者往往倾向于直接使用 SELECT COUNT(*) FROM table。但在高并发场景下，这种做法无异于给数据库埋下"定时炸弹"。
1. InnoDB 的扫描成本
在 MySQL 的 InnoDB 引擎中，为了保证事务隔离性，COUNT(*) 需要一行行读取数据并累计。当数据量达到万级甚至百万级时，一次计数查询就会产生显著的 IO 压力。
2. 写入热点问题
即使我们单独开一张"计数表"记录总数，每次点赞都需要 UPDATE counter SET count = count + 1。在超高并发下，行锁竞争（Row Lock Contention）会直接导致数据库连接池枯竭。
三、 为什么 Redis 是计数的"最优解"？
与其在关系型数据库上缝缝补补（如加缓存、异步消息），不如直接将存储层切换为以内存为核心的 Redis。
1. 天生的原子增减
Redis 提供的 INCRBY、HINCRBY 命令是原子性的，能够完美支撑并发场景下的数值准确性，且单机性能极高。
2. 灵活的持久化保障
作为计数存储层，我们必须考虑数据丢失风险。Redis 提供了成熟的方案：
- RDB（快照）： 定期全量备份，文件紧凑，适合快速恢复。
- AOF（日志）： 记录每一条写指令。
- 建议配置：
appendfsync everysec。 - 折中方案： 每秒同步一次，即使发生机房级断电，最多也只丢失 1 秒的数据，这在计数业务中是完全可接受的。
3. 数据修复方案
由于计数数据具有可推导性，我们可以建立一套"离线/异步修正"机制：
方案： 周期性（如每小时或每天）通过扫描 MySQL 的原始流水记录统计总数，并对比修正 Redis 中的计数值。
四、 架构演进：从数据耦合到独立服务
为了保证系统的高可用，我们需要将计数逻辑从业务代码中解耦，抽象为独立的通用计数服务。
核心架构要点：
- 读写分离： 业务侧直接读取 Redis 快速展示；点赞动作通过消息队列（MQ）异步写入。
- 分布式集群： 使用 Codis 或 Redis Cluster 支撑海量 Key 的存储。
- 冷热隔离： 极高热度的作品（如大V发文）可以进一步引入本地缓存（Local Cache）进行汇总后再批量写入 Redis。
结语
计数系统虽小，却是分布式系统设计的缩影。在面对高并发挑战时，"解耦" 与"选型"比盲目扩容服务器更重要。将计数从关系型数据库中解放出来，利用 Redis 的高性能和灵活性，才能构建起一个既简洁又稳健的通用计数系统。