设计微博(Twitter/Facebook Feed)时间线（微博品牌推广方案）_facebook知识

以下主要译者自Github，译者也有圣戈当县认知：

donnemartin/system-design-primergithub.com/donnemartin/system-design-primer/blob/master/solutions/system_design/twitter/README.md

第二步：依照使用者市场需求和不动点列举结构设计概要

使用者市场需求

需要考量的各方面

发博客控制系统会将该条博客推送给影迷，并内含推送email等通告使用者创下主页（查阅自己的天数线）使用者查阅别人的博客使用者搜寻URL服务项目具有高易用性（注：high availability，指通过结构设计减少控制系统不能提供更多服务项目的天数。假定控制系统一直能够提供更多服务项目，他们说控制系统的易用性是100%。如果控制系统每运行100个天数基层单位，会有1个天数基层单位无法提供更多服务项目，他们说控制系统的易用性是99%。很多公司的高需用目标是4个9，也就是99.99%，这就意味著，控制系统的年断电天数为8.76个小时。详尽：https://www.w3cschool.cn/architectroad/architectroad-high-availability.html）

不需考量的各方面

将博客推送至其他在线视频（streaming，例如可被服务器端加速以获取的API，还有Twitter便携式收费项目服务项目Firehose，类streaming API但是更稳定：https://brightplanet.com/2013/06/25/twitter-firehose-vs-twitter-api-whats-the-difference-and-why-should-you-care/）依照使用者个人隐私市场需求过滤器博客的显示使用者预设过滤器URL暗藏非关注人申明/转贴对博客（网络流量、来源）的附加分析

不动点与假定

大体的量级假定

通用型网络流量原产失衡。比如说大家喜欢集中在早上8-12点晚饭刷博客，半夜没什么他用；不同地域性的使用者原产也失衡衡。发博客如果迅速，假如你有上百万影迷博客有上百万使用者所有使用者加起来六天会发布上百万条博客，三个月会发数千万条平均下来，一条博客被推送给10个影迷六天总计会有数千万条推送，三个月会有数千万条（x10）三个月会有几百万次写作允诺三个月会有数千万次搜寻允诺天数线点进使用者下载它的博客如果是一个加速操作方式使用者更频密的读博客而不是写博客如果著重强化读操作方式，提高速度搜寻搜寻应迅速搜寻是一个频密读（read-heavy）的操作方式，意味著会有上百万人搜寻同一URL，适度内存（cache）会降低成本

估计数据大小与服务项目频率

每条博客大小~10KB博客编号~8B使用者编号~32B文字~140 letter媒体（图像，视频）~10KB每个月新增150TB博客，每年新增5.4PB（依照上述博客增量x10KB）每秒写作允诺100k，每秒写博客允诺6k，60k影迷推送（x10平均影迷）每秒搜寻允诺4k

第二步：创建高层结构设计（High-level Design）

流程图：

将不同服务项目划分成各种service，有专属服务项目器负责read/write之间联结者是memory cache，此模块的用意是提高推送博客的速度主数据库是SQL媒体（图片，视频）被分开放在了对象库里面

第三步：结构设计核心组件（core components）

进一步挖掘每个组件的细节。

使用场景：推送博客

使用者博客数据如果被储存在关系数据库（relational database）中。此处如果讨论关系数据库与非关系数据库的权衡（https://github.com/donnemartin/system-design-primer#sql-or-nosql）。

向影迷推送博客/从关注以获取博客建立天数线是更加复杂的操作方式：

向影迷推送博客（60K操作方式每秒）会很容易使传统关系数据库过载。他们如果会选择一个能加速写操作方式的数据存储例如NoSQL或者Memory Cache。值得注意的是，读操作方式的速度：从内存里读取1MB需要250ms从SSD读取需要4倍天数从普通硬盘读取需要80倍的天数

他们如果把博客内含的媒体（例如图片、视频）存储在对象库（Object Store， https://en.wikipedia.org/wiki/Object_storage）里。

以下是描述推送博客的操作方式步骤：

使用者将博客推送至网络服务项目器（Web server）网络服务项目器向Write API推送写允诺Write API将博客存储在使用者天数线的SQL数据库里Write API向推送服务项目发出允诺：查询使用者关系图，以获取使用者影迷将博客存储在使用者影迷天数线的Memory Cache里（方便影迷加速写作，相当于为推送做好准备）为博客建立搜寻索引（search index service），方便加速检索将博客内含媒体存储到对象库使用通告服务项目，向使用者影迷推送通告利用队列实现异步推送

新推送的博客如果被留存于Memory Cache里以方便影迷写作。

使用场景：使用者下载自己的天数线（打开/创下博客主页）

使用者向网络服务项目器允诺下载天数线网络服务项目器向Read API推送读允诺Read API向天数线服务项目（Timeline Service）推送允诺：从Memory Cache里以获取关注的新博客（Memory Cache的写操作方式已经由Write API完成）查询数据控制系统，以获取博客附加信息

使用场景：使用者下载别人的天数线（点进其他使用者主页）

使用者向网络服务项目器允诺下载别人天数线网络服务项目器向Read API推送写允诺Read API从SQL DataBase以获取别人天数线数据

使用场景：使用者搜寻URL

使用者向网络服务项目器允诺搜寻网络服务项目器向Search API推送搜寻允诺Search API向搜寻服务项目推送允诺：解析/标记（Parses/tokenizes）搜寻允诺去除markup将成段文字分解成URL修正笔误查询Search Cluster以获得结果可能有并发查询可能需要合并来自不同cluster的结果

第四步：考量结构设计尺度（Scale the Design）

在有限制的情况下，识别并解决瓶颈。

这张图比第一张图添加了：

Load Balancer（平衡服务项目器查询负担）SQL数据库依照read/write拆分成了两部分，read有多重副本，write采取master-slave结构Horizontal Scaling：每一份service/API都是复数的，意味著有多台服务项目器同时提供更多相同服务项目，会有同步数据/map-reduce的问题利用CDN访问对象库

注意：以上图只是可能的针对大尺度（large-scale）的结构设计，具体问题需要具体分析，没有查明瓶颈之前，不能贸然结构设计。

查明瓶颈可以进行以下步骤：

Benchmark/Load TestProfiling在评估替代方案和折衷方案时解决瓶颈重复以上步骤

将结构设计扩大规模的常用方法/组件：

DNS CDN Load balancer Horizontal scaling Web server (reverse proxy)API server (application layer)Cache Relational database management system (RDBMS)SQL write master-slave failover Master-slave replication Consistency patterns Availability patterns

可能的瓶颈

影迷推送服务项目针对大V（上百万影迷那种），他们不如果每次都使用推送服务项目把一条博客推送给上百万影迷，而如果在每个影迷创下博客的时候去搜寻这个大V的博客，然后跟影迷自己的天数线主页合并整理附加的强化每个使用者在Memory Cache里面只存几百条最新博客只存活跃使用者的天数线如果使用者30天都没上博客了，他们就可以把它的天数线从Memory Cache里面拿掉，等它上的时候再从SQL数据库里面重建博客查询控制系统里面只存最近三个月的博客使用者查询控制系统里面只存活跃使用者Search Cluster的所有data都如果存在memory里面，降低查询延迟解决SQL数据库的瓶颈虽然Memory Cache降低了数据库的过载，但是仅仅只有SQL Read duplicas是无法解决读市场需求的。他们可能需要其他的SQL scaling patterns写市场需求过多，一个master-slave SQL也不够，可能需要其他的结构设计需用 pattern：Federation Sharding Denormalization SQL Tuning 或许可以考量把一部分数据放在NoSQL数据库里面

其他要点

以下各方面均可深入细化此问题：

https://github.com/donnemartin/system-design-primer/blob/master/solutions/system_design/twitter/README.md#additional-talking-pointsgithub.com/donnemartin/system-design-primer/blob/master/solutions/system_design/twitter/README.md#additional-talking-points

NoSQLCachingAsynchronism and microservicesCommunicationsSecurityLatency numbersOngoing