作者主要介绍了Google内部的分布式锁服务Chubby，可以在分布式环境中提供粗粒度的锁服务，可以在由大型、小型机器组成的松耦合分布式系统中实现同步、元数据存储、拓扑或配置信息等功能。
如何实现异步一致性，Chubby的解决方案是引入Paxos。 作者也表示，当时的一般情况是，只要涉及到实现异步一致性的系统，其内部实现或多或少都会受到Paxos算法的影响。 作者强调了这篇论文不涉及新提出的算法，而是集中在工程实现和后续优化的提高上。 实际上，整篇论文不涉及一致性算法。
中心块服务的第二部分作者解释了为什么选择使用本地客户端访问此lock service的中心块服务，而不是创建Paxos算法库并将其提供给开发人员。 作者说，这样的理由是由开发者的需求决定的，另外，中心锁服务可以减少APP应用依赖的服务的数量。 此类设计要求客户端能够主动发现中央服务器上的数据更改。 此外，客户端还必须缓存信息以减少对服务器的压力。 当然，访问限制也是必要的。
接下来作者阐述了为什么选择提供粗粒度的锁定服务而不是细粒度的锁定服务。 这是因为它可以增加锁的保留时间并减少服务器压力，即使较小规模的锁服务不可用，许多客户端也会停止。 APP应用程序开发者可以自己对业务内部实现细粒度的锁定。
系统架构是系统结构的一部分，Chubby主要有两个组成部分：服务器和客户端库。 Chubby内部有Chubby Cell的概念，一般一个Cell有5台Server构成一个集群，其中一台是master，其他是复制品(replica )。 5台机器按照分布式一致性协议(Paxos )选出主机，为了成为主机，5台机器中至少有3台机器必须经过大多数投票(也就是说，如果这个蜂窝中有3台机器正常运行，这个蜂窝就是正常的配对)
其中，主机以租赁的形式运行。 只要得到复制的同意，租赁就会定期更新，延长主运转时间。 这样，在主机正常运行期间，新主机就不会在短时间内选出。 此外，由于Chubby支持读写小文件和订阅主选举结果，因此Chubby的实际APP应用必须支持成百上千的客户端截获和读取相同的文件。
客户哪台是主机？ 然后，客户端向DNS请求Chubby服务器列表，并开始随机访问。 非主服务器根据其存储的群集信息向客户端反馈哪个是主服务器，然后客户端重定向到主服务器。
复制副本(replica )是copy master数据库，用于保持一致性，但只有master可读写，并且更新会传播到复制副本。 过半数的replica收到请求后，master会向客户端返回成功的反馈。 读取请求不需要通过广播直接进行主处理。
Chubby的客户端界面类似于Unix文件系统结构。 该客户端不仅可以读写Chubby服务器上的整个文件，还可以添加文件节点的锁定控制，以及通过事件机制订阅服务器端对文件内容变更的通知。
文件后不久，作者开始介绍Chubby的文件、目录和句柄。 大体上类似于UNIX文件系统。 后来我说API也很像文件系统。 因此，文件的地址由目录和斜杠分隔。 这样的地址被称为一个Node。 Node有永久和临时两种，每个Node除了数据外还具有一些元数据。 每个Chubby的文件和目录都可以用作读写锁。 其中，写锁定是独占的，读锁定是共享的。 如何实现锁定提到了sequence number。
由于网络通信的不确定性，sequence number分布式环境中的锁定机制很复杂。 例如，客户机C1获得排他锁l，在拥有l的期间发出了request R，但由于网络问题，r没有到达服务器端时，APP应用程序认为客户机C1进程挂起，将锁l重新分配给C2 重新启动以前失踪的request R，但之后之前失踪的r到达服务器端，在非幂等条件下服务器端可能会再次响应r，导致数据不一致。
Chubby采用了delay和sequence number两种机制来优化上述问题(我认为这并不是解决方案)。 delay简单地说，如果客户端在异常情况下解除锁定，Chubby服务将允许该客户端在delay时间内一直不解除此锁定。 这样，其他客户端就无法获得该锁，从而减少网络延迟带来的问题。
sequence number是指锁的所有者向Chubby服务器端请求包含若干属性的序列号，然后在需要使用锁时将该序列号发送给Chubby服务器，服务器端将发送number是否有效等
介绍了事件通知机制和缓存然后转发给客户端创建者，在服务器端发生某些事件时通知客户端的事件通知机制。 这样，客户端就可以识别数据更改，并可以更新或禁用本地缓存。
客户端有自己的本地缓存，因此可以减少对Chubby的读取压力。 如何确保客户端和服务器端缓存的一致性？ 答案是利用租赁，缓存时效由租赁把持，协议保证客户端看到的是和
Chubby 一致的状态，否则会报错。一旦租约到期客户端要向服务端续订才能继续保持缓存的有效性，否则只能过期缓存。如果 file data 或者 meta-data 将被改变了，master 会通知所有缓存了该信息的客户端，期间这部分更改会被阻塞，等到 master 收到了客户端确认本地缓存无效或者是过期了缓存租约，那么这部分更改才会生效。本地缓存还可以重用句柄，或者是更长时间地 hold lock 期待客户端将来会再使用这把锁，如果期间发生了其他客户端请求这把锁的情况，那么在 master 通知它后就释放。
Session、KeepAlive一个 Chubby session 是在 Chubby cell 和客户端之间的一种关系，它存在于某个时间间隔内，通过周期性的称为 KeepAlives 的心跳来保持 session 的活性。响应来自客户端的 KeepAlive RPC 调用时。在收到一个KeepAlive RPC 时，master 通常会阻塞该 RPC(不允许它返回)到该 client 的前一个租约接近过期。然后 master 允许该 RPC 返回给客户端，同时告知客户端新的租约过期时间。Master 可以任意的延长过期时间。默认的延长时间是12s，但是一个负载过高的 master 可能使用一个更高的值来减少它所需要处理的 KeepAlives RPC 调用。收到上一个 KeepAlives 调用的回复后，客户端会初始化一个新的 KeepAlives 调用。因此客户端可以保证通常只有一个KeepAlives 调用阻塞在 master 端。这个 KeepAlives 的回复也可以用来给客户端传递时间和过期缓存。同时客户端维护了一个本地租约过期时间，如果客户端的本地缓存租约过期了，由于此时它就无法确定 master 是否已经结束了这个 session，客户端就需要清空并禁用它的缓存，此时 session 处于 jeopardy 状态。客户端会继续等待一个称为 grace period 的时长，默认是45秒。如果在grace period 结束之前，客户端和 master 又完成了一次成功的 KeepAlive 交互，那么客户端就会再次使它的缓存有效。否则，客户端就假设 session 已过期。
当 master 挂了或者失去 master 身份的时候，它会丢掉它的关于 session，句柄及锁的所有内存状态，转而运行一个 session 租约计时器。等待新的 master 选举出来，如果一个 master 选举很快完成，那么客户端就可以在他们的 local 租约计时器过期之前联系新的 master。如果选举花了很长时间，客户端 grace period 使得会话可以超越正常的租约过期时间而能够在故障恢复期间仍能得以维护。新的 master 需要重建它的前任 master 内存状态，这里一部分通过读取保存在硬盘上的数据来完成，一部分通过从客户端获取状态，一部分再通过保守的估计来完成。数据库会记录每个会话，持有的锁及临时文件。
论文剩下的部分主要是一些工程上的演进和使用改良。