版本基线：MySQL 8.0+ | Redis 7.x | Memcached 1.6 | ShardingSphere 5.x 阅读时间：约 20 分钟 前置知识：[[微博技术解密（上）]] 微博信息流是如何实现的
上一篇文章剖析了微博 Feed 的存储选型（MySQL + Memcached 双层架构）。本文深入微博存储的三个核心组件，揭示其在亿级流量下的精妙设计：
这些设计不仅适用于微博，更是一套高并发存储的通用方法论——分库分表、缓存分层、冷热分离、BloomFilter 优化——对理解现代存储体系（如 ShardingSphere、TiDB、Redis Cluster）有直接价值。
在 Feed 存储中，Memcached 挡住了 99% 的访问压力，但剩余 1% 仍有几万 QPS，远超单台 MySQL（千级 QPS）的极限。需要从三个维度进一步减压：
思路：不同 UID 的用户按 Hash 规则访问不同数据库端口，将单个端口的访问量均分。
微博读请求量远大于写请求量，因此：
形成 一主多从（Master-Slave） 架构，将读压力从主库卸载。这正是 MySQL 主从复制 + 读写分离的标准实践，也是现代数据库中间件（ShardingSphere-Proxy、Vitess）的核心能力之一。
在异地部署一套冷备灾备库：平时不提供线上服务，每天对最新数据全量备份，以防线上数据库同时宕机。
架构形态：Master-Slave-Backup 三层，兼顾性能、可用性与灾备。
2025-2026 年，上述手工分库 + 主从配置已演进为平台化能力：
缓存层需承担几百万 QPS，主要挑战是带宽。同时要避免缓存未命中时流量穿透至数据库。微博设计了三层结构：
核心思想：逐层兜底，将数据库访问概率压到极低。这与现代多级缓存（本地缓存 L1 → Redis L2 → DB）的设计一脉相承。
微博对原生 Redis 进行了深度改造，诞生了专用于计数与存在性判断的两个组件。其核心动机是 Redis 的内存有效负荷过低。
原生 Redis 一个 KV 至少占用 65 字节，但业务有效数据可能仅 12 字节：
在千亿级数据规模下，这种浪费是致命的——这正是为极致场景定制存储的根本动因。
应用场景：转发、评论、点赞计数。
存储结构（内存 + SSD 分层）：
效果：内存使用量减少到原 Redis 方案的 1/15 ~ 1/5，并实现冷热数据分离 + LRU。
场景：判断"某用户是否赞过某微博""某微博是否已读"。这类数据：
存储成本对比（按每天千亿条新增估算）：
| 方案 | 单条占用 | 日增存储 | 结论 |
|---|---|---|---|
| 原生 Redis | 65 字节 | 约 6 TB | 不可接受 |
| CounterService | 约 8 字节 | 约 800 GB | 仍偏高 |
| Phantom（BloomFilter） | 约 1 字节（每个元素约 10 bit） | 约 120 GB | 最优 |
设计：与 CounterService 类似分 Table，但每个 Table 是一个完整的 BloomFilter：
BloomFilter 判存原理：
效果：每天存在性判断仅需约 120 GB 内存；业务需满足一周需求，最多 840 GB。相比原生 Redis 的 6 TB，降低两个数量级。
2025-2026 年，类似场景已有更成熟的工程化方案：
BF.ADD / BF.EXISTS，无需自研| 时间 | 里程碑 | 影响 |
|---|---|---|
| 2009 | MySQL + Memcached 双层架构 | Feed 存储基础 |
| 2010 | 端口拆分 + 读写分离 | 单库减压 |
| 2013 | 自研 CounterService | 计数器存储降本 5-15 倍 |
| 2015 | 自研 Phantom（BloomFilter） | 存在性判断降本两个数量级 |
| 2018+ | Redis Cluster / Codis 普及 | 缓存层现代化 |
| 2020+ | RedisBloom / NewSQL 成熟 | 原生替代自研组件 |
| 2025-2026 | 云原生存储 + 中间件平台化 | 分库分表、容灾、备份自动化 |
何时做分库分表：单库 QPS 逼近极限、且数据量持续增长时，按业务键水平分片。
何时用多级缓存：读多写少、需拦截缓存穿透、对延迟敏感的场景。多级缓存逐层兜底，将数据库访问压到极低。
何时自研存储组件：通用方案（如 Redis）存在致命的内存浪费，且业务量达千亿级、成本不可接受时，才考虑针对场景定制。
何时用 BloomFilter：存在性判断、稀疏数据、可容忍少量误判的场景。注意 BloomFilter 存在误判率（不存在可能被误判为存在），需评估业务可接受度。
微博的存储实践证明了：在高并发、大数据的极限场景下，通用存储方案的"够用"与"最优"之间存在巨大鸿沟。理解这些针对性优化（分片、分层、压缩、概率数据结构），是设计现代高并发存储体系的基石。