Spanner由谷歌2012年的论文《Spanner: Google’s Globally-Distributed Database》提出，是谷歌的一个全球级别的分布式数据库。它管理着全球成百上千个数据中心，数百万个服务器，将数万亿数据分片存储到这些服务器上。同时，它支持以下特性：
支持高可用（数据的备份和恢复）。数据可以有多个备份副本，并且可以灵活、细粒度地配置：副本数量、副本所在的数据中心等。副本甚至可以跨国家存储，即使面临大范围自然灾害，数据依旧可用。
同时，Spanner保证这些副本的外部一致性（谷歌创造出来的一种一致性）。
支持广域的分布式事务，对于涉及不同数据中心的事务，也能保证ACID特性。
Spanner如何保证这些特性呢？具体内容请看下文。
《Frangipani: A Scalable Distributed File System》是1997年发表的一篇论文，年代较为久远，但其中关于缓存一致性(cache coherence)、分布式事务(distributed transactions)、分布式故障恢复(distributed crash recovery)的设计思想，依旧值得我们学习。
Frangipani可以看作是一个分布式文件系统，它为上层应用提供文件系统的接口。
一台服务器的读写性能有限，当数据量过大时，我们需要将数据分割到不同的服务器上，从而使系统能够并行处理客户请求，提高系统整体性能。但这又引出新的问题：分布式事务(Distributed Transactions) 。
举个例子：一家银行将北京用户的数据存放在北京的服务器中，将上海用户的数据存储在上海的服务器中。此时，一个北京的用户A向上海的用户B汇款100元。按照正常流程，需要同时进行2个操作：到北京服务器中将用户A的余额-100，到上海服务器中将用户B的余额+100。但是，分布式网络充满复杂性，如果北京服务器操作完之后，上海服务器宕机了，那用户A的余额-100，而用户B的余额并没有+100。或者，北京服务器执行操作出错了，因为用户A余额并不够100，而上海服务器执行操作成功，用户B余额+100。不管是哪种结果，这肯定是不符合预期的，系统应该保证2个操作都成功或都失败。而这就是分布式事务所要解决的问题之一。
MIT6.824 LEC10
为了容错，我们需要对数据进行备份。而当数据有多个备份副本之后，我们又需要保证各副本的一致性，即需要将状态（数据）同步到各个副本。
常见的一致性算法，比如raft，都采用主从拓扑结构。这种结构下，主节点接收读写请求，并负责将状态同步到所有备份节点。主节点负载较高，系统整体性能将受限于主节点。当然，也可以与Zookeeper一样，舍弃强一致性（线性一致性），将读请求分摊给备份节点。
而链式复制(CR, Chain Replication)采用链式拓扑结构，不选择主节点，每个节点只需将状态同步到下一个节点。CRAQ是基于CR的改进，它允许从任意副本中读数据，同时还保证线性一致性。
MIT6.824 LEC9: Zookeeper。
当单机性能到达瓶颈时，我们需要对应用服务进行横向扩展，将同一个应用部署到多台服务器上，以提高整体性能。但新的解决方法总会带来新的问题：应用的配置（比如数据库连接、地址黑名单）需要更新时，如何进行统一更新？当多个应用对同一个外部资源进行修改时，如何保证同步互斥？为了解决这些问题，就有了Zookeeper的出现。
Zookeeper是大数据组件中的一员，由于它起到协调管理的作用，而其它大数据组件大多以动物名字命名，因此它就被称为动物园管理员。
Zookeeper是一个提供分布式协调的中心化服务，官网中的一句话介绍了Zookeeper的主要功能：配置管理、命名服务（类似于DNS）、分布式同步（分布式锁）和集群管理（集群节点的加入与退出）。
ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
接下来将结合Zookeeper论文来学习它的具体设计与实现。
VMware公司在2010年发表了一篇有关虚拟机容错的论文：《The Design of a Practical System for Fault-Tolerant Virtual Machines》。同时，它也是MIT6.824 LEC4的Preparation Read。本文将结合课程简单介绍论文内容。
2000年前后，随着互联网的飞速发展，单机的存储和计算能力早已达到瓶颈，急需通过增加机器数量来提高整体性能。但是，1+1并不大于2，机器数量的增加带来了许多新的问题：网络延迟、机器宕机、数据不一致等等。正是为了解决这些问题，Google在2003-2006年间先后发表了3篇论文《GFS》、《MapReduce》、《Bigtable》，分别解决了大规模数据的存储(非结构化)、计算、索引(结构化数据/数据库)，这三篇也被称为Google三驾马车，鉴定了分布式大数据时代的基础。后来的开源项目Hadoop中，HDFS参考了《GFS》，MapReduce参考了《MapReduce》，HBase参考了《Bigtable》。
GFS首先被提出，它在大规模分散的机器上，实现了类似Linux文件系统的分布式存储系统。单台机器读写数据的性能有限，对于数亿GB的海量，肯定不能存放在单台机器上，而应将数据分割存储到多台机器上。同时，还需考虑机器宕机、磁盘损坏的问题，对同一份数据应做多个备份。如此又会出现许多新问题：如何在多台机器中找到用户想要的数据？如何保证系统在部分机器失效的情况下仍能正常运行？如何保证多个备份数据的一致？如何保证较高的读写性能？这些问题都将GFS中得到解决。