直接回答：计数系统的特征是写多读多、允许秒级延迟、容忍极小误差但要求不丢。写路径不进数据库：点赞事件先入消息队列削峰，消费者聚合后批量累加到 Redis（INCRBY），再由异步任务周期把 Redis 增量刷回 MySQL（upsert 累加）；读路径直接读 Redis，miss 时回源数据库并回填。数据库只承担持久化与冷数据回源，永远不抗流量。

展开解析：细节分层：热点问题——单个爆款对象的计数 key 被打爆（Redis 单 key 能到十万 QPS，但绑定单分片），极端热点拆子 key（key:shard:{n} 分散写，读时聚合）；去重语义——点赞要防重复（用户-对象唯一关系放 Redis SET 或 RoaringBitmap，量级大到 SET 放不下时换 BloomFilter 加数据库唯一索引兜底）；一致性——Redis 到 DB 的刷盘窗口内宕机会丢增量，用 AOF 每秒刷盘 + 对账任务（比较事件流重放与当前值）把误差压到可接受；时间维度统计（每分钟播放量）用分桶 key 或时序库，别在一个 key 上折腾。读侧缓存击穿：爆款内容刚发布 DB 无记录，回源要加空值缓存或单飞（singleflight）。容量估算示例：十亿对象 × 8 字节计数 + 键开销约几十 GB，Redis 集群完全可扛；播放量的“+1 防刷”（同设备频控、行为校验）属于风控侧，架构上放在事件入口而非计数核心。

追问方向：排行榜（实时 TopN）在计数之上怎么做？跨地域计数如何汇总？

（约 480 字）