@xsen 很多这个词，和你自己下面讲的人是难找、还得靠其他语言转，不觉得逻辑上是冲突的么？你这个很多翻译过来，其实叫比例很低但有一定数量。

语法层面的比较其实没意义，核心还是生态。
java 的优势是 web 工程和 android 生态太好了。
国内除了超大厂敢上 go ，flutter 之类的，中小厂这么玩很容易坑自己。轮子少，招人难，遇到问题也不容易 google 到。

能搞定 mask rcnn 却搞不定加几像素轮廓？

需要做题才能加的群要不要试试？偶尔技术，大部分时间吹水
primeoj.com

看起来还挺好的，为啥评论怪怪的，就不能夸夸吗。
我觉得只要数据一致性可靠，服务 sla 并不是那么重要。

10 轮算法，10 年以上工作经验，是给 ACM 国家队招教练没错了

集思广益第二章：
工作绩效组内第一，但因为双非文凭 2 年间连普调都没轮上，内网抗议还被人匿名嘲讽。
摄神术操控教育部长将母校升级为 985 ，白富美 HR 小姐姐特批 4.0 跪求不要跳槽。

毕竟码农，即使身居道祖，也是只会应用于那种现实到可怜的场景。

灵活在哪，轻量几 K ？只说概念听起来很阿里不是吗？

好奇都问的什么问题

50 万的成本呢？可持续性如何？ A 股估值跟小打小闹不一样的，小打小闹没护城河，PE 上 5 就不错了。

npm 升级 v7 以后自动 install peer deps，很多老项目懒得更新 peer deps （因为 v4-v6 只有 warning ）的就会出这个毛病。

帝都 5 年社保才能买房吧，刚毕业就别考虑了。
体制内拿了户口干 2 年出来的还挺多得，就是收入比直接进入落后点，所以就看有多看重户口了。

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 优化的空间。

纸上谈兵的话就是这样了，欢迎做过这个量级的来指点迷津
---
感谢头条群友逆天之剑半夜讨论启发

破局取决于先败光家产还是先认清自己的能力。

room 吧，自己拥有的属性和状态变化自己维护，至于操作者和权限是另外一层含义了。而且这个动作今后未必属于 user 也是可能的。

上云，然后买买买