经典系统设计twitter（浅谈版）

用户可以follow其它用户。被follow的用户如果发贴，则要按照时序出现在foller的timeline里。很明显这是一个写频繁（考虑到帖子字数要求140以下），读更频繁的分布式系统。

考虑到很多的小的写操作，一开始我的思路是纯粹按照用户来sharding。但是看过参考资料才知道这是不可取的。因为会有两个因素导致冷热不均：水车型用户（大量的写和存储）以及网红型用户（大量的读操作）

否决掉这个后，自然想到的就是按照unique id来sharding。

unique id的构成由

• userid前缀
• 发帖时间戳，
  

组成。不特别把所有某个用户的帖子全部集中于一个sharding。可能是存储于连续的若干shardings里。

我这个版本，不同于参考资料的，有几个好处：

• 写操作可以分布到用户区间涵盖该用户的服务器上，插入。
• 浏览他人的tweets，往往要倒序查阅所有的该用户的帖子。那么因为我这个unique id是以用户id为前缀的。所以可以很快获取所有的该用户的帖子。
• 帖子和用户的关系也就不必再写入关系型数据库了。查找某个用户的帖子可以query（比如：用户id+周一，用户id周三）。
  

cache可以用来存储高频阅读的帖子，比如网红贴。

对于timeline的生成，
当用户发帖的时候，unique id就会生成，那么一方面写入存储媒体，一方面把帖子的id写入follow我的用户的timeline中。
我认为应该区分网红（follower超过某个数）和非网红。非网红的可以使用fan-out-on-write。而网红的贴采用fan-out-on-read。在用户读取的时候做aggregation处理。

retweet也是帖子。只不过其中的body是个ref-id的chain。比如A retweet B, but B was retweeting from C, C was retweeting from D. 这样读完这个ref-id的chain后可以deduce出ABCD的用户名，另外只要去取帖子D的内容就可以了。

estimation没有做，明白了以上的设计，加上一些常数和估计数字，estimation应该没有问题。

然而事实上分网红完全没必要。纯pull模型现在企业级的云完全handle得过来，反而维护两套业务逻辑代码，并且还要设置网红margin是很头疼的事情。还不如不干。

alibi 发表于 2019-3-28 10:43
userid + ts 的组合还是会shard到同一个partition上去吧? 怎么保证一个单独的key(userid+ts)会分布到某些sh ...

楼顶我的叙述是「不特别把所有某个用户的帖子全部集中于一个sharding。可能是存储于连续的若干shardings里。」
这样userid + ts 的组合会shard到连续的shardings里。但是每个单独的key(userid+ts)只会到某一个shard上。这样就把大小不同用户的数据分散了。而避免了冷热问题。

好想法，受教了

本文被选为03/15/2019全站置顶文章之一。
作者获得大米奖励，谢谢你的分享

也欢迎大家分享你收集和研究的系统设计题目、一起讨论

userid + ts 的组合还是会shard到同一个partition上去吧? 怎么保证一个单独的key(userid+ts)会分布到某些shard上，之后查询的时候不至于遍历所有的shard

假设follow 100个用户，这样db设计 我刷新timeline会很慢吧。
twitter读还是应该比写多，个别用户再狂写，大多数粉丝在狂读。
提速读肯定要用到cache server，问题就是cache什么，如何cache，如何update cache。

Neil_Acton 发表于 2019-3-28 21:07
假设follow 100个用户，这样db设计 我刷新timeline会很慢吧。
twitter读还是应该比写多，个别用户再狂写， ...

你提出这点“twitter读还是应该比写多，个别用户再狂写，大多数粉丝在狂读。“很有道理。


为了增速，除了楼顶提到的“cache可以用来存储高频阅读的帖子，比如网红贴。“，那么cache也应该用于最近的tweets。
在cache里，如果按照tweetID来shard，同时设置某个时间延迟的expiration，比如一般的用户的tweet统计后得知大多数是1天后就读的少了，那么设置延迟为2天。是不是就可以了？