大规模分布式存储那些底层原理和架构设计怎么回事，整体是咋搭起来的

根据谷歌发表的技术论文,The Google File System》，这是他们为了解决海量网页数据存储问题而设计的，它的核心思想很简单：既然一台机器的硬盘容易坏、容量也有限，那就把成千上万台普通的、便宜的电脑用网络连起来，让它们一起干活，当成一个巨大的硬盘来用。

这个架构里,主要有三个角色，第一个角色叫主服务器，它就相当于一个总指挥，它知道所有的文件被切成了多少块，每一块具体放在哪台机器上，但它自己并不存储实际的数据，只存储这些文件的“地图”，这样设计的好处是，主服务器的负担很轻，不容易成为瓶颈，第二个角色叫数据服务器，就是那些干体力活的工人，它们就是普通的电脑，上面插着很多块硬盘，实际的数据块就保存在它们这里，第三个角色就是客户端，比如一个网络应用，它想读或者写一个文件。

一个文件到底是怎么存进去的呢？根据这个设计，当客户端要存一个很大的文件时，主服务器会告诉它：“你这个文件太大了，我得把它切成很多个固定大小的块，比如64兆一块，然后我把这些块分散地放到很多台数据服务器上去。” 这就是分而治之的思想，把大文件切小，分别存放，这样读写时可以同时从很多服务器上操作，速度就快了，为了防止某一块数据因为硬盘坏了而丢失，系统会自动把每一块数据都复制成三个一模一样的副本，放在不同的数据服务器上，这就像重要文件复印了三份，分别放在三个不同的地方，这样即使一个地方失火了，另外两个地方还有备份，这个复制副本的过程，就是保证数据可靠性的关键。

再来看看读文件的过程,客户端想读一个文件，它先去问主服务器：“我要读这个文件，它的数据块都放在哪些机器上？”主服务器就把存放这些数据块的数据服务器地址列表告诉客户端，然后客户端就直接去找这些数据服务器要数据了，注意，这里很关键：数据是不经过主服务器转发的，客户端是直接和数据服务器通信，这样一来，主服务器这个总指挥就不会被大量的数据流量压垮，它只负责管理元信息，也就是“地图”，而真正的数据流是在客户端和数据服务器之间直接建立的通道，这就像你去一个大仓库取货，管理员只告诉你货在A区、B区，你自己去拿，而不是让管理员帮你把货搬出来。

写文件的过程稍微复杂一点,但原理类似，客户端也是先从主服务器那里拿到目标数据块的位置信息，它会把要写的数据推送到所有存有该数据副本的服务器上，这些服务器会排成一个链式顺序，数据先到第一个，第一个推给第二个，第二个推给第三个，这样能最有效地利用网络带宽，等所有服务器都确认收到数据后，客户端才发一个写命令，这些服务器才把数据正式写入硬盘，这个过程是为了保证所有副本的数据是完全一致的。

万一有机器坏掉了怎么办？这是分布式存储系统必须面对的核心问题，系统会不停地监控所有数据服务器的心跳，如果主服务器发现某台数据服务器在一段时间内没有回应，就判定它“死”了，这时候，主服务器就知道，原来放在这台坏机器上的那些数据块，它们的副本数量现在不够了（比如从三个变成了两个），主服务器就会立刻下令，从其他还活着的、拥有该数据块副本的服务器上，再复制一份到一台新的、正常的服务器上去，让副本数量恢复到三个，这样，数据就又安全了，同样，如果主服务器自己坏了怎么办？论文里也提到了，可以通过一个备用的主服务器，或者通过选举机制，再选出一个新的主服务器来接替工作，这个备用主服务器平时可能不干活，但它一直通过日志同步的方式，知道主服务器在做的一切，随时准备顶上去。

后来,根据类似的思想，又出现了很多其他的系统，比如Apache Hadoop项目中的HDFS，就是受到了谷歌这篇论文的启发，这些系统的核心思路都是一脉相承的：用大量普通机器组成集群、对文件进行分块、多副本备份、一个主节点管理元数据、数据节点负责实际存储、通过心跳检测和副本复制来容错，整个系统就是这样一层一层、一环扣一环地搭建起来的，目标就是在不可靠的硬件基础上，通过软件的方法，构建出一个高度可靠、可扩展的海量存储服务。