V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  pkupyx  ›  全部回复第 1 页 / 共 5 页
回复总数  99
1  2  3  4  5  
18 小时 37 分钟前
回复了 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 优化的空间。

纸上谈兵的话就是这样了,欢迎做过这个量级的来指点迷津
---
感谢头条群友逆天之剑半夜讨论启发
破局取决于先败光家产还是先认清自己的能力。
也许数据库上有唯一索引重复就回滚吧
11 天前
回复了 csfreshman 创建的主题 程序员 面试题讨论,类设计
room 吧,自己拥有的属性和状态变化自己维护,至于操作者和权限是另外一层含义了。而且这个动作今后未必属于 user 也是可能的。
上云,然后买买买
先得聊聊什么叫 redis 扛不住,你给的方案难道是主备?
16 天前
回复了 yuann72 创建的主题 MySQL 这两种表设计, 用哪种好?
第一种就不能整个 byte,按 bit 来判断星期几么。。。
21 天前
回复了 Hsinyao 创建的主题 职场话题 腾讯云北京怎么样?暑期实习
他们好几年前就在银科,搬去了西格玛又要搬回银科。但是疼逊云吧一言难尽。。。
@ampedee 那就不是大厂面试了。。。
看内推谁主动要求的了,如果你要求的然后人家推了,你因为职级问题连面都不面的话,那确实觉得挺坑的。
如果想要一只以 rw open 然后多人读写,把这个文件读写模块封装一下,对外暴露同步写接口,量大还能整个 buffer 异步。然后通过业务逻辑保证不把配置写错乱。
24 天前
回复了 HereIStand 创建的主题 职场话题 关于 offer 选择问题
@HereIStand 不熟,只是买了他们产品,刚好看过宣传 PPT 。。。
24 天前
回复了 HereIStand 创建的主题 职场话题 关于 offer 选择问题
E 轮,CRM,996 。销售易?
24 天前
回复了 Alcantara 创建的主题 程序员 转 Java 后端,还是继续前端?
接触业务,成为有产品思维的前端专家,这种又产品思维还知道怎么实现的前端人才很稀缺的。
24 天前
回复了 luwill 创建的主题 职场话题 聊聊大厂面试一次不过,次次不过?
如果简历一般的,其实先去中型厂干 2 年,跳大厂成功率会上升一些。毕竟同等情况下大家总会愿意选个背景强的。
我们一般都找代理,2-3 个月 600 元。
25 天前
回复了 copper20 创建的主题 程序员 线下面试服装选择 正装 or 其他
除非是日企,否则穿西装会减分吧。。。
具体电商业务理论上每次编辑商品信息都得创建新的商品快照,编辑价格也一样。所以创建假超管账户,然后走人工编辑创建快照的逻辑吧。
1  2  3  4  5  
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2256 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 42ms · UTC 00:50 · PVG 08:50 · LAX 17:50 · JFK 20:50
♥ Do have faith in what you're doing.