随着计算机系统规模变得越来越大，将所有的业务单元集中部署在一个或若干个大型机上的体系结构，已经越来越不能满足当今计算机系统，尤其是大型互联网系统的快速发展，各种灵活多变的系统架构模型层出不穷。
同时，随着微型计算机的出现，越来越多廉价的PC机成为了各大企业IT架构的首选，分布式的处理方式越来越受到业界的青睐——计算机系统正在经历一场前所未有的从集中式向分布式架构的变革。
自20世纪60年代大型主机被发明出来以后，凭借其超强的计算和I/O处理能力以及在稳定性和安全性方面的卓越表现，在很长一段时间内，大型主机引领了计算机行业以及商业计算领域的发展。
在第 1 章内容的讲解中我们也已经提到，在对一个分布式系统进行架构设计的过程中，往往会在系统的可用性和数据一致性之间进行反复的权衡，于是就产生了一系列的一致性协议。
为了解决分布式一致性问题，在长期的探索研究过程中，涌现出了一大批经典的一致性协议和算法，其中最著名的就是二阶段提交协议、三阶段提交协议和Paxos算法了。
本章将着重向读者介绍二阶段和三阶段提交协议的设计与算法实现流程，指出它们各自的优缺点，同时重点介绍Paxos算法。
在第2章中，我们主要从理论上讲解了Paxos算法，然而Paxos算法在工程实现的过程中，会遇到非常多的问题。
Paxos算法描述并没有涉及实际工程中需要注意的很多细节，同时对于开发人员来说，如何在保证数据一致性的情况下兼顾稳定性和性能也是一个巨大的挑战。
从本章开始，我们将结合实际工程实践中的Paxos实现，来讲解如何真正地使用Paxos算法来解决分布式一致性问题。
Google Chubby 是一个大名鼎鼎的分布式锁服务，GFS和Big Table等大型系统都用它来解决分布式协作、元数据存储和 Master 选举等一系列与分布式锁服务相关的问题。
Hypertable 是一个使用 C++语言开发的开源、高性能、可伸缩的数据库，其以 Google的 BigTable 相关论文为基础指导，采用与 HBase 非常相似的分布式模型，其目的是要构建一个针对分布式海量数据的高并发数据库。
目前 Hypertable 只支持最基本的添、删、改、查功能，对于事务处理和关联查询等关系型数据库的高级特性都尚未支持。
同时，就少量数据记录的查询性能和吞吐量而言，Hypertable 可能也不如传统的关系型数据库。
和传统关系型数据库相比，Hypertable 最大的优势在于以下几点。
