摘要：性能 - > sharding->错误 - >容错 - >复制 - >不一致 - >组成 - >低穿孔
您可以建立一个高性能的系统，但是不可避免地会陷入这里的周期。实际上，如果您想要良好的一致性，则必须支付相应的价格。如果您不想付出代价，您必须忍受一些不确定的行为。
我们将在稍后在许多系统中看到此处引入的周期。从总体上讲，人们很少支付良好的一致性来支付相应的性能成本（即忍受某些不一致的行为）。
例如，有两个服务器，每个服务器都有一个完整的数据副本。它们都在磁盘上存储了一个键值。我希望这两种表单完全一致。这样，一台服务器是错误的，我们可以切换到另一台服务器进行读写。
这两种表单完全意味着每个写作请求必须在两个服务器上执行（因为我们想更新两个服务器上的数据），并且仅在一台服务器上执行读取请求，否则不会有容忍度为了容忍。性质（因为您阅读了请求，需要从两个服务器中读取数据，那么我们无法在服务器故障中提供服务）。
现在，问题出现了，假设客户端C1和C2想要执行写作请求，则必须将其中一个写入x至1，而另一个则将x写入2.c1，将发送一个请求，将请求发送给写作x作为1两台服务器和C2也将将书面X的请求发送为2至两个服务器。
这里会发生什么错误？我们没有做任何事情以确保两个服务器按照相同的顺序处理这两个请求：如果服务器1（S1）首先处理C1请求，则以其形式为单位，x是1，并且然后，S1从C2中看到了C2，请求将覆盖您的表格为2；但是，如果S2仅以不同的顺序接收客户端请求，则S2将首先执行C2请求，将X设置为2，然后接收C1请求。SET.SETX到1。
之后，如果其他一些客户端假设C3读取来自S1和C4的数据读取来自S2的数据，那么我们将面临一个可怕的场景：读取这两个客户端的数据是不同的。
这里的问题可以通过另一种方式暴露。我们试图修复上述问题。当我们让客户端仅读取S1的数据时，S1不在网上，然后从S2.中读取数据，所有客户端都会读取x以获取2. 2.但是，如果S1失败，尽管请求不是将其写入x为1，客户端读取的数据x将从2更改为1。由于S1失败后，所有客户端将切换到S2以读取数据。
当然，这里的问题可以修复。维修需要服务器之间的更多沟通，并且复杂性也将得到改善。由于获得强大的一致性将带来不可避免的复杂性改善，因此有很多方法可以在良好的一致性和一些小缺陷之间达到平衡。
Google有大量数据，需要大量磁盘存储这些数据，并且您需要使用MapReduce之类的工具来快速处理这些数据。因此，Google需要能够快速访问这些大量数据。
Google的目标是构建一个大型快速文件系统，并且此文件系统具有全局和有效，以便各种应用程序可以从中读取数据。
为了获得大容量和高速度特征，每个包含数据的文件都会通过碎片自动存储在多个服务器上，这自然会变得快速。获得更高的polychia.file存储还可以节省大于存储系统中单个磁盘的文件。
因为我们现在正在建造数百台服务器上方的存储系统，所以我们希望自动维修。我们不希望每次都会发生故障，请将某人发送到机床维修服务器或迁移数据。我们希望该系统可以自动修理自己。
GFS旨在仅在一个数据中心运行，并且不能保存世界各地的副本。单个GFS存在于单个数据中心的单个计算机室中。在理论上，应将多个数据副本彼此分开，但很难实现，因此GFS仅限于数据中心。
GFS不适合普通用户。这是Google中用于应用Google工程师编写应用程序的系统。因此，Google不出售GFS，它可能会出售基于GFS的服务，但GFS并不直接面对普通用户。
GFS在各个方面都定制了大规模文件的读取和写作。
它描述了一个真正运行数百台计算机的系统，该系统远远超过了学术界建立的系统，并且由于GFS在行业中使用，因此反映了现实世界的体验。例如，对于系统，如何正常工作以及如何节省成本，这些内容也非常有价值。
论文当时还提出了一个非常不同的观点：存储系统薄弱且一致。在那个时候，学术界的概念认为存储系统应该具有良好的行为。如果一个构建错误数据的系统是什么意义？为什么不直接构建可以返回正确数据的系统？GFS不保证返回正确的数据。就这一点而言，GFS的目标是提供更好的性能。
在某些学术论文中，您可能会看到一些耐受性，多副本和多个主节点，这些节点会自动修复，但是GFS声称使用单个主节点并可以很好地工作。
单个主节点，多个块服务器，多个客户端
主节点用于管理文件和块信息，块服务器用于存储实际数据。这是GFS设计中更好的一面。它几乎与这两种数据类型的管理问题完全分开。这两个问题可以通过独立设计解决。
它们存储在主人的记忆中。
除了存储在主中的内存外，磁盘上还需要存在一些数据，而有些数据则不使用。它们分别是：分别：
如果应用程序发出的书面请求太大或跨越多个块，则GFS的客户端代码将分为多个写操作。拆分书面请求是根据上面的控制流执行的，但可能有些情况下与其他客户的并发请求的并发请求可以由其他客户的并发请求涵盖或涵盖。
因此，共享文件区域最终可能包括来自不同客户端的片段。一致但不确定的状态。
主执行所有命名空间操作。
Master还管理整个系统中的Chunk的副本：做出安置决策，创建新的块和副本，协调各种活动系统以维护块副本完全复制，平衡所有块Server负载并回收未使用的存储。
主人的许多操作可能会消耗很长时间，例如：快照操作必须恢复所涉及的块的Chunkserver的租赁。执行这些操作后，我们不想推迟Master的其他操作。因此，我们允许，我们允许同时进行多个操作的操作，并使用命名空间的区域锁定机制来确保操作的正确执行。
GFS从逻辑上使用完整的路径名来表示元数据的查找表来表示名称space。通过前缀压缩技术，可以在内存中有效地表达此搜索表。在命名树上的east节点（也许是文件或文件的绝对路径名称或目录的绝对路径名）具有读写锁。
在大师的每次操作之前，都会请求一系列锁。通常，如果主的操作包含命名空间/d1/d2 /.../ dn/leaf，则主人将在目录/d1上请求锁/d1/d2，/d1/d2/dn和theand要求在完整的路径名/d1/d2/leaf上读取或写作锁。它们可以根据执行的操作，叶子可能是文件或目录。
示例：说明当将锁定机制拍摄到/保存/用户，并创建/home/user/foo时，请说明如何创建锁定机制。
快照操作将写入/家庭和/保存的锁定，并在/home/home/user和/save/user上要求锁定。
文件创建操作需要读取/home/home/user/foo on/home/home/user/foo on/home/home/user。
因为他们试图在/家庭/用户上发生冲突，所以可以串行执行这两个操作。由于GFS或Inode之类的数据结构中没有目录数据结果，因此在修改过程中没有必要保护它，因此没有需要在需要文件创建操作时获得其父目录的写作锁定。父亲目录上的读锁足以保护父亲的目录，而不会被删除。
这种锁定机制提供了非常好的性质：允许在同一目录中并行更改。创建文件的书面锁定。目录名称上的读取锁足以防止其删除，重命名或快照。文件名上的写作锁可以防止同一名称的相同名称被创建两次。
由于命名空间可能包含很多节点，因此在使用过程中会懒惰的lod锁对象，并且一旦不再使用，它将被删除。此外，为了防止死锁，锁的获取始终是相同的：名称太空树中的层次结构中的第一个排序，并在同一级别内按字典的顺序排序。
GFS群集高度分布在多个级别上。GFS通常有数百个块状服务器。这些块服务器可以由数百个客户从相同或不同的机架访问。不同机架上两台机器的通信可能跨越一个或多个switches.in.in此外，机架的进入和出口带宽可能小于此机架上所有机器的进入和出口带宽的总和。Multi -Level分配给数据的弹性，可靠性和可用性带来了独特的挑战。
块复制分发策略有两个目标：最大化数据可靠性和可用性，并最大程度地利用网络带宽。对于这两个目标，不足以将副本散布在所有机器上。这仅保证公差磁盘或机器故障，并且仅使用每台机器的网络带宽。我们必须在框架之间分散块的副本。这可以确保当整个机架被损坏或离线时（例如，由共享资源问题，例如开关和电源电路），块的某些副本仍然存在并保持使用状态。此外，这还使流量（尤其是阅读流量）充分利用另一方面，编写流量必须流过多个机架，这是我们资源取得的平衡。
创建块可能是由三个原因引起的：创建，重复复制和重大。
当创建创建一个块时，它将选择初始空气副本的位置。选择位置的选择将指许多因素：（1）我们希望在较低磁盘的平均磁盘利用率上放置副本。时间，这将平衡块块服务器之间的磁盘利用率（2）我们希望限制最近在每个块的块上创建的块数量。尽管块本身很小，但它是在写作时写成的，是在写作时创建的，我们一次性添加的负载（附录读）的负载，通常只有在写作完成后才阅读。因此，主人还将可靠地预测即将到来的大量写作流。（3）以上讨论，我们希望分散块的复制跨度。
重新复制零件的副本数量小于用户设定的目标值时，主人将重新制作副本。可能有许多原因减少块副本的数量，例如：chunkserver可能会变得不可用，Chunkserver报告了其副本损坏，由于错误或目标副本的数量增加，Chunkserver的磁盘变得不可用。
每个需要复制的块都将指某些因素并在优先级中进行排序。这些因素之一是块副本数量和目标副本之间的差异。副本而不是仅丢失一本副本。此外，我们更倾向于复制仍然是首选的文件的一部分，而不是最新删除的文件的优先级。最后，为了最大程度地减少应用程序的影响运行，我们增加了阻止客户端流程的所有块的优先级。
主人选择最高优先级块，然后直接从存在和法律副本直接命令块制品以克隆块。新副本位置的选择与创建新块时选择的目标相似：克隆操作的数量仅限于使用空间空间空间，限制单个块的克隆操作的数量，并在机架之间分散副本。为了防止克隆操作的流量从客户端流量的情况下，主服务器需要为了限制整个集群中克隆操作的数量以及每个块服务器活动上的克隆操作数量。此外，在克隆操作中，每个块的人还限制了源块服务器的读取请求，以限制每个克隆占用的总带宽手术。
重新平衡的主人将每隔一次与副本均衡：主人将检测当前的副本分布并移动复制位置以使磁盘空间和加载更加平衡。例如，在此过程中，主人将逐渐填充新的块，而无需立即填写。从新的块编写的高负载压碎了新的块服务器。新副本放置位置的选择方法与我们上面讨论的相似。此外，主人必须删除现有的副本。总体，主人选择删除副本的副本平均块块以下的空闲磁盘空间平衡磁盘空间的使用。
删除文件后，GFS将不会立即恢复可用的物理存储空间。Master仅在定期执行Lazy垃圾回收过程中回收物理存储空间。其中，垃圾回收分为文件级别的垃圾回收和块 - 级垃圾回收。我们发现此方法可以使系统更容易可靠。
当应用程序删除文件时，主会立即将删除操作写入日志。主扫描文件系统周期性的名称空间，它用超过三天的时间删除此隐藏的文件（用户可以配置此间隔时间）。在完全删除文件之前，在此之前，它仍然可以通过特殊的新文件名来访问该文件。该文件被重命名。还可以通过正常文件将其删除并通过重命名删除。当隐藏的文件从名称空间中删除时，也可以删除其内存中的元数据。该方法可以有效地切断指向文件及其相应块的链接。
类似于上面介绍的文件级垃圾回收。当大块的垃圾回收利用时，主人会定期扫描块命名空间并找出孤儿块（例如，块状块）（例如，任何文件无法访问），也可以使用。Chunkserver会定期与主人交换，将报告其拥有的块子集，主体将回复这些块数据的块徽标。Chunkserver可以自由删除这些元数据的副本。
原始：https：//juejin.cn/post/7097118657154809864