1. 问题背景与核心挑战
1.1 点赞数缓存的现状
在分布式应用中，点赞数缓存往往作为高性能路径，避免直接击穿数据库。但是当数据源和缓存之间出现不一致时，会延迟反映用户的行为，导致 用户看到的点赞数与实际状态不符，对体验产生影响。
此外，缓存刷新策略如果设置不当，可能在高并发场景下引发 并发写入的冲突，进一步加剧不一致。
1.2 刷新后不一致的成因
主要成因包括 缓存过期策略与写入路径不同步、多实例并发写入未做幂等性保护、以及 热数据突然涌入导致穿透缓存等。
在某些场景下，数据库写入比缓存更新慢，导致在缓存修复的瞬间出现差异；另外，异步刷写策略可能丢失更新，也会造成不一致。
2. 缓存策略总览
2.1 读取路径策略
优先从 本地缓存-远端缓存-数据库 组合路径读取，确保命中率和数据准确性；在 高并发读取场景，设定合理的 TTL 和回源策略，避免 缓存穿透。
为点赞数这类热数据，推荐采用 读时回源+写时缓存 的双路径模式，确保读取时能校验数据的新鲜度。
2.2 写入路径策略
对写入请求执行 双写策略，即同时写入缓存与数据库；引入 幂等性标识，确保同一操作不会重复叠加。
使用异步刷写机制，使得缓存更新与数据库持久化尽可能解耦；在系统容错时，补偿机制能把未落地的更新重新落地。
3. 数据一致性的实战解法
3.1 双写与幂等性设计
核心是确保同一次点赞操作在缓存和数据库中的状态一致；幂等接口与去重能避免重复计数，同时减少后端复杂度。
实现方式包括：在接口层做幂等性检查，以及在 Redis 侧对关键键使用 自增并记录时间戳，以便对比消费端的变更。
3.2 基于 Redis Lua 的原子操作
利用 Lua 脚本在 Redis 端原子执行增量与日志写入，避免跨命名空间操作导致的竞态；同时通过脚本将缓存与日志绑定，提升一致性。
-- Lua script: 原子地将点赞计数自增并记录日志
local key = KEYS[1] -- like counter key, e.g., post:likes:123
local delta = tonumber(ARGV[1]) -- delta, usually 1
local now = tonumber(ARGV[2]) -- timestamp
local cur = tonumber(redis.call('GET', key) or '0')
redis.call('INCRBY', key, delta)
local logKey = 'log:likes:' .. tostring(now)
redis.call('RPUSH', logKey, cjson.encode({id= key, delta=delta, ts=now}))
return cur + delta
3.3 异步刷写与事件驱动架构
通过 消息队列/事件总线 将缓存更新与数据库持久化解耦；吞吐量提升 的同时，便于排查不一致的原因。
示例流程包括：用户点击赞 -> 缓存自增 -> 发送 点赞事件 到消息队列 -> 监听端落地到数据库，并在落地成功后确认缓存状态；如落地失败，则重试和补偿。
4. 监控与回放
4.1 监控点与告警
建立对 缓存击穿、更新延迟、以及数据不一致比例的监控；设定阈值告警，如单日不一致比例超过 1% 时触发。
使用 为关键键设置版本号/时间戳，以便快速对比缓存与数据库的版本差异，便于追踪原因。
4.2 回放与自愈能力
实现对历史日志的回放，判断是否有 丢失的更新；通过回放机制，自动修正/补偿缓存与数据库的差异。
对关键场景启用 幂等日志，确保回放不会对同一事件重复计算。
