图2-24是Megastore的基本架构，最底层的数据是存储在Bigtable中的。不同类型的副本存储不同的数据。在Megastore中巧有三种副本，分别是完整副本（Full Replica)、 见证者副本（Witness Replica)和只读副本(Read-only Replica)。图2-24中出现了两种副本，分别是完整副本A和B，以及见证者副本C。对于完整副本，Bigtable中存储完整的日志和数据。见证者副本的作用是在Paxos算法执行过程中无法产生一个决议时参与投票，因此对于这种副本，Bigtable只存储其日志而不存储具体数据。最后一种只读副本和见证者副本恰恰相反，它们无法参与投票。它们的作用只是读取到最近过去某一个时间点的一致性数据。如果读操作能够容忍这些过期数据，只读副本能够在不加剧写延迟的情況下将数据在较大的地理空间上进行传输。
Megastore的部署需要通过一个客户端函数库和若干的服务器。应用程序连接到这个客户端函数库，这个函数库执行Paxos算法。图2-24中还有一个称为协调者的服务，要想理解这个服务的作用，首先来了解下Megastore中提供的快速读（Fast Reads)和快速写 (FastWrites)机制。
1.快速读
如果读操作不需要副本之间进行通信即可完成，那么读取的效率必然相对较高。由于写操作基本上能在所有的副本上成功，一旦成功认为该副本上的数据都是相同的且是最新的，就能利用本地读?。↙ocal Reads)实现快速读，能够带来更好的用户体验及更 低的延迟。确?？焖俣脸晒Φ墓丶潜Ｖぱ≡竦母北旧鲜菔亲钚碌?。为了达到这一目标，设计团队引入了协调者的概念。协调者是一个服务，该服务分布在每个副本的数据中心里面。它的主要作用就是跟踪一个实体组集合，集合中的实体组需要具备的条件就 是它们的副本已经观察到了所有的Paxos写。只要出现在这个集合中的实体组，它们的副本就都能够进行本地读取，也就是说能够实现快速读。协调者的状态是由写算法来保证。
2.快速写
为了达到快速的单次交互的写操作，Megastore釆用了一种在主/从式系统中常用的优化方法。如果一次写成功，那么下一次写的时候就跳过准备过程，直接进入接受阶段。因为一次成功的写意味着也准确地获知了下一个日志的位置，所以不再需要准备阶段。 Megastore没有使用专门的主服务器，而是使用leaders。系统在每一个日志位置都运行一个Paxos算法实例。leader主要是来裁决哪个写入的值可以获取0号提议。第一个将值提交给leader的可以获得一个向所有副本请求接收这个值作为0号提议最终值的机会。其他的值就需要重新使用Paxos算法。
由于写入者在提交值给其他副本之前必须要和leader通信，为了尽可能地减少延迟， Megastore做了一个简单的优化，即在提交值最多的位置附近选择一个副本作为leader。
客户端、网络及Bigtable的故障都会导致一个写操作处于不确定的状态。图2-24中的复制服务器会定期扫描未完成的写入并且通过Paxos算法提议没有操作的值（No-op Values)来让写入完成。
