Twitter是亚洲地区最小的SNS互联网众所周知，假如让他们从0已经开始结构设计twitter的控制系统构架，该怎么做呢？有什么样服务项目是要的？有什么样点须要提早考量？这首诗单纯如是说了结构设计类twitter控制系统的路子并在最终得出了参照结构设计。书名：Twitter System Architecture[1]

Twitter是亚洲地区领跑的新浪网SNS互联网服务项目，使用者能在这儿和写作被称作贴文（tweets）的发送者。在控制系统构架结构设计复试操作过程中，当被问到怎样结构设计Twitter时，绝大多数参选人单厢将其结构设计为乙烯服务项目。不过，将Twitter这种的小型服务项目结构设计为乙烯，说明参选人缺少结构设计互联网通讯的实战经验。从微服务项目即使lambda(或表达式)的视角来结构设计互联网通讯在那时是很恒定的优先选择。现阶段的态势是，没有人会将新服务项目结构设计为乙烯，子公司正渐渐将其巨大的乙烯服务项目切换为几组微服务项目。因而，参选人假如迪拉泽服务项目的形式结构设计Twitter。

机能市场需求

1. 使用者能正式发布或撷取捷伊贴文（tweet）
2. 每条贴文最多不超过140个字符
3. 使用者能删除贴文，但不能更新/编辑正式发布的贴文(写操作)
4. 户能标记喜欢的贴文(写操作)
5. 使用者能关注或取消关注另一个使用者(写操作)，关注一个使用者意味着使用者能看到其他使用者在他的时间线上的贴文
6. 能生成两种类型的时间线(读操作)，使用者时间线由他最终N个贴文组成，主页时间线由他正在关注的使用者的热门贴文按照时间降序生成
7. 使用者能根据关键字搜索贴文(读操作)
8. 使用者须要有一个帐户来正式发布或读取贴文(暂时使用外部身份服务项目)
9. 使用者能注册和删除帐户
10. Twitter支持包含文字和图片/视频的贴文，但在他们当前的结构设计中，将只支持文本
11. 分析/监视服务项目，以确定其负载、运行状况和机能
12. 分析还可为使用者提供关于关注谁、贴文通知、热门话题、推送通知和撷取贴文的意见或建议

非机能市场需求

1. 服务项目的高可用是最重要的市场需求，这意味着使用者能在自己的主页时间线上写作贴文，而感受不到任何停顿
2. 生成时间线的时间最长不得超过半秒
3. 不须要强一致性，只须要最终一致性，能使用关键词数据库用于搜索基于关键词的贴文
4. 随着使用者和贴文的增加，控制系统负载也在增加，因而控制系统假如具有可伸缩性
5. 持久化使用者数据

现在他们来做一些计算。

• 日活跃使用者平均请求/天 = 150M*60/86400 = 100k /秒
• 峰值使用者 = 平均并发使用者* 3 = 300k
• 三月内最小峰值使用者数 = 峰值使用者数*2 = 600k
• 读QPS = 300k
• 写QPS = 5k

twitter服务项目的概要结构设计

由于控制系统的复杂性，能将其划分为若干个服务项目，其中包括若干个微服务项目。

1. 贴文服务项目（Tweet service）
2. 使用者时间线服务项目（User timeline service）
3. 扇出服务项目（Fanout Service）
4. 主页时间线服务项目（Home timeline service）
5. SNS互联网服务项目（Social graph service）
6. 搜索服务项目（Search service）

下面是twitter服务项目中不同逻辑组件或微服务项目构架。

twitter服务项目的详细结构设计

所有微服务项目都能被称作模块。

1. 贴文服务项目（Tweet service）

• 接收使用者贴文，转发使用者贴文到关注者时间线和搜索服务项目
• 存储使用者信息，贴文信息，包括使用者的贴文数量以及使用者喜欢的状态
• 包括应用服务项目器、分布式的内存缓存以及后端的分布式数据库，或者使用直接由数据库(例如Redis)支持的内存缓存

然后他们看一下tweet服务项目的数据库表结构。

使用者（Users）表包含使用者的所有信息，贴文（Tweet）表存储所有贴文，Favorite_tweet表存储了喜欢的贴文记录，也就是说，每当使用者喜欢一条贴文时，就会在Favorite_tweet表中插入一条记录。

2. 生成唯一的贴文Id

当使用者调用postTweet()时，调用会发送给应用服务项目器。应用服务项目器为该贴文生成一个唯一的id，同样的机制也能用来为贴文生成短URL。另一个形式是基于应用服务项目器的UUID（Universally unique identifier）。贴文ID生成后，应用服务项目器将该贴文插入分布式缓存和数据库的tweet表中。由于须要在执行贴文的创建/更新/删除操作的同时更新缓存和数据库，所以他们使用缓存透写机制。

3. 可扩展性结构设计

• 他们能将分布式缓存和数据库划分为多个分区和副本。
• 基于使用者ID分片
• 基于贴文ID分片
• 基于使用者ID和贴文ID进行两层/级别分片

4. SNS互联网服务项目（Social graph service）

• 实现Following API，跟踪使用者之间的关注关系
• 包括应用服务项目器、分布式缓存和数据库
• 用于存储使用者关系的数据库表结构

• Following API
• 将被关注使用者的时间线异步合并到关注者的信息事件流中
• 取消关注一个使用者后，从关注者的事件流中异步删除他的贴文
• 异步的从信息事件流中挑选贴文
• 之所以须要异步操作，是因为这个操作过程比较慢，而使用者在关注和取消关注其他使用者时，希望很快得到反馈
• 异步的缺点是使用者在取消关注后，假如刷新信息事件流，会发现这些信息仍然存在，但最终它们会被删除

5. 使用者时间线服务项目（User timeline service）

• 返回使用者的时间线，以降序排列的形式包含使用者所有贴文。此服务项目可用于主页时间线或其他使用者的时间线。
• 该服务项目包括应用服务项目器和分布式内存缓存，但没有涉及该服务项目的数据库。
• 使用者时间线是使用包含使用者贴文链接列表的数据结构结构设计的

• 当使用者正式发布一条贴文时，tweet服务项目调用使用者时间线服务项目，将该贴文插入到使用者时间线的贴文列表顶部，运算复杂度为O(1)。
• 此外，分析仪表板能配置参数K，表示能保留的贴文个数，K默认为1000，表示保留使用者时间线轴中的最终K条贴文。
• 在使用者时间线列表中，贴文按creationTime（创建时间）降序存储。当使用者时间线列表达到最小K条贴文时，最老的条目将被删除。

6. 扇出服务项目（Fanout Service）

• 将新贴文转发到搜索和主页时间线服务项目，以及其他组件/微服务项目，比如态势服务项目或通知服务项目
• 由多个分布式队列组成
• 当使用者发送一条贴文消息时，该服务项目把消息放入贴文队列，SNS互联网服务项目要获得使用者的关注者列表，并在第二组队列中插入尽可能多的消息。对于名人使用者来说，他们拥有非常多的影迷，其影迷数即使超过了每次推送的阈值。那么，怎样处理这个问题呢?
• 该服务项目是一个先进先出的任务队列列表，处理共享相同列表的任务，并在完成后反馈给队列服务项目器。队列服务项目器是异步任务的重要组成部分，其执行的任务可能不会立即收到响应，但却能够保证最终一致性。

7. 主页时间线服务项目（Home timeline service）

• 显示使用者的主页时间线
• 包括来自其他关注的使用者的贴文，按照贴文的creationTime（创建时间）降序显示。
• 其结构设计类似于使用者时间线服务项目。
• 但是比使用者时间线服务项目稍微复杂一点，因为使用者将插入最捷伊贴文，并且当贴文数量超过K值时须要删除最老的贴文，假如使用者关注了很多其他使用者，服务项目还须要一些机制来给不同关注使用者的贴文赋予不同的权重。

8. 搜索服务项目（Search service）

• 为使用者提供搜索查询服务项目
• 扇出服务项目将贴文传递给搜索服务项目

• Ingester(或ingestion engine)：给贴文标记上许多标签、术语或关键字。例如这条贴文:我想成为像亚马逊的杰夫·贝索斯一样非常富有的人，它会过滤掉那些在搜索中没有用的词。除了杰夫·贝索斯(Jeff Bezos)和亚马逊(Amazon)，所有其他词都将被丢弃。Ingester能通过配置或数据库获得词汇表。
• 一个叫做词根提取（stemming）的操作过程对剩下的单词进行分析，以确定它们的词根。Stemming是处理词干、词根或词根的词形变化(或派生)的操作过程。因而，会在数据库中保存一个查找表。这种方法的优点是能单纯、快速、轻松的处理异常。缺点是捷伊或不熟悉的单词即使是完全符合规则的，也不会被处理。
• 传递到搜索索引
• 搜索索引微服务项目将创建反向索引，并存储从内容(如单词)到其所在文档或几组文档中的位置的术语映射索引，在他们的例子中，这是一个或几组贴文。
• Blender服务项目：在twitter平台上为使用者提供搜索查询。当请求搜索查询时，首先确定搜索条件，然后进行词干分析，最终使用词根在术语的倒排索引上运行搜索查询。

9. 照片和视频

• 使用NoSQL数据库
• 媒体文件(使用文件控制系统)
• 数据表格式

twitter的互联网

twitter的最终详细结构设计

控制系统结构设计

数据构架

参照文档

1. http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html
2. https://www.codekarle.com/system-design/Twitter-system-design.html
3. https://blog.twitter.com/engineering/en_us/topics/infrastructure/2017/the-infrastructure-behind-twitter-scale
4. http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html

References:[1] Twitter System Architecture: https://medium.com/interviewnoodle/twitter-system-architecture-8dafce16aec4

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、互联网、后端构架、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢写作、思考，相信持续学习、终身成长，欢迎一起交流学习。：公众号DeepNoMind

→CL自助下单平台←