微博技术解密（下）| 微博存储的那些事儿
胡忠想
该思维导图由 AI 生成，仅供参考
今天是微博技术解密系列的第二期，我们来聊聊微博存储的使用经验。上一期“微博技术解密”我讲到微博主要使用了两大类存储：一类是数据库，主要以 MySQL 为主；一类是缓存，主要以 Memcached 和 Redis 为主。
今天我来分享一下微博在使用数据库和缓存方面的经验，也欢迎你给我留言一起切磋讨论。
MySQL
上一期我讲到微博 Feed 的存储使用了两层的结构，为了减少对 MySQL 数据库的访问压力，在前面部署了 Memcached 缓存，挡住了 99% 的访问压力，只有 1% 的请求会访问数据库。然而对于微博业务来说，这 1% 的请求也有几万 QPS，对于单机只能扛几千 QPS 的 MySQL 数据库来说还是太大了。为此我们又对数据库端口进行了拆分，你可以看下面的示意图，每个用户的 UID 是唯一的，不同 UID 的用户按照一定的 Hash 规则访问不同的端口，这样的话单个数据库端口的访问量就会变成原来的 1/8。除此之外，考虑到微博的读请求量要远大于写请求量，所以有必要对数据库的读写请求进行分离，写请求访问 Master，读请求访问 Slave，这样的话 Master 只需要一套，Slave 根据访问量的需要可以有多套，也就是“一主多从”的架构。最后考虑到灾备的需要，还会在异地部署一套冷备的灾备数据库，平时不对外提供线上服务，每天对所有最新的数据进行备份，以防线上数据库发生同时宕机的情况。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
微博技术解密系列第二期揭示了微博在存储方面的创新和优化经验。文章详细介绍了微博在使用MySQL、Memcached和Redis方面的技术实践。针对MySQL，微博通过拆分数据库端口、读写请求分离和一主多从的架构来减轻数据库压力，同时还部署了冷备的灾备数据库。在Memcached方面，微博采用了多层缓存结构，包括L1、Master和Slave，以应对数百万QPS的数据请求。此外，微博还介绍了对Redis的改造，包括CounterService和Phantom两类存储组件，用于计数器和存在性判断的场景。这些经验展示了微博在存储方面的创新和优化，为读者提供了宝贵的技术参考和启发。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学微服务》，新⼈⾸单¥59
《从 0 开始学微服务》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(15)
- 最新
- 精选
拉欧redis里的布隆过滤器，也是同样的原理2019-02-018
王鸿运胡老师，问一个布隆过滤器问题: 因为hash函数存在冲突问题，所以布隆过滤器如果判断不存在肯定是不存在，判断存在有极低可能不存在（该key哈希后对应的三个位置都冲突了），你们是允许这种概率性误判存在，还是会通过其他方式规避?2019-02-0217- xylsh不太明白L1怎么分担带宽压力的， 1、是每组L1都有自己的带宽吗？ 2、带宽压力指机器接入的网络的压力吗？那岂不是每组L1都要有自己的网络带宽？？？2019-07-223
波波安老师，redis单个key value占大概65个字节，这个是怎么算得？2019-06-232
donsonredis内存有效负荷比较低，一条KV大概需要至少65个字节。 这65个字节是怎么来的？2019-02-262
westbrookbloom过滤器 当3次Hash 都存在 只能说明可能存在，还需要进行值对比，才能确认是否真的存在2019-12-081
惘 闻比如每天新发布的微博数量在 1 亿条左右，是否被用户读过的总数据量可能有上千亿，怎么存储是个非常大的挑战。 这是怎么算的啊,只有一千个用户吗? 还是每个用户不必存储所有的微博是否阅读标识.2021-01-291- mz感谢2019-02-23
小若胡老师新年快乐！利用七天假期完成了课程学习，受益匪浅，感谢！2019-02-09
CAFEBABE新年快乐2019-02-04
收起评论
