交互数据缓存设计：前端到后端的全链路方案

小流量：MySQL 直写#

技术栈：MySQL 8.0（InnoDB）+ HikariCP 连接池，无缓存组件。

状态表 upsert 与计数表 UPDATE 放同一个事务，行锁保证串行。写入 QPS 低于 2,000（读写比 10:1 时总 QPS 约 2 万，距纯库压测崩溃线还有一倍余量）时，4C8G 主从 MySQL 余量充足；此时引入 Redis，换来的是一个新故障域加一套一致性问题，属于负收益。

缓存能力由前两层提供：前端 HTTP 缓存和网关限流已经把重复流量挡在外面。这一级的一致性成本为零：数据库是唯一事实来源，没有第二份状态。

表结构设计（这两张表同时是中、大流量方案的落库目标表）：

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
);

记录表用唯一索引（user_id + target_type + target_id + interaction_type）兜底防重复写入，upsert 的 affected rows 判断状态是否翻转；计数表独立于记录表，展示页读计数表，不执行 COUNT(*)。

中流量：Redis + Cache-Aside + 异步落库#

技术栈：

读路径：Caffeine（可选，命中率不足时再上）→ Redis → MySQL，miss 回填。写路径分两条：状态数据走「MySQL 事务落库 + 同步删 Redis」，因为它需要读己之写；计数数据走「Redis INCR 先行 + MQ 或定时任务批量回写 MySQL」，因为它容忍分钟级旧值。两类数据一致性要求不同，写路径必须分开，不要用一条链路服务两种 SLA。

Redis Key 设计：

Key 设计的四条规则：

1. 命名统一 {对象}:{维度}:{id} 三段式。计数用 Hash 把赞 / 藏 / 关注多个维度装进一个 Key，Key 数量比 String 少一个量级；此量级单内容参与量在百万级以下，单 Key 内存可控，不需要分桶。
2. 状态与计数的 TTL 策略不同。状态 Hash 以库为事实源，设长 TTL（24 h），过期回源无损；计数 Hash 承载已接收未落库的增量，TTL 过期等于丢弃这部分计数，不设 TTL，兜底靠落库进度监控与对账。
3. 判重以记录表唯一索引为准（upsert 的 affected rows 决定计数是否翻转），不依赖缓存判重，避免缓存与库两套判重口径。
4. 状态删除按 field 粒度（HDEL），不做整 Key 删除：整 Key 删除会把其他用户的缓存状态一并打掉，造成回源放大。

中流量变体：Caffeine + MySQL 定时刷新（无 Redis）#

适用条件：不想承担 Redis 运维成本、部署规模为单机或小集群、热点内容集合能用任务周期内的增量捞取覆盖。读洪峰由本地缓存吸收，写仍由 MySQL 扛，但「MySQL 扛不住多少写」是经验误判，压测给出了实测边界。

写入能力实测（来源：自研压测客户端对点赞写接口施压，2026-09 采样）：发送量 7,240 万+ 请求，TPS 稳定在 2.5 万左右，平均延迟 427 ms。按 Little 定律，TPS × 平均延迟对应约 1.1 万在途请求，延迟主体是行锁排队与组提交等待。这组数字界定了方案的真实定位：吞吐上限覆盖多数中型业务的峰值写入绰绰有余，代价是写入延迟从 Redis 路径的毫秒级抬到数百毫秒级。

技术栈：

表结构设计：

1
create table v_like
2
(
3
    v_id        varchar(64)      not null comment '视频id',
4
    service_id  varchar(64)      not null comment '服务ID',
5
    shard_key   tinyint unsigned default '0' not null comment '分片KEY',
6
    like_num    int unsigned     default '0' not null comment '点赞数',
7
    create_time datetime(3)      default CURRENT_TIMESTAMP(3) not null comment '创建时间',
8
    update_time datetime(3)      default CURRENT_TIMESTAMP(3) not null on update CURRENT_TIMESTAMP(3) comment '更新时间',
9
    primary key (v_id, service_id)
10
);
11

12
create index idx_top
13
    on v_like (shard_key asc, update_time desc);

主键（v_id, service_id）定位唯一计数行，service_id 隔离业务线，一张表服务多个业务。三个字段支撑刷新链路：shard_key 把全表行划成 N 个可并行扫描的分片，定时任务按分片捞取、并发刷缓存，避免全表扫描，多实例部署时也可按分片分工；update_time 随行更新，作为增量捞取的水位，只捞上次刷新以来有变更的行；idx_top（shard_key + update_time 倒序）为这个捞取模式提供索引路径。写入侧是对计数行的单行 UPDATE 自增，每个内容只落一行（主键约束），热点内容的行锁竞争由 MySQL 直接承受；like_num 用 int unsigned，单内容计数上限约 42.9 亿。

与 Redis 方案的取舍：省掉 Redis、缓存框架和 MQ 三个组件，代价是三件事。缓存只存在于单个 JVM 内，多实例各自回源，全局命中率低于共享缓存；刷新窗口内所有实例返回的是上一次任务快照，旧值窗口等于任务周期（分钟级）；写入延迟在高并发下抬到数百毫秒（压测均值 427 ms），且热点内容始终落在同一计数行，极端热点集中或延迟预算以十毫秒计时，仍需 Redis + MQ 方案削峰。写入延迟越过预算、热点集无法枚举，或多实例回源把 MySQL 读压力打回原值时，切到 Redis 方案。

一致性模型与 Redis 方案不同：写路径直写数据库，不存在缓存双写，第一道防线（Cache-Aside）被「定时刷新 + miss 回填」取代，binlog 补偿整条省略，TTL 与任务周期共同构成兜底。WebSocket 推送引入自身的一致性细节：推送有丢失和乱序的可能，客户端重连后必须全量拉取一次对齐，不能依赖增量推送收敛。

大流量：多级缓存 + MQ 批量聚合落库#

在中流量基础上追加：

分层依据的数据：社区基准测试中 Redis 单机读约 11 万 QPS（来源：redis.com.cn 及社区压测汇总），Cluster 分片解决容量与吞吐，但单个热点 key 仍落在单分片。大流量的读洪峰主要靠 L1 吃掉：微博 Feed 缓存体系采用「多组 L1 前置集群 → 主缓存集群 → 数据库」结构，层内哈希保证 miss 穿透路径确定，支撑了百亿级日访问。本方案是其同构简化版：Caffeine 承担 90% 以上读命中，Redis Cluster 承担剩余部分，热点 key 由 JD-hotkey 毫秒级推送到全部实例内存，参考京东该框架支撑 618 大促的实践。

写路径把随机写聚合成批量写：点赞事件先写 Redis 和 MQ，消费端攒批后批量 UPSERT 到 interaction_record / interaction_count。热点内容的计数增量随机写入分桶，聚合 worker 周期取走增量累加进读 Key，前端永远只读读 Key，无读放大。

Redis Key 设计（在中流量基础上追加）：

分桶动机：「一个内容一个 Key」在参与量到百万级时踩两个雷——大 Key（500 万成员约 200 MB，DEL 与 rehash 阻塞秒级）和热 Key（单 Key 落单分片，热点流量打满一台节点）。状态桶按 userId 整除 1 万计算桶号，Key 天然散列到不同节点，两个问题一次解决；计数增量桶随机写入，聚合 worker 每 500 ms 用 GETDEL 取走增量（取走即清零，原子完成，避免读与清之间丢计数），一次 HINCRBY 累加进读 Key，读侧无放大。

知乎 Redis 平台 1.6 万实例支撑 2,000 万 QPS 的演进路径是「单机 / 主从 → Cluster → 客户端多级缓存」，与本方案方向一致，本方案没有引入该路径之外的组件。

第一道防线：写路径 Cache-Aside#

写操作统一「先更新数据库，再删除缓存」。两个被否决的替代方案：

• 先删缓存再更新库：删除到库提交之间存在窗口，并发读会把旧值重新填回缓存，旧值暴露概率高于先更库方案。
• 更新缓存而非删除：并发写到达时缓存更新的到达顺序不受控，后提交的值可能被先提交的值覆盖；删除是幂等的，天然免疫乱序。

Cache-Aside 本身不保证强一致（Azure 架构文档明确指出这一点），它把不一致窗口压到毫秒级。窗口来自两个真实场景：删除缓存失败，以及数据库被绕过缓存的方式改掉。这两个场景由第二道防线接管。

第二道防线：binlog 订阅补偿#

技术栈：Canal 订阅 MySQL binlog → RocketMQ / Kafka → 消费端删除缓存，失败进重试队列，超阈值告警并落重试表。

这一层覆盖两类场景：业务代码删缓存失败（网络抖动、Redis 故障），以及 DBA 或其他服务直改数据库。后一类变更业务代码感知不到，binlog 是唯一的全量变更视图。

选 binlog 订阅而非延迟双删做补偿的理由：

• 零代码入侵：业务代码只删一次，补偿链路独立演进。
• 延迟双删的「延迟」没有可靠依据，500 ms 还是 1 s 取决于主从延迟和业务耗时；且它只降低不一致概率、不消除（DTM 对该方案的结论），还要在业务代码里引入一个 sleep。
• binlog 链路有明确的失败路径：MQ 重试、死信告警、重试表，故障可观测。

代价：多两个组件（Canal、MQ），运维复杂度上升，binlog 延迟本身成为监控对象。大流量级别这条链路必备；中流量可选，TTL 足够短时可以只依赖第一道和第三道防线。

第三道防线：TTL + 对账#

• TTL 是所有缓存副本的最终兜底：L1 上限 60 s，L2 上限 24 h。任何失效机制失效时，数据最迟在 TTL 内回源修正。计数先行 Key 是例外：它承载未落库增量，TTL 过期等于丢数据，兜底靠落库进度监控与对账（见 Key 设计的 TTL 策略）。
• 对账任务：定时比对 Redis 计数与 MySQL 计数，差异超过 1% 时以库为准修正缓存并告警。增量对账 5 min 一次，全量对账每日一次。
• 监控四项进 Grafana：缓存命中率、binlog 延迟、MQ 堆积、对账差异数，各项设独立告警阈值。

读己之写的实现#

用户自己的状态不走任何共享缓存路径。写接口同步更新数据库和 Redis 后返回成功；前端收到响应后 mutate 本地 SWR 缓存并重新拉取状态接口；状态接口带 private 标记，网关不缓存。读己之写的延迟等于一次 RPC 加一次 Redis 读，1 s 目标内可达。

强一致场景不缓存#

账务计数、风控标记这类错误代价高的数据不进本方案的任何缓存层，直接读写数据库。本方案的一致性手段都是概率性的：Cache-Aside 压缩窗口、binlog 补偿有延迟、对账有周期。用概率手段服务强一致需求是错误分类。

SWR 与 HTTP 缓存叠加后 revalidate 失效#

数据层发起的 revalidate 请求会被浏览器 HTTP 缓存直接命中（响应还在 max-age 内），返回旧值，SWR 误以为校验完成。vercel/swr#558 记录了该冲突。解法：revalidate 请求显式带 Cache-Control: no-cache，或在数据层关闭对 HTTP 缓存的依赖。

网关缓存串读私有数据#

缓存 key 未包含身份维度时，A 用户的请求命中 B 用户的缓存。这类事故在带 Cookie 的响应上反复出现过。解法：网关层维护「可缓存接口清单」，清单外的响应一律不存；自动化测试覆盖每个清单接口的多用户隔离。

本地缓存多实例不一致#

实例 A 更新数据后，实例 B 的 Caffeine 仍是旧值，直到 TTL 过期。解法：写路径经 Redis Pub/Sub 广播失效消息，各实例收到后驱逐本地 key；同时保留 TTL 上限，作为广播丢失时的兜底。

分桶计数的 hash tag 热分片#

为聚合方便把同一内容的桶 key 写成 count:{contentId}:n，花括号会被 Redis Cluster 解析为 hash tag，N 个桶全部落进同一分片，热点没有消除。解法：桶 key 不用 hash tag，读聚合时接受跨 slot 的多 key 请求（客户端或代理聚合）。

延迟双删的 sleep 参数靠拍#

延迟时长没有公式，定 500 ms 的依据往往是「感觉主从延迟差不多」，主从延迟一变参数即失效。本方案用 binlog 补偿取代它；若必须使用，sleep 时长应跟随监控到的主从延迟动态计算，而不是常量。