pkupyx
2021-04-28 03:25:43 +08:00
没做过这么大量级的，瞎想了想
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 优化的空间。
纸上谈兵的话就是这样了，欢迎做过这个量级的来指点迷津
---
感谢头条群友逆天之剑半夜讨论启发