关于Google的典型编码面试的内容，有很多帖子。 但是，尽管没有得到广泛的描述和讨论，但也经常有系统设计访谈。 对于SRE职位，它是NALSD：非抽象的大型系统设计。 SWE和SRE访谈之间的主要区别在于这两个字母：NA。
那么，有什么区别呢？ 如何为这次面试做准备？ 让我们保持抽象，并举一个例子。 为了更加简洁，让我们从物质世界中获取一些信息，这样在真正的采访中（至少在Google采访中不会）您不会被问到完全相同的事情：）
因此，让我们设计一个公共图书馆系统。 对于纸质书籍，就像您到处看到的一样。 下面的全文大约在一小时内一次写完，以粗略地向您展示面试中您应该涵盖/触摸的领域。 请原谅我的混乱（这就是我的想法）。
NALSD采访：设计公共图书馆系统。
首先，我们通过向访调员提问或通过做出合理的猜测（不要忘记大声说出来）来收集负荷特征。 由于访谈涉及可扩展系统，因此我们期望一个人口众多的城市（例如1M +）。 我们有几种选择：一栋巨大的建筑，或本地图书馆加存储。 我认为后者更为合理，因为它还使我们能够将该系统扩展到多个城市。
现在，让我们集中讨论单个城市的系统； 我们应该能够再次应用相同的设计（稍作修改）以将其扩展到国家/地区级别。 因此，我们有一个人口超过1M的城市。 为了简化计算，让我们四舍五入到100万可能的读者。 每个读者都希望在任意时间读取彼此独立的东西。 因此，我们可以将读者流建模为泊松过程。 在面试期间，正确地进行数学运算有点困难，所以让我们再简化一次，只说大约每天可能有1％的读者来读书。 因此，假设每天有10,000本图书请求。
因此，我们的任务变成了：提供在每天100万以上的城市中每天分发10000本书的能力（这也意味着，我们有必要在一天后收回这些10000本书）。 此估计表明，单栋建筑解决方案将不可行（要为100万以上的人口提供图书，我们的图书馆应在合理的时间内到达，否则他们取书的意愿将因交通拥堵而超时）。 因此，让我们尝试猜测我们必须构建的本地库的合理大小。 绝对正确的估算将涉及人口密度，可达性等待时间等，但是由于这不会影响整体设计，因此我们可以通过考虑相似单位的均匀分布来再次简化该估算。 我们仍然不知道单位应该有多大；例如，我们可以在全市分布10000个图书馆，每个图书馆有1本书，但这显然行不通。 下一层。
单个本地图书馆单位。 为了使它有用，大多数访问者应该能够找到他们想要的书。 这意味着我们需要跟踪使用情况并预测最受欢迎的请求的需求，以便为它们提供服务。 另外，我们应该有很多不受欢迎的商品。 我的粗略猜测是图书馆的书名少于1000个，其中最受欢迎的书有数十本，书尾的有单本。 在我们的图书馆中阅读书籍的平均时间为3天到2周（当然，实际时间取决于书籍本身，在实际情况下，这需要进行额外的分析）； 我们估计每本书1周。 这意味着发放的一本书将在1周内归还，因此我们应该为1周提供顶级书籍（一周后从退货中补充）。
假设平均爆炸系数为6，这将使我们的单位存储容量为6000本书。 较少的存储量将意味着最受欢迎的名称短缺（嗯，较小的单元仍然有用-例如带有“ Twilight”的小型Mall Kiosk，但现在就将其保留在我们的设计范围之外）。
在稳定状态下，每天的收益和借款几乎相似（有些分散），但我们还应计划最高收益（可能是外部同步事件：假期，趋势等）。 正确的方法是建立并运行统计模型。 但是现在，让我们保留⅓作为缓冲区。 这意味着我们应该准备6000本书以备分发，再加上2000的空间。
总结一下：我们需要一个可存储8000本书的图书馆单位。 预计每天补货会很昂贵，因此我们应该预期一两个星期就足够了。 两周内，有6000本书，可能会有回报偏差，每天大约300本书。 在开幕当天，我们可以填满整个存储库（8000本书），以使最初的2000本书的交易量增加。 3天= 2000 =每天600本书，倾斜缓冲区=每天800本书。
让我们估计吞吐量和存储限制。 1本书大约2线性厘米的空间，即8000本书= 160米。 我们可以将其垂直折叠4次，所以它是40线性米。 如果将其分成约5米的机架，则将得到8个机架，每个机架有4个架子，每个架子长5米。 一名图书管理员（或机器人图书管理员）应该能够使用两个机架。 提取一本书的时间：走到书架上需要5秒钟，抓取/放书到位需要5秒钟，后退需要5秒钟（总共15秒钟）。 4位馆员将为我们提供每分钟15本书的峰值吞吐量。 因此，每小时最多可处理900本书。
如果我们还考虑了请求处理时间（10s），搜索时间（5s），跟踪系统的时间（2s），我们将获得400本书/小时的高峰。 因此，我们应该能够在2小时内处理每天800本书的估计。
让我们来计算其他方面：为了能够由4位馆员每小时分发400本书，我们需要有足够的空间容纳100人排队等候，而入口门应允许400个人/小时双向走动。 这意味着我们的主要限制将是等候空间和建筑物门。
这意味着在对实际设计进行适当的计算期间，我们应该能够找到存储空间和等待区域之间的最佳平衡。
就此级别而言，就该继续了。 我们估计整个图书馆网络需求为10000本书/天。 1单位是800本书/天，所以我们需要12.5单位。 如果我们进行统一的地理分布，则每个读者的范围应在1-2个单位（在城市边界上）和3-4个单位（在城市内）之间。 这样一来，就可以使峰值略微平滑和/或弥补顶级书籍的不足。
我们还知道，每个图书馆都可以随时关闭（火灾，检查，冰箱门把手重新粉刷等），而且我们拥有的单位越多，发生这些事件的可能性就越高。 因此，每5-6个单位需要1个冗余单位。 因此，如果我们要维持每个单元内所需的供给，则总共需要15个单元才能满足我们的城市需求。
正如我们早先已经考虑过的那样，我们需要每周或每两周补充一次存储空间（之前我们猜过两次）-大约有一半的存储空间应该更换，以适应趋势等。 因此，新交付了4000本书，从中删除了4000本书。 每次补货时，我们需要提取4000本书，然后再插入4000新条目。 凭借我们400本书/小时的吞吐量，一次补货将是10个非常小时。 好吧，这似乎还是可以的，特别是因为批量操作通常更便宜； 但无论如何-我们应该记住，补货操作的成本是服务成本的5倍。
一本普通的书（2厘米* 20厘米* 30厘米）的容积为1.5升，因此4000本书= 6立方米。 这应该适合一辆普通的轻型货车。 1立方米的纸张重量600kg，6m ^ 3 = 3.6吨。 一辆普通的轻型货车能够处理约1.5吨的货物，因此我们需要其中的3辆。 再加上一个冗余。 我们的15个图书馆单元每2周刷新一次，这意味着时间表很紧张，因此我们还需要一辆车。
而且我们仍然没有想到这些汽车如何以及从何处移动书籍，因此我们的设计也将需要供应商仓库和垃圾收集点以不再使用流行的书籍...
时间到了。 那么，NALSD问题有什么特别之处？ 任何大型系统设计都具有可扩展性。 但是在NALSD采访中，必须
具体 。
您可以在上面看到很多猜测和假设，但是所有计算都是基于先前得出的数字。 我也试图解释如何获得正确的数字，但是很容易感到厌倦/无聊，并开始想念它。 同样，很容易从内存中保留一些数字，而没有提供其原因的很好解释。但是由于设计非常具体，如果您对任何数字输入有误，都可以更改数字并重新计算其余数字。
我仍然记得在NALSD面试中我如何将单个HDD的IOPS保持为600，只是因为我最近在优化某些RAID阵列，整个阵列的600 IOPS……面试官有些惊讶：每人600 IOPS开车？ ：D在面试过程中，面试官可以纠正您的任何假设和猜测。 另外，面试官可以添加一些其他限制（您忘记，不知道，不询问或只是调整任务，因为他们希望或认为这是更好的继续方法）。 由于您仅对特定数字进行运算，因此仅需要按照已经给出的公式对数字进行少量更新。
如果假设的校正需要对系统进行全面的重新设计，则可能是设计错误，或者是不正确的校正，或者新的假设使我们超出了设计的适用范围（并且在现实生活中并不罕见）。 重要的是不要错过这个事实：在设计过程中和进行任何校正之后，您都应验证所获得的数字，以确保它们是现实的。
作为SRE，我们必须考虑在实际硬件限制的约束下，实际系统的可伸缩性。 可能有一种漂亮的
算法可以将大量的时间复杂度交换给一定数量的RAM ...但是，如今，我们不能构建每1个CPU 1PiB的RAM。 因此，如果我们有1个PiB RAM，那么我们也将有大约1万个CPU。 或20k。 甚至30k。 这意味着我们应该专注于现实中今天可以达到的真实（局部）最优，而不是理想条件下可以达到的全局最优。
您不应该记住精确的数字，但是应该能够运用经验法则来获得数量级。 就像IOPSes：HDD大约是100s，SSD大约是10万。 但是这十万个硬盘在HDD和SSD之间的价格差异为1：3或1：4。 它还忽略了周围的所有内容：机架空间，驱动器的刀片，网络端口以及其他所有东西，一旦您在Peta和Exa级工作，它们将不再便宜。
现在，坐在椅子上放松一下，放松一下，尝试设计一个订阅系统，用于新鲜鸡蛋的生长和传送系统。