X扯闲篇
系统设计题目就是一个大坑 没有一个标准答案的意思就是面试官如果真跟你过不去随便挂人 跟玩儿似的。说答案的时候，总的来说，最注意把控的就是平衡细节的知识和大局的构架。什么意思？一，别有太多细节你自己说出来了你自己答不上，比如你说要用redis 结果redis数据放哪不知道。那就gg了。二， 别说一个细节说了十分多钟忘了之前到哪了。工程师就不能跟我一样，丢三落四的，就算你面试过了也一定做不了多好。勤看表不是问题，但是一定要有一个大概的感觉你每一个部分大概说多久，然后什么时候到哪了一定 一定 一定要有数。
结构 （我这四十几分钟要说什么）
有个培训机构叫太阁 他们用的方法是SNAKE 原则。啥意思啊？
Scenario - Necessary - Application - Kilobit - Evolve
先说哪里用得到，再说我们需要解决问题多大规模。然后说基本解里头Application里面都有啥，然后说说相对应的数据放哪里怎么放。最后这些都说完了（20-25分钟左右）来具体谈怎么让我的基本解在哪些方面做的更好。
还有个培训机构叫九章， 他们用的方法是4S原则，啥意思啊？
Scenario - Service - Storage - Scale
先说哪里用得到 要解决什么问题，然后说我们一个大系统对吧，怎么写出对应的micro services， 然后再说我们的数据放哪里怎么放，最后（也是20-25分钟后）说我们怎么样向上scale
这两个大家想明白了其实就是一回事。这俩都有版权 我都不能用，如果各位是随便过来看到的，也推荐大家两个都上一下 相辅相成很有用。
Scenario 场景
1. 问清楚自己要做哪些功能（也就是说，45分钟内不聊哪些功能）
2. 问清楚或者说清楚自己要handle多大用户量，面试官起码得给你确认这么几个信息，否则聊不下去。
- 一个是你平均每天handle多少用户
- 一个是你峰值（最多？不太精确但是形容一下）每天handle多少用户
3. 自己把自己要算的东西都算出来， QPS啊，存储size啊，不非得一口气全部算完，但是记住最基本的用户量，然后再说然后的。
Implementation 实现
4. 搭架子，我的系统要干嘛，为了做这件事情，我们需要什么组件，怎么安排。这里一切最简单，保证这个东西可以work，不要有明显的优化还不做。
5. 按照架子一个一个实现具体功能，如果发现有问题了，改改架子。记住。改架子的时候一定要想想别的东西动没动，动了，赶紧拿个纸记下来。数据放哪可以这里说可以分开说，这都不要紧。
6. 架子流程实现完了想想数据放哪里怎么放，那么些个数据库呢，好好挑挑。
Enhancement 提高
7.根据确认的问题或者优化点慢慢优化。这里的话，不懂就说不懂。为啥？基本分已经有了，大好局面来之不易，千万不要不懂装懂暴露问题。比如你之前说的都挺好，然后到优化了把load balancer放到dispatch service还要靠前端的地方，这不扯么？
具体结构怎么安排我等到自己练熟了以后我专门写一篇 我今天只写社交网络相关, 希望被我无耻强推连接的好友在评论里面多提意见，我也多改进。
场景 Scenario
上来我们第一个问题，没啥说的，
用户在twitter/facebook/weibo上面都干啥？
社交网络是吧，定义一下，是每个用户（人）对社交群体（人）的信息（帖子）分享。
人和帖子，俩基本点，所以说呢？
1. 好友关系，加好友，删好友， （改好友），查好友
2. 帖子关系，加帖子，删帖子，改帖子，查（谁的）帖子
具体点呢？
增删帖子
timeline (所有好友/单个好友的最近N个帖子。为啥N个？一屏放不下，数据发不完）
新闻（理解成厂家小编名义发送的帖子，是为新闻 news feed)
好友管理（增删改查，想到什么了没）
用户管理（登陆、注册、profile）
第二个问题，也没啥说的，
我需要考虑多大的数据量？
《=多大用户量以及用户都怎么用的？
具体下来是这么几个：
1. 日活用户多少啊？(How many daily active user(DAU) should I expect)
根据不完全调查，一般来说：
twitter： DAU 10M
facebook: DAU 1.2B
weibo: MAU 340M, DAU 11M
2. 每天每个用户要expect多少个新帖子啊，多少次阅读啊？(How many daily new posts/reads should I expect per user)
大坑预警： 不是直接问总共多少个，咱不是产品经理，问每人多少个
twitter/facebook/weibo: 20min *25 read/min = 500 reads per user per day. (亲测差不多) 5 writes per user per day（亲测比这个少，但是自己跟朋友平均下来，这个数字也靠谱)
3. 知道这几个数字了，能算QPS了不？
大坑预警：QPS的S是啥？DAU的D是啥？两者啥关系？
一天多少秒？24*60*60 = 86400秒
就先拿weibo来算好了，中国人关注中国企业
Read QPS: 500 * 11,000,000/ 86,400 .= 70K
Write QPS: 5 *11,000,000/86,400 = 700 QPS
啥概念？咱一会儿说 别忘了哈！
实现 Implementation
来 先画图
我的架子怎么搭？
关键点是？ 人和帖子？
人需要几个service？ 好友管理和用户登陆
帖子需要几个service？帖子管理和大文件存储
所以一共？四个service
User service
每个用户的基本资料
注册 登陆
Posting Service
每个帖子的内容和资料
大坑预警：可别在这里放图片/文件/视频哈，说挂立刻就挂！！ 那要放放哪？attachment service 能让别人打架绝不自己动手：）
Friendship Service
放每个用户的好友关系
facebook 你是我好友 我肯定是你好友 双向保存也可以，单向保存也可以
twitter/weibo不一定哦 分关注和被关注，这里到底是保存关注，保存被关注，还是都需要保存，就看具体实现了，设计的时候要有意识
Attachment service 统一存放所有的大文件（图片，视频，pdf 等）
如果多个人有同一个文件 正好！
下一个问题：
数据怎么放？
首先 基本概念，每个service考虑自己的就行。
为啥？做成SOA(Service Oriented Architecture) 不就是为了每个service可以自己做事情么 而且每个service的数据存储模式是不一样的。既然不一样，那就分开放。
下一个问题： 那你倒是放呀？
好好 不着急不着急。。。
User Info: 读远大于写，经典的SQL应用。
Post Info: 内容不定，读写频繁，除时间外无法排序，适合NoSQL
Attachment Info: 大文件 这就没啥可说的，只能放在文件系统里面。
Friendship info: 关系确定（好友呗，最多再分一个类），有时排序，读远大于写。这个就不好说了。你想存SQL也行，你想存NoSQL也行。
关于这几个数据库之间的关系，什么时候该用哪一个。我就将来另写一篇文章说这个问题了。感觉谁都会用到的。
下一个问题： 该有的有了 该存的存了，
流程啥样？
用户注册：没啥可说的，user table里加一个entry
用户注销： 别愣着直接删，标记不活跃就可以了
用户登陆：关键字，不要原样传输密码，不要原样储存密码
发帖：发帖。。。
讲究就大了
单纯发帖好说，post table里面加一个entry。如果有大文件，entry里面自动添加链接，attachment table里面加一个节点或者重用已有文件。
可是我要怎么让关注我的人（不管是单向的还是双向的知道我发帖了呢）?
首先 要想到有两种做法（想到一种不是你的错，但是认为没有别的路就是你要准备好被挂了）
1. Push model: 用户发帖以后更新自己的记录以外，遍历所有follow自己的人，把这条帖子推送给他们对应的user service。user service 保存推送来的消息，用户显示朋友圈的时候，在接收到的消息里面选取topK个显示。
2. Pull model: 用户发帖以后更新自己的记录。用户显示朋友圈的时候，把遍历所有自己follow的人拿topN个显示（N和K的关系可以另外算），截取topK个显示。
所有培训机构的图都是有版权的不能用。我给大家放一个不完全准确的图。简单说，这里面都有一个遍历关系。
push：遍历所有follow自己的人，每个人推送自己的更新
pull：遍历所有自己follow的人，每次显示朋友圈的时候询问更新
那我要怎么选择呢？上课都会讲怎么选择的，我们先从各自的优缺点开始。
push：如果follow自己的人不多，省！
pull：如果自己follow的人不多，省！
push：如果自己follow的人不都活跃，省！
pull：如果follow自己的人不都活跃，省！
push：会带来一个特定的问题，叫做惊群效应 就是如果今天王宝强发了一个帖子，我的天爷，大家是不是纷纷点赞纷纷转发纷纷评论，这个如果用push的话，fanout结束怎么也得好几个小时吧？
这个问题为啥难，因为所有的人修改的都是同一个帖子。什么caching，sharding，根本都不管用。我贴的链接不是关于网络系统设计的，是关于计算机系统设计的。这个问题不分软件固件，大家都能碰到。解决的办法说起来也只有慢慢fanout了，只要在用户的视角里面显示自己评论就可以了。
pull：这个问题就不是特定了，为啥，因为王宝强少，看王宝强的人多。不论已婚与否，我们今天基本上男性劳苦大众都是关注的人比被关注的多。所以我们的问题就现打不赊着，如果不做任何优化，我们每次更新都要很慢，因为每次看朋友圈都要二重循环
以上是基本解的实现。说了这么多，我想我都累了。面试官应该不会挂了吧（有问题指出来，要不我还是得挂！）。接下来就要说说一些相对比较高级的功能了。
提高 Enhancement
我自己这个破记性 能够把基本点记下来就不容易了，接下来你说要提高，那我们从提高开始，要记住什么要点呢？
就从奥林匹克精神开始吧。更高咱先不说，先说后面两个
更快：前面分析完了并发性 现在可以开始说说速度了，怎么样更快得到结果，让前端尽可能的不要等？
更强：就是面对可能出现的各种问题是否有更好的准备和更好的解决办法。
接下来我们就一个一个说我这里可能会想到的问题。
我们先说更快，因为基本解来说，更快还是相对比较容易做到的。
我们之前在基本解说了这么多，我们自己每天也都在用社交网络，我们要优化东西，就要牺牲东西。可以牺牲的东西一定是我们不太看重，或者不太感觉得到的东西，对吧？那么我们什么可以牺牲？什么不那么重要？
答案：实时性（Real-time-ness)
为啥？你今天分析你一个交恶的原密友发的不利于你的消息。你就关心他消息是什么时候发出来的，对不对？什么时候到你这里的，只要别太慢，你自己也没感觉，对吧？
所以，只要保证时序性（最先发出来的帖子，最后在用户这里显示是显示在前面的），可以允许有些消息先显示出来，然后等到别人的消息来了再整理就好了。
这样，对于pull来说，就有一个特别好的消息了。 我可以用缓存了。
我先把缓存里面的信息先放出来，然后有消息来了我一点一点加进去（大家用微信看消息是不是就是这个感觉？消息在一点一点的更新？这就是pull+cache的用户体验）
那push呢？
王宝强级别的明星必须用pull，没说的。否则没有别的任何招数。普通人可以用push，反正不伤。
那是吧，我们结合一下，如果明星用pull，普通人用push，是不是就两全其美了呢？
不能说不是，但是会带来新的问题。叫摇摆效应。啥叫摇摆效应？
比如说吧，咱划个线，粉丝一万以上叫明星，一万以下叫普通人
要是有人本来10001个粉丝，今天掉了两个粉，我怎么办？如果明天又涨回来两个粉，我又怎么办？
后台可以在这俩之间切来切去，但是这样不是要反复通知上下游的其他service吗？
解决这个问题的办法来说，比较容易想到的就是设置一个过渡期，先默认是明星，如果普通人变成了明星，立刻改，如果明星变成了普通人，等待一段时间。
下一个问题，取关怎么处理？
还是那句话，你取关谁你看不见就行！
所以我们就可以异步操作，先立刻删除缓存，在本机禁止显示关于被取关好友的消息，然后再异步发送给服务器来删除服务器上的好友记录。
下一个话题， 更强， 也就是不能有东西挂掉
单点failure怎么办？（有一台数据中心或者服务器down了）
一，数据要复制，一份数据不能只放在一个地方(replica)
二，数据要分散，不能所有的数据只放在一个地方(sharding)
如何识别虚假用户？
一，用户举报机制
二，这是一个典型的supervised learning/classification， 用machine learning辅助判断
然后今天就先说道这里。就像开头说的，系统设计想挂人还不容易，稍微在他进行的时候打断他两下问他两个细节，很多人就都不行了。所以。一定要记住大框架，然后时刻记住自己说道哪里了。
网友评论