系统设计面试的行家指南（下）（3）-阿里云开发者社区

通知服务

为了保持文件的一致性，在本地执行的文件的任何变化都需要通知其他客户端以减少冲突。通知服务就是为此而构建的。在高层次上，通知服务允许在事件发生时将数据传输到客户端。下面是几个选项：

长轮询。Dropbox 使用长轮询[10]。

网络插座。WebSocket 提供了客户端和服务器之间的持久连接。交流是双向的。

尽管这两个选项都工作得很好，但我们选择长轮询有以下两个原因：

通知服务的通信不是双向的。服务器向客户端发送有关文件更改的信息，但反之亦然。

web socket 适用于实时双向交流，比如聊天应用。对于 Google Drive，通知很少发送，没有数据突发。

使用长轮询，每个客户端建立一个到通知服务的长轮询连接。如果检测到对文件的更改，客户端将关闭长轮询连接。关闭连接意味着客户端必须连接到元数据服务器才能下载最新的更改。收到响应或连接超时后，客户端会立即发送新的请求来保持连接打开。

节省存储空间

为了支持文件版本历史并确保可靠性，同一文件的多个版本存储在多个数据中心。频繁备份所有文件修订会很快填满存储空间。提出了三种技术来降低存储成本：

删除重复数据块。在帐户级别消除冗余块是节省空间的简单方法。如果两个块具有相同的哈希值，则它们是相同的。

采用智能数据备份策略。可以应用两种优化策略：

设置限制：我们可以设置存储版本数量的限制。如果达到限制，旧版本将被新版本替换。

只保留有价值的版本：有些文件可能会经常编辑。例如，为大量修改的文档保存每个编辑过的版本可能意味着该文件在短时间内被保存 1000 次以上。为了避免不必要的拷贝，我们可以限制保存版本的数量。我们更重视最近的版本。实验有助于找出要保存的最佳版本数量。

将不常用的数据移动到冷存储。冷数据是几个月或几年没有活动的数据。像亚马逊S3冰川[11]这样的冷库比S3便宜多了。

故障处理

大规模系统中会出现故障，我们必须采用设计策略来解决这些故障。你的面试官可能有兴趣听听你是如何处理以下系统故障的：

负载均衡器故障：如果一个负载均衡器出现故障，辅助负载均衡器将变为活动状态，并接管流量。负载平衡器通常使用心跳来相互监控，心跳是负载平衡器之间发送的周期性信号。如果负载平衡器在一段时间内没有发送心跳信号，则被视为失败。

块服务器故障：如果一个块服务器发生故障，其他服务器会接管未完成或未完成的任务。

云存储失败：S3桶在不同地区多次复制。如果文件在一个区域不可用，可以从不同的区域获取。

API 服务器故障：是无状态服务。如果一个 API 服务器出现故障，负载均衡器会将流量重定向到其他 API 服务器。

元数据缓存故障：元数据缓存服务器被多次复制。如果一个节点出现故障，您仍然可以访问其他节点来获取数据。我们将启用一个新的缓存服务器来替换出现故障的服务器。

元数据数据库故障。

主节点关闭：如果主节点关闭，提升其中一个从节点作为新的主节点，并启动新的从节点。

从服务器宕机：如果一个从服务器宕机，您可以使用另一个从服务器进行读取操作，并使用另一个数据库服务器来替换出现故障的服务器。

通知服务失败：每个在线用户与通知服务器保持长时间的轮询连接。因此，每个通知服务器都与许多用户连接。根据 Dropbox 2012 年的报告[6]，每台机器上有超过 100 万个连接处于打开状态。如果服务器关闭，所有长轮询连接都将丢失，因此客户端必须重新连接到不同的服务器。即使一台服务器可以保持许多打开的连接，它也不能一次重新连接所有丢失的连接。与所有丢失的客户重新联系是一个相对缓慢的过程。

离线备份队列失败：队列被多次复制。如果一个队列失败，该队列的使用者可能需要重新订阅备份队列。

第四步——总结

在本章中，我们提出了一个支持 Google Drive 的系统设计。强一致性、低网络带宽和快速同步的结合使设计变得有趣。我们的设计包含两个流程：管理文件元数据和文件同步。通知服务是系统的另一个重要组成部分。它使用长轮询来使客户端及时了解文件更改。

和任何系统设计面试问题一样，没有完美的解决方案。每个公司都有其独特的限制，你必须设计一个系统来适应这些限制。了解设计和技术选择的权衡非常重要。如果还有几分钟，你们可以谈谈不同的设计选择。

例如，我们可以从客户端直接将文件上传到云存储，而不是通过块服务器。这种方法的优点是它使文件上传更快，因为文件只需要传输一次到云存储。在我们的设计中，文件首先传输到块服务器，然后传输到云存储。然而，新方法有一些缺点：

首先，必须在不同的平台(iOS、Android、Web)上实现相同的分块、压缩、加密逻辑。它容易出错，需要大量的工程工作。在我们的设计中，所有这些逻辑都在一个集中的地方实现：块服务器。

其次，由于客户端很容易被黑客攻击或操纵，在客户端实现加密逻辑并不理想。

系统的另一个有趣的发展是将在线/离线逻辑转移到一个独立的服务中。让我们称之为现场服务。通过将在线服务移出通知服务器，在线/离线功能可以很容易地被其他服务集成。

祝贺你走到这一步！现在给自己一个鼓励。干得好！

参考资料

[1] Google Drive: https://www.google.com/drive/
[2] Upload file data: https://developers.google.com/drive/api/v2/manage-uploads
[3] Amazon S3: https://aws.amazon.com/s3
[4] Differential Synchronization https://neil.fraser.name/writing/sync/
[5] Differential Synchronization youtube talk https://www.youtube.com/watch?v=S2Hp_1jqpY8
[6] How We’ve Scaled Dropbox: https://youtu.be/PE4gwstWhmc
[7] Tridgell, A., & Mackerras, P. (1996). The rsync algorithm.
[8] Librsync. (n.d.). Retrieved April 18, 2015, from https://github.com/librsync/librsync
[9] ACID:  https://en.wikipedia.org/wiki/ACID
[10] Dropbox security white paper: https://www.dropbox.com/static/business/resources/Security_Whitepaper.pdf
[11] Amazon S3 Glacier: https://aws.amazon.com/glacier