其他分享
首页 > 其他分享> > 系统设计面试题-实现Twitter时间线和搜索

系统设计面试题-实现Twitter时间线和搜索

作者：互联网

设计Facebook feed和设计Facebook搜索都是类似的问题。

步骤1：概述用例和约束

收集需求并确定问题的范围。提出问题以澄清用例和约束。讨论假设。

 如果没有面试官来回答明确的问题，我们将定义一些用例和约束。

用例

我们将把问题的范围限定为只处理以下用例

超出范围

约束和假设

状态假设


总则

时间线

搜索

 

计算用量

向面试官说明你是否应该计算资源的使用量。

方便的转换指南：

 

步骤2：创建宏观设计

概述所有重要组件的高级设计。

 

步骤3：设计核心组件

深入了解每个核心组件的细节。

用例：用户发布tweet 

我们可以在关系数据库中存储用户自己的tweet来填充用户时间线（来自用户的活动）。我们应该讨论选择SQL还是NoSQL的用例和权衡。


发布tweet和建立home时间线（用户关注的人的活动）更为棘手。将tweet扩散给所有关注者（每秒扩散6万条）将使传统的关系数据库过载。我们可能希望选择一个具有快速写入的数据存储，例如NoSQL数据库或内存缓存。从内存中顺序读取1 MB大约需要250微秒，而从SSD读取需要4倍的时间，从磁盘读取需要80倍的时间。


我们可以将照片或视频等媒体存储在对象存储上。

向你的面试官说明你需要写多少代码。

如果我们的缓存是Redis，我们可以使用具有以下结构的Redis列表：

           tweet n+2                   tweet n+1                   tweet n
| 8 bytes   8 bytes  1 byte | 8 bytes   8 bytes  1 byte | 8 bytes   8 bytes  1 byte |
| tweet_id  user_id  meta   | tweet_id  user_id  meta   | tweet_id  user_id  meta   |

新的tweet将被放置在缓存中，缓存填充用户的关注时间线（用户跟踪的人的活动）。

我们将使用REST API：

$ curl -X POST --data '{ "user_id": "123", "auth_token": "ABC123", \
    "status": "hello world!", "media_ids": "ABC987" }' \
    https://twitter.com/api/v1/tweet

Response:

{
    "created_at": "Wed Sep 05 00:37:15 +0000 2012",
    "status": "hello world!",
    "tweet_id": "987",
    "user_id": "123",
    ...
}

对于内部通信，我们可以使用远程过程调用。


用例：用户查看关注时间线

REST API: 

$ curl https://twitter.com/api/v1/home_timeline?user_id=123

Response:

{
    "user_id": "456",
    "tweet_id": "123",
    "status": "foo"
},
{
    "user_id": "789",
    "tweet_id": "456",
    "status": "bar"
},
{
    "user_id": "789",
    "tweet_id": "579",
    "status": "baz"
},

 

用例：用户查看个人主页

restapi与关注 timeline类似，只是所有tweet都来自用户，而不是用户关注的人。

 

用例：用户搜索关键词

REST API:

$ curl https://twitter.com/api/v1/search?query=hello+world

 除了与给定查询匹配的tweet外，响应与 timeline类似。

 

步骤4：演进设计

确定并解决瓶颈，给出限制条件。 

重要提示：不要从最初的设计直接跳到最终的设计！

说明您将1）基准测试/负载测试，2）瓶颈概况，3）在评估备选方案和权衡时解决瓶颈，4）重复。


讨论在初始设计中可能遇到的瓶颈以及如何解决每个瓶颈是很重要的。例如，通过添加带有多个Web服务器的负载均衡可以解决哪些问题？CDN？主从复制？每种方法有哪些选择和权衡？


扩散服务是一个潜在的瓶颈。拥有数百万粉丝的Twitter用户可能需要几分钟的时间来完成他们的tweet扩散过程。（译者：后面还有一句话，我没理解意思）：This could lead to race conditions with @replies to the tweet, which we could mitigate by re-ordering the tweets at serve time.


我们还可以避免从关注度很高的用户那里散播tweet。在拉取用户时间线时，通过搜索那些大v的推文list，将它们merge到用户的时间线中，再返回list (译者：其实就是写扩散的时候，大v不扩散，然后读写扩散结合去做feed流)


其他优化包括：

我们还希望通过SQL数据库解决瓶颈问题。


尽管内存缓存可以减少数据库的负载，但仅SQL读取副本不太可能足以处理cache miss。我们可能需要采用额外的SQL扩展模式。


大量的写操作将使单个SQL写操作主从设备无法承受，这也表明需要额外的扩展技术。

我们还应该考虑将一些数据移动到NoSQL数据库。

 

其他谈话要点

根据问题范围和剩余时间，需要深入研究的其他主题。

NoSQL

Caching

Asynchronism and microservices

Communications

Security

Latency numbers

Ongoing

 

 

 

 

 

标签：面试题,请求,tweet,用户,id,搜索,推文,Twitter
来源： https://blog.csdn.net/TongWaccs/article/details/112103484