2020-08-31

如何设计一个新鲜事系统？
如果在面试中，遇到系统设计题目，不要一上来就堆砌各种技术栈，什么分布式集群，微服务，读写分离，分库分表，hdoop，负载均衡lvs，mongodb，hBase，一致性哈希，主从同步等。生怕不能体现自己广度的技术栈，如果是实际工作中，你会一开始就设计一个大而全的系统架构吗？

1 需求分析
可以询问面试官，需要设计哪些功能，需要承担多大的访问量？DAU，MAU。
先列出功能
注册登录
个人信息编辑展示
上传视频图片
搜索
发送分享新鲜事
Timeline / News Feed
关注取关
筛选核心功能，因为面试中时间不多，什么都设计不太现实。
发送新鲜事
TimeLine
News Feed
关注取关
注册登录

并发用户 Concurrent User
• 日活跃 * 每个用户平均请求次数 / 一天多少秒 = 150M * 60 / 86400~ 100k
• 峰值 Peak = Average Concurrent User * 3 ~ 300k
• 考虑业务增长 Fast Growing
• MAX peak users in 3 months = Peak users * 2
• 读频率 Read QPS (Queries Per Second)
• 300k
• 写频率 Write QPS
· 5k

为什么要分析QPS
• QPS = 100
用你的笔记本做 Web 服务器就好了
• QPS = 1k
用一台好点的 Web 服务器就差不多了
需要考虑单点故障
• QPS = 1m
需要建设一个1000台 Web 服务器的集群
需要考虑如何 Maintainance（某一台挂了怎么办）

• QPS和 Web Server (服务器) / Database (数据库) 之间的关系
•一台 Web Server 约承受量是 1k 的 QPS （考虑到逻辑处理时间以及数据库查询的瓶颈）
•一台 SQL Database 约承受量是 1k 的 QPS（如果 JOIN 和 INDEX query比较多的话，这个值会更小）
•一台 NoSQL Database (Cassandra) 约承受量是 10k 的 QPS
•一台 NoSQL Database (Memcached) 约承受量是 1M 的 QPS

系统设计=服务+存储

将大系统拆成小服务
1.Replay 重放需求
2.Merge 归并需求
对于同一类问题的逻辑处理归并在一个 Service 中。

用户服务
推文服务
媒体服务
关系服务

存储
1.Select 为每个 Service 选择存储结构
2.Schema 细化表结构

数据如何存储与访问
关系型数据库 SQL Database
• 用户信息 User Table
• 非关系型数据库 NoSQL Database
• 推文
• 社交图谱 Social Graph (followers)
• 文件系统 File System
• 图片、视频 Media Files

设计数据库的表结构
用户表
id integer
username varchar
email varchar
password varchar

用户关系表
from_user_id foregin_key
to_user_id foregin_key

推文表
id interger
user_id foregin_key
context text
created_at timestamp

新鲜事系统有哪些内容？
1、登陆 Facebook / Twitter / 朋友圈 之后看到的信息流
2、你的所有朋友发的信息的集合

新鲜事系统的核心因素？
关注与被关注
每个人看到的新鲜事都是不同的

储存一般有两种模式
pull模式
算法
• 在用户查看News Feed时，获取每个好友的前100条Tweets，合并出前100条News Feed
• K路归并算法 Merge K Sorted Arrays
• 复杂度分析
• News Feed => 假如有N个关注对象，则为N次DB Reads的时间 + K路归并时间(可忽略)
• Post a tweet => 1次DB Write的时间

N次DB Reads非常慢，且发生在用户获得News Feed的请求过程中。

push模式
• 算法
• 为每个用户建一个List存储他的News Feed信息
• 用户发一个Tweet之后，将该推文逐个推送到每个用户的News Feed List中
• 用户需要查看News Feed时，只需要从该News Feed List中读取最新的100条即可
• 复杂度分析
• News Feed => 1次DB Read
• Post a tweet => N个粉丝，需要N次DB Writes
• 好处是可以用异步任务在后台执行，无需用户等待

followers的数目可能很大。

选用push还是pull模式？
热门Social App的模型
• Facebook – Pull
• Instagram – Push + Pull
• Twitter – Pull

• 什么时候用 Push？
• 资源少
• 想偷懒，少写代码
• 实时性要求不高
• 用户发帖比较少
• 双向好友关系，没有明星问题（比如朋友圈）
什么时候用 Pull ?
• 资源充足
• 实时性要求高
• 用户发帖很多
• 单向好友关系，有明星问题

到这里，就完成了一个基本可用的系统。
系统如何优化与维护？
优化
1 解决设计缺陷
解决pull的缺陷
最慢的部分发生在用户读请求时（需要耗费用户等待时间）
• 在 DB 访问之前加入Cache
• Cache 每个用户的 Timeline
• N次DB请求 → N次Cache请求 (N是你关注的好友个数)
• Trade off: Cache所有的？Cache最近的1000条？
• Cache 每个用户的 News Feed？
• 没有Cache News Feed的用户：归并N个用户最近的100条Tweets，然后取出结果的前100条
• 有Cache News Feed的用户。归并N个用户的在某个时间戳之后的所有Tweets

2 解决push的缺陷
浪费更多的存储空间 Disk
• 与Pull模型将News Feed存在内存(Memory)中相比
• Push模型将News Feed存在硬盘(Disk)里完全不是个事儿
• Disk is cheap
• 不活跃用户 Inactive Users
• 粉丝排序 Rank followers by weight (for example, last login time)
• 粉丝数目 followers 远大于 关注数目 following
• 热点用户问题
• Trade off: Pull + Push vs Pull
正确的思路
• 尝试在现有的模型下做最小的改动来优化
• 比如多加几台用于做 Push 任务的机器，Problem Solved!
• 对长期的增长进行估计，并评估是否值得转换整个模型

Push 结合 Pull 的优化方案
• 普通的用户仍然 Push
• 将明星这类的用户，标记为明星用户
• 对于明星用户，不 Push 到用户的 News Feed 中
• 当用户需要的时候，来明星用户的 Timeline 里取，并合并到 News Feed 里

2更多功能设计
如何存储like

3特殊场景
维护
如果有一台服务器/数据库挂了怎么办
服务器数据库挂了，要考虑高可用，一般是数据冗余设计，分片
如果有流量暴增，如何扩展？

数据库承受不住压力
• 对于同一条数据短时间出现大量的请求
• 因为是同一条数据，所以什么load balancer，sharding，consistent hashing都不管用
• 解决方案：加上 Cache
• 点赞，转发，评论，都会修改这条 Tweet 的基本信息，如何更新？
• Keywords: write through, write back, look aside
• Cache 失效如何解决？
• 因为内存不够或者 Cache 决策错误，热点信息被踢出了 Cache，会发生什么？
• DB会瞬间收到一大波对该数据请求，然后就可以安心的挂了

• 解决方法：
• Facebook Lease Get（from Facebook Paper)

待完成。