pkupyx 最近的时间轴更新
pkupyx

pkupyx

做题加群:http://primeoj.com
V2EX 第 487445 号会员,加入于 2020-05-02 14:57:22 +08:00
根据 pkupyx 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
pkupyx 最近回复了
灵活在哪,轻量几 K ?只说概念听起来很阿里不是吗?
121 天前
回复了 neruda 创建的主题 程序员 Java 收徒 7 天后情况汇报
好奇都问的什么问题
50 万的成本呢?可持续性如何? A 股估值跟小打小闹不一样的,小打小闹没护城河,PE 上 5 就不错了。
npm 升级 v7 以后自动 install peer deps,很多老项目懒得更新 peer deps (因为 v4-v6 只有 warning )的就会出这个毛病。
129 天前
回复了 areyoukidding 创建的主题 职场话题 校招 offer 对比
帝都 5 年社保才能买房吧,刚毕业就别考虑了。
体制内拿了户口干 2 年出来的还挺多得,就是收入比直接进入落后点,所以就看有多看重户口了。
140 天前
回复了 find456789 创建的主题 React 有多少人是放弃 react-native,转向原生了?
20MB 可能是框架问题,220MB 绝对是你的问题。。。
没做过这么大量级的,瞎想了想

1.先定义下要持久化的表:朋友圈:moment,用户的跟随者:user_follower,用户跟随了谁:user_followee
用户:user (无关,外部服务)

2.moment(user_id,data...)表
moment 表 10W QPS 写,一天按 10W 秒算,每天新增 100 亿,每年新增 4W 亿。这个量级需要同时做 sharding 和冷热库了。然后热库存最近一年的,剩下全同步给冷库,应该是够用的。
热库:一年需要存 4W 亿,按单表 1KW 算(其实 SSD 了可以多点),需要 40W 个表,2^19=524288 。按照实体机每台 32 个库,每个库 32 个表分,需要 512 台 mysql 实体机,还可以。
冷库:复制一个同规模的集群,随时同步超过一年的数据。正常业务的冷查询不会很多,做好冷库的防刷是另外一个话题。这边要计算下磁盘够不够用,按照一条 moment 2KB 来算,冷库设计存 10 年,需要存 40W 亿( 40T ) * 2KB = 80PB,平均每台 160TB,现在密集写的服务器等级的 SSD 主要是 3.84TB 的? girigiri 够。热库除以 10,16TB 一台物理机,肯定够用了。
sharding 维度:按按发布用户 id 吧,my_moment_ids 的查询直接命中了。

3.follower(user_id,follower_id) & followee(user_id,followee_id)表
user_follower 和 user_followee 是等价量级的,可以认为都是热数据。这个增量还比较可控,每人 400 个好友,按 1W 亿规模计算,上面那个方案够用。两个库分别按 user_id 做 sharding,一个对应我关注的用户列表,一个对应关注我的用户列表,写关系时候同步写 2 个表,主要是方便查方便写缓存。

4.发布&查询朋友圈
增加缓存:moment 实体,user_follower_ids,user_followee_ids 的缓存,我发的朋友圈的 id 索引 my_moment_ids(user_id->[{my_moment_id,time},...]),重点是我看的朋友圈的 id 关系索引 mix_moment_ids(user_id->[{followee_moment_id,time},...]):
全量写到 my_moment_idx 缓存,好办。
读 moment 实体,这块甚至能做到 99%命中缓存。

维护 mix_moment_ids:
全量写:如果 mix_moment_ids 要全量写全量存,量级是 moment 表量级的 400 倍,每年要新增 1600 万亿( 1.6P )条数据,按上面的计算,就算放宽 sharding 到单表 1 亿,也需要一个上万台的 mysql 集群,估计 GG 。全量写扩散到 redis 不丢弃,每条关系按 10 字节算,一年 16PB,集群内存估计一个月也存不下,GG 。

部分写:
mix_moment_ids 只写前 100 条的 ID,按 100 亿(10G)用户每条 10 字节计算,10TB 数据,redis 集群内存富裕。总之这里策略合适抗住 95%的 mix_moment_idx 查询,剩下 5W 读 qps 需要计算。命中不够就多缓存点,100TB 的 redis 集群还是有的。全量写到 mix_moment_ids 前 100 条的话,写操作先需要读 my_follower_ids,再写到对应人的 mix_moment_ids,集群需要 4KW 的写 QPS,理论上可以做得到。。。吧?不行就只写热点用户。

剩余 5Wqps 变成了读扩散:这里包含没命中缓存的和冷用户,需要取 user_followee_ids,再取 400 个我关注的人的 my_moment_ids 按时间聚合,这样变成 2KW 读 QPS,95%打到 redis 集群上,剩下 100Wqps 命中 mysql 集群的 moment 表,全热库的话每台 2KQPS,够了。这块应该有很大的做各种 trick 优化的空间。

纸上谈兵的话就是这样了,欢迎做过这个量级的来指点迷津
---
感谢头条群友逆天之剑半夜讨论启发
破局取决于先败光家产还是先认清自己的能力。
也许数据库上有唯一索引重复就回滚吧
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2518 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 8ms · UTC 12:28 · PVG 20:28 · LAX 05:28 · JFK 08:28
♥ Do have faith in what you're doing.