交互数据缓存设计：按流量分级的三套方案

使用场景#

写入 QPS < 500，无热点集中。数据库行锁、连接池都够用，引入缓存层是负收益。

使用方案#

全部逻辑落在 MySQL，两步一个事务：记录表 upsert + 计数表 UPDATE。无 Redis、无 MQ、无定时任务，部署成本一个数据库。

Key 设计#

无缓存 Key。表结构即全部存储：

1
CREATE TABLE interaction_record (
2
    id               BIGINT PRIMARY KEY AUTO_INCREMENT,
3
    user_id          BIGINT NOT NULL,
4
    target_type      INT NOT NULL,
5
    target_id        BIGINT NOT NULL,
6
    interaction_type INT NOT NULL,
7
    status           TINYINT NOT NULL DEFAULT 1 COMMENT '1=有效, 0=取消',
8
    create_time      DATETIME NOT NULL,
9
    update_time      DATETIME NOT NULL,
10
    UNIQUE KEY uk_user_target (user_id, target_type, target_id, interaction_type)
11
);
12

13
CREATE TABLE interaction_count (
14
    target_type      INT NOT NULL,
15
    target_id        BIGINT NOT NULL,
16
    interaction_type INT NOT NULL,
17
    count            BIGINT NOT NULL DEFAULT 0,
18
    update_time      DATETIME NOT NULL,
19
    PRIMARY KEY (target_type, target_id, interaction_type)
20
);

计数表独立于记录表，展示页读计数表，不执行 COUNT(*)。

写入流程#

1
-- 一个事务内：
2
-- 1. 记录 upsert（唯一索引兜底防重复点赞）
3
INSERT INTO interaction_record (user_id, target_type, target_id, interaction_type, status, create_time, update_time)
4
VALUES (42, 1, 10086, 1, 1, NOW(), NOW())
5
ON DUPLICATE KEY UPDATE status = 1, update_time = NOW();
6

7
-- 2. 计数（仅当 status 确实翻转时执行，由应用层判断 affected rows）
8
UPDATE interaction_count SET count = count + 1, update_time = NOW()
9
WHERE target_type = 1 AND target_id = 10086 AND interaction_type = 1;

强一致，无对账需求。瓶颈出现（行锁排队、P99 劣化）时升级方案二。

使用场景#

写入 QPS 500 ~ 5000，数据库开始吃紧，但没有 MQ 基础设施或不想引入。可接受分钟级落库延迟。

使用方案#

Redis 扛实时读写，定时任务批量扫描变更落库。依赖：Redis + 调度器（XXL-Job / crontab），无 MQ。

Key 设计#

此量级单 Key 内存可控（单内容参与 < 百万级），不需要分桶。cnt 用 Hash 一个 Key 装多维度计数（赞 / 藏 / 关注），比 String 少 3/4 的 Key 数。

写入流程#

1
点赞:
2
    HSET like:1:10086 42 1        # 返回 1 = 新 field，继续；0 = 已存在，查 value 分支
3
    HINCRBY cnt:1:10086 like 1
4
    SADD dirty:1 10086            # 标记待落库
5

6
取消:
7
    HSET like:1:10086 42 0
8
    HINCRBY cnt:1:10086 like -1
9
    SADD dirty:1 10086

定时任务（每 5 分钟）：

1. SMEMBERS dirty:1 取变更内容列表（避免 KEYS 全库扫描）；
2. 对每个 targetId：HSCAN like:1:10086 取全部 field 终态，批量 upsert 记录表；
3. HGET cnt:1:10086 与记录表核对后更新计数表；
4. SREM dirty:1 10086 清除脏标记。

状态 Hash 不删除（保留终态供下次增量扫描），脏标记是唯一需要清理的 Key。

一致性#

落库延迟 = 扫描周期（分钟级）。Redis 与 DB 间的偏差由每日对账收敛：抽样比对 cnt 与计数表，不一致时以 Redis 状态桶 HSCAN 重算为准（此方案 DB 是定期镜像，Redis 是活跃数据源）。

使用场景#

写入 QPS 500 ~ 5000，已有 MQ 基础设施，要求秒级落库延迟。单内容参与量可控（未达大 Key 阈值），无热点集中——不需要分桶，但不接受方案二的分钟级延迟。

使用方案#

Redis 单 Key 扛读写，MQ 异步批量落库。依赖：Redis + MQ（RocketMQ / Kafka）+ 消费集群。与方案二共用单 Key 状态设计，落库路径从定时扫描换成事件驱动：变更即发消息，消费端攒批写库，无需等扫描周期。

Key 设计#

与方案二相比去掉脏标记：MQ 消息本身携带变更信息，替代扫描发现变更。

写入流程#

1
点赞:
2
    HSET like:1:10086 42 1        # 返回 1 = 新 field，继续；0 = 已存在，查 value 分支
3
    HINCRBY cnt:1:10086 like 1
4
    发 MQ 消息 {userId: 42, targetId: 10086, type: like, delta: +1}
5

6
取消:
7
    HSET like:1:10086 42 0
8
    HINCRBY cnt:1:10086 like -1
9
    发 MQ 消息 {userId: 42, targetId: 10086, type: like, delta: -1}

落库：MQ 批量聚合消费，消费端攒 500 条或 1s 触发一次批量提交：

• 记录表：内存按 (userId, targetId) 去重（同用户秒内赞了又取消，取时间靠后一条）后批量 upsert；
• 计数表：按 targetId 聚合净增量（+1/-1 相消），每内容一次 UPDATE count = count + delta。

交互 QPS 5000 时 DB 写入降至 10 QPS 以内。消费失败重试 3 次进死信队列告警。

一致性#

秒级最终一致（消费延迟 + 攒批窗口）。以 DB 为最终数据源，每日对账抽样比对 cnt 与计数表，不一致时以 Redis 状态 Hash 重算为准修复。MQ 堆积超 10 万条自动暂停对账防误报。

使用场景#

写入 QPS > 5000 且热点集中（单内容 1 分钟 10 万级参与），或参与量达百万级、Cluster 下出现热 Key。方案三的两个前提被打破：单 Key 内存失控（大 Key），单节点写吞吐不足。

使用方案#

Redis 分桶扛读写，MQ 异步批量落库。依赖：Redis Cluster + MQ + 消费集群。与方案三共用「MQ 批量聚合」落库设计，状态侧从单 Key 换成分桶。

分桶动机：「一个内容一个 Key」必然踩两个雷——大 Key（500 万参与约 200MB，DEL / rehash 阻塞秒级）与热 Key（单 Key 落单节点，热点流量打满一台机器）。桶号由 userId 计算，Key 天然散列到不同节点，两个问题一次解决。

Key 设计#

状态桶在方案三单 Key 基础上分桶。差异是两点：状态从单 Key 变多桶（写入侧），计数增加热点分桶（b{0..15}）；落库路径与方案三完全一致（MQ 批量聚合）。

写入流程#

1. HSET 单命令完成判重 + 写入，无「先查后写」的并发缺口；
2. 状态与计数跨 Key 非原子是刻意取舍：Lua 合并两命令要求同 slot，与分桶分散互斥，偏差交给对账收敛；
3. 计数失败同步重试一次，仍失败记日志留给对账。

热点计数两档：单内容 QPS ≤ 5000 直接 HINCRBY 读 Key；超过后随机 INCR cnt:{targetId}:b{0..15}，worker 每 500ms 用 GETDEL 原子取走各桶增量（取走 = 读出 + 清零一步完成，避免读清间隙丢计数），一次 HINCRBY 累加进读 Key。前端永远只读读 Key，无读放大。

落库：MQ 批量聚合消费，同方案三：攒 500 条或 1s 触发批量提交，记录去重 upsert + 计数聚合净增量。交互 QPS 10 万时 DB 写入降至 200 QPS 以内。消费失败重试 3 次进死信队列告警。

一致性#

以 DB 为最终数据源。每小时抽样 1% 内容比对 DB 与 Redis 计数，偏差超阈值的内容用 HSCAN 全量校验状态桶，以 DB 为准修复，修复加分布式锁防写入踩踏。MQ 堆积超 10 万条自动暂停对账防误报。

降级#

Redis 超时率超 10% 熔断：直写 DB + 限流 1000 QPS（退化为方案一）；降级标记进本地缓存，5s 探测恢复；恢复后预热热点 TOP 1000，其余懒加载回源。