亿级流量下的 Redis 计数系统设计：位图事实 + 事件聚合 + SDS 汇总

亿级流量下的 Redis 计数系统设计：位图事实 + 事件聚合 + SDS 汇总

灵感来源：《亿级流量系统架构设计与实战》

一、背景与挑战

在社交平台或内容社区中，点赞数、收藏数、关注数、粉丝数等计数是最基础也最高频的功能。一个热门内容可能在几秒内涌入数十万次操作，这对计数系统提出了极高的要求。

传统方案面临三大痛点：

本方案提出一套 “位图事实 + Kafka 事件聚合 + SDS 固定结构汇总” 的三层架构，以极低的内存开销和秒级最终一致性解决上述问题。

二、设计目标

• 统一支撑：内容实体的点赞、收藏等高并发计数；用户维度的关注、粉丝、发文、获赞、获收藏

• 写入幂等：同一操作重复执行不影响最终结果

• 读低延迟：单次读取 O(1)，批量读取管道化

• 秒级最终一致：写入后 1 秒内可读到最新值

• 自动纠偏：异常时具备从事实际自主重建的能力

• 低成本：内存占用低、CPU 分布均衡，避免数据库热写与 Redis 哈希膨胀

三、架构总览

三层数据分层架构，实现「写削峰、读极致、错可修」的核心能力，层层各司其职、解耦容错。

flowchart LR
A[用户动作] –> B["位图切换(Lua 原子 SETBIT)"]
B –>|仅状态变更时| C["计数事件"]
C –> D["Kafkacounter-events"]
D –> E["聚合增量桶(Redis Hash)"]
E –>|fixedDelay=1s| F["SDS 汇总(固定结构计数)"]

G[读取请求] –> H{读取策略}
H –>|常规| F
H –>|异常| I["位图 BITCOUNT 重建"]
I –> J["分布式锁"]
J –> F

三层数据层次：

┌─────────────────────────────────────┐
│ 位图事实层 (不可变事实) │ ← 幂等开关，状态唯一可信来源
│ bm:{metric}:{etype}:{eid}:{chunk} │
├─────────────────────────────────────┤
│ 聚合增量层 (过渡态) │ ← Kafka 消费攒批，秒级窗口
│ agg:{schema}:{etype}:{eid} (Hash) │
├─────────────────────────────────────┤
│ SDS 汇总层 (读优化) │ ← 定长二进制结构，O(1) 读取
│ cnt:{schema}:{etype}:{eid} │
└─────────────────────────────────────┘

四、核心设计详解

4.1 数据模型与键设计

实体计数（内容维度）

用户计数（用户维度）

ucnt:{userId} → 5 段 × 4 字节（大端 int32）
┌────────────┬───────────┬────────┬──────────────┬──────────────┐
│ followings │ followers │ posts │ likesReceived│ favsReceived │
│ (0-3) │ (4-7) │ (8-11) │ (12-15) │ (16-19) │
└────────────┴───────────┴────────┴──────────────┴──────────────┘

设计亮点：将一组计数编码为定长二进制结构存储在 Redis String 中（类似 Redis 内部的 SDS），一个用户的所有计数仅占用 20 字节，读取时按偏移量直接解出对应字段，真正做到 O(1) + 零膨胀。

4.2 写路径：幂等原子 + 异步聚合

写路径的核心思想是 “状态驱动计数”——计数的变化源于用户状态的变更，而非单纯的加减操作。从根源解决重复请求、并发写入导致的数据异常问题。

sequenceDiagram
participant Client
participant App
participant Redis
participant Kafka
participant AggConsumer
participant FlushScheduler

Client->>App: 点赞 / 取消点赞
App->>Redis: Lua TOGGLE (SETBIT + 状态判定)
Redis–>>App: 1=变更 / 0=无变化

alt 状态发生变更
App->>Kafka: 发布 CounterEvent(+1/-1)
Kafka->>AggConsumer: 消费事件
AggConsumer->>Redis: HINCRBY 聚合桶
AggConsumer->>Kafka: 手动 ACK

FlushScheduler->>Redis: 扫描聚合桶 (每1s)
FlushScheduler->>Redis: Lua 原子折叠到 SDS + 删除字段
end

关键代码：位图切换

private boolean toggle(String etype, String eid, long uid,
String metric, int idx, boolean add) {
// 固定分片定位，避免单键膨胀
long chunk = BitmapShard.chunkOf(uid); // uid / 32768
long bit = BitmapShard.bitOf(uid); // uid % 32768
String bmKey = CounterKeys.bitmapKey(metric, etype, eid, chunk);

// Lua 原子执行：仅状态变更时置 1/清 0，返回 1 表示变更
Long changed = redis.execute(toggleScript,
List.of(bmKey),
String.valueOf(bit), add ? "add" : "remove");

if (changed == 1L) {
int delta = add ? 1 : -1;
// 产出计数事件 → Kafka 异步聚合
eventProducer.publish(CounterEvent.of(etype, eid, metric, idx, uid, delta));
// 同步触发本地事件 → 缓存失效等
eventPublisher.publishEvent(CounterEvent.of(etype, eid, metric, idx, uid, delta));
}
return changed == 1L;
}

定时刷写到 SDS：

@Scheduled(fixedDelay = 1000L) // 秒级最终一致
public void flush() {
Set<String> keys = redis.keys("agg:" + CounterSchema.SCHEMA_ID + ":*");
for (String aggKey : keys) {
Map<Object, Object> entries = redis.opsForHash().entries(aggKey);
if (entries.isEmpty()) continue;

String cntKey = CounterKeys.sdsKey(etype, eid);
for (Map.Entry<Object, Object> e : entries.entrySet()) {
// Lua 原子折叠：INCRBY SDS[idx] += delta，成功后删除聚合字段
redis.execute(incrFieldScript, cntKey, e.getKey(), e.getValue());
}
}
}

4.3 读路径：常规快速 + 异常自愈

flowchart TD
A[读取请求] –> B{"SDS 是否存在且结构正确?"}
B –>|是| C["直接返回O(1) 读取对应段"]
B –>|否| D["尝试获取分布式锁(TTL 5s)"]
D –>|获取成功| E["逐分片 BITCOUNT 管道求和"]
E –> F["拼装新 SDS 并回写"]
F –> G["清理聚合桶字段释放锁"]
G –> C
D –>|获取失败| H["等待后重试 / 降级返回 0"]

常规读取：

// GET cnt:{schema}:{etype}:{eid}
// 按 Schema 偏移直接读取段值（大端 32 位）
public long getCount(String etype, String eid, int metricIdx) {
byte[] raw = redis.get(CounterKeys.sdsKey(etype, eid));
if (raw != null && raw.length == CounterSchema.TOTAL_BYTES) {
return CounterSchema.readField(raw, metricIdx); // O(1) 偏移读取
}
return rebuildAndGet(etype, eid, metricIdx); // 异常触发重建
}

批量读取（Feed 场景）：

// 管道批量 GET，缺失时补 0，避免逐条 RTT
List<Object> results = redis.executePipelined((RedisCallback<?>) conn -> {
for (String key : sdsKeys) {
conn.stringCommands().get(ByteBuffer.wrap(key.getBytes()));
}
return null;
});

4.4 用户维度计数

用户维度的关注数、粉丝数等通过 Outbox 事件处理器 异步维护，解耦核心业务与计数统计，避免主流程阻塞。

// 关注事件处理
@EventListener
public void onFollow(FollowEvent evt) {
if (evt.isCancelled()) {
// 取关：删除关注关系 + 过期集中缓存
redis.opsForSet().remove("uf:flws:" + evt.getFromUserId(),
String.valueOf(evt.getToUserId()));
redis.opsForSet().remove("uf:fans:" + evt.getToUserId(),
String.valueOf(evt.getFromUserId()));

userCounterService.incrementFollowings(evt.getFromUserId(), -1);
userCounterService.incrementFollowers(evt.getToUserId(), -1);
}
}

并通过 定期抽样校验（每 300s 对关注/粉丝做数据库对比，不一致则全量重建）保证数据质量。

五、压测性能数据

为验证亿级流量适配能力，我们基于生产环境配置（8核16G Redis、3节点Kafka集群）做并发压测，核心指标如下，直观体现方案优势：

核心结论：本方案相较于传统Hash方案，并发吞吐量提升3倍+、延迟降低75%、内存开销缩减96%，且彻底解决并发脏写问题，完全适配热点内容亿级访问场景。

六、一致性、幂等与容错

6.1 幂等保证

6.2 最终一致性

写入 → 聚合桶 → SDS 刷写 窗口：≤ 1 秒

在窗口内读取可能略滞后，这是 秒级最终一致 的有意取舍——换来了写入的高吞吐和内存的高压缩。对于社交计数场景，用户对1秒内的数据偏差无感知，完全符合业务预期。

6.3 异常自愈

• SDS 缺失/损坏：自动触发位图重建 + 分布式锁保护，杜绝并发回写

• 严重故障：可切换 CounterRebuildConsumer 做全量 Kafka 事件回放（earliest），直接从历史事件重建 SDS

• 定期对账：异步任务从业务事实表聚合校正，作为最后一道防线

6.4 并发保护

┌──────────────┐ ┌──────────────┐
│ 请求 A │ │ 请求 B │
│ SDS 缺失! │ │ SDS 缺失! │
│ SETNX lock │ │ SETNX lock │
│ 获取成功 ✓ │ │ 获取失败 ✗ │
│ BITCOUNT.. │ │ 等待/降级 │
│ 回写 SDS │ │ │
│ 清理聚合字段 │ │ │
│ DEL lock │ │ │
└──────────────┘ └──────────────┘

七、运维监控与降级预案

7.1 核心监控指标

生产环境必备监控告警，覆盖性能、异常、一致性三大维度，实现问题秒级发现：

• 性能指标：位图写入QPS、SDS读取QPS、聚合刷写耗时、批量读取RT

• 异常指标：SDS重建次数、分布式锁竞争失败次数、Kafka消息堆积量

• 一致性指标：抽样对账偏差率、聚合桶残留字段数量

• 资源指标：位图分片内存占用、Redis CPU使用率、键过期失效数

7.2 多级降级预案

针对流量峰值、Redis宕机、Kafka阻塞等极端场景，配置无损降级策略，保障服务可用性：

• 一级降级（流量峰值）：关闭实时SDS刷写，延长聚合窗口至3s，优先保障写入吞吐，读取兼容滞后数据

• 二级降级（Kafka阻塞）：切换本地内存队列临时缓存事件，流量削峰后异步补发，不丢失用户操作记录

• 三级降级（Redis异常）：临时切换数据库兜底读取，停止实时计数写入，流量低谷后批量同步修复

八、落地踩坑与解决方案

梳理生产落地过程中遇到的核心问题，补充通用解决方案，提升博客实战价值：

九、方案对比

直接写 Hash 纯位图+BITCOUNT 数据库计数列 本方案
────────── ────────────── ─────────── ──────
写入性能 ★★★ ★★★★ ★★ ★★★★
读取性能 ★★★ ★★ ★★★ ★★★★
幂等性 ★★ ★★★★★ ★★★ ★★★★★
内存占用 ★★ ★★★ ★★★★ ★★★★★
批量友好 ★★ ★★ ★★★ ★★★★★
事实回溯 ★ ★★★★★ ★★★★ ★★★★★
自动纠偏 ★ ★★ ★★★ ★★★★★
实现复杂度 ★★★★★ ★★★ ★★★★ ★★★

十、总结与可扩展方向

10.1 核心设计理念

10.2 可扩展方向

• 段大小平滑升级：当前 4 字节 int32，可在 CounterSchema 中引入版本号，新版本使用 8 字节 int64，读写时按版本选择解析方式

• 冷热分离：热度低的实体计数可下沉到 SSD 存储（如使用 Redis on Flash），节省内存成本

• 多级缓存：本地 Caffeine 缓存 + Redis SDS + 位图，进一步降低读取延迟，应对超高频读场景

• 多维计数：Schema 中增加更多字段（如分享数、评论数），仅增加少量字节即可快速扩展业务维度

• 全局限流适配：结合网关限流，针对异常刷量请求拦截，保护计数系统稳定性

十一适用与不适用场景

11.1 最佳适用场景

• 社交/内容平台高频计数：点赞、收藏、关注、粉丝、发文数等

• 热点流量场景：爆款短视频、热门文章、热搜话题的超高并发计数

• 需要数据可回溯、可纠偏的统计场景

• 对内存成本敏感、追求极致读写性能的业务

11.2 不适用场景

• 强实时绝对一致场景：如交易金额、库存计数（需毫秒级强一致，本方案为秒级最终一致）

• 低频小众数据：极低访问量的实体计数，架构冗余度高于收益

• 频繁清零重置场景：需要频繁清空计数的业务，位图重建成本高于普通计数方案