Google三驾马车——GFS、MapReduce、Bigtable



1、GFS

GFS的一些假设：

系统由许多廉价的普通组件组成，组件失效是一种常态。

统的工作负载主要由两种读操作组成：大规模的流式读取和小规模的随机读取。

系统的工作负载还包括许多大规模的、顺序的、数据追加方式的写操作。

高性能的稳定网络带宽远比低延迟重要。

GFS架构：

租约保证replica数据一致性：

注意，数据量超过一个chunk，会再生成一个chunk；如果中间有某个chunk server没成功写入，其他成功那个写入的server还是要重新写一下数据。【尽管会有重复，但是保证了至少一次所有的server都是atomic unit的】，后续的操作操作只要在更高的偏移量上进行就可以了。

数据副本不仅要放在同一机架的不同机器上，还要在不同机架的机器上放置一份副本。这样可以防止整个机架的失效。。。

注意，使用校验和来保证数据一致性。但绝对不能简单的通过比较不同副本是否一样来判断数据是否失效，这种比较首先不简单，需要耗费大量的资源，更重要的是，GFS的追加操作并不保证“副本字节级完全一致”，只是保证至少一次原子操作！！所以，每个Chunkserver必须通过维护检验和来独立地验证自己副本的完整性！！

2、MR