Bigtable是一个分布式多维映射表，表中的数据通过一个行关键字（RowKey）、一个列关键字（ColumnKey）以及一个时间戳（TimeStamp）进行索引Bigtable的存储逻辑可以表示为：(row:string,column:string,time:int64)→string行：Bigtable的行关键字可以是任意的字符串，但是大小不能够超过64KB表中数据都是根据行关键字进行排序的，排序使用的是词典序同一地址域的网页会被存储在表中的连续位置倒排便于数据压缩，可以大幅提高压缩率列：将其组织成所谓的列族（ColumnFamily）族名必须有意义，限定词则可以任意选定组织的数据结构清晰明了，含义也很清楚族同时也是Bigtable中访问控制（AccessControl）的基本单元时间戳：Google的很多服务比如网页检索和用户的个性化设置等都需要保存不同时间的数据，这些不同的数据版本必须通过时间戳来区分。Bigtable中的时间戳是64位整型数，具体的赋值方式可以用户自行定义

1、广泛的适用性Bigtable是为了满足一系列Google产品而并非特定产品的存储要求。2、很强的可扩展性根据需要随时可以加入或撤销服务器3、高可用性确保几乎所有的情况下系统都可用4、简单性底层系统的简单性既可以减少系统出错的概率，也为上层应用的开发带来便利

用户chinacloud提出向文件CLOUD中写入内容的请求。CLOUD首先读取自身的写ACL名fun，接着在fun中查到了chinacloud这一行记录，于是返回信息允许chinacloud对文件进行写操作，此时chinacloud才被允许向CLOUD写入内容。其他的操作和写操作类似。

1、一致性每个Chubby单元是由五个副本组成的，这五个副本中需要选举产生一个主服务器，这种选举本质上就是一个一致性问题2、安全性采用的是ACL形式的安全保障措施。只要不被覆写，子节点都是直接继承父节点的ACL名3、性能优化提高主服务器默认的租约期、使用协议转换服务将Chubby协议转换成较简单的协议、客户端一致性缓存等

1、实例号InstanceNumber新节点实例号必定大于旧节点的实例号。2、内容生成号ContentGenerationNumber文件内容修改时该号增加。3、锁生成号LockGenerationNumber锁被用户持有时该号增加。4、ACL生成号ACLGenerationNumberACL名被覆写时该号增加。

1、客户端在客户这一端每个客户应用程序都有一个Chubby程序库（ChubbyLibrary），客户端的所有应用都是通过调用这个库中的相关函数来完成的。2、服务器端服务器一端称为Chubby单元，一般是由五个称为副本（Replica）的服务器组成的，这五个副本在配置上完全一致，并且在系统刚开始时处于对等地位。

1、高可用性和高可靠性2、高扩展性3、支持粗粒度的建议性锁服务4、服务信息的直接存储5、支持缓存机制6、支持通报机制

一、准备阶段proposers选择一个提案并将它的编号设为n将它发送给acceptors中的一个“多数派”acceptors收到后，如果提案的编号大于它已经回复的所有消息，则acceptors将自己上次的批准回复给proposers，并不再批准小于n的提案。二、批准阶段当proposers接收到acceptors中的这个“多数派”的回复后，就向回复请求的acceptors发送accept请求，在符合acceptors一方的约束条件下，acceptors收到accept请求后即批准这个请求。

p1：每个acceptor只接受它得到的第一个决议。p2：一旦某个决议得到通过，之后通过的决议必须和该决议保持一致。p2a：一旦某个决议v得到通过，之后任何acceptor再批准的决议必须是v。p2b：一旦某个决议v得到通过，之后任何proposer再提出的决议必须是v。p2c：如果一个编号为n的提案具有值v，那么存在一个“多数派”，要么它们中没有谁批准过编号小于n的任何提案，要么它们进行的最近一次批准具有值v。为了保证决议的唯一性，acceptors也要满足一个约束条件：当且仅当acceptors没有收到编号大于n的请求时，acceptors才批准编号为n的提案。

三个节点1、proposers：提出决议2、acceptors：批准决议3、learners：获取并使用已经通过的决议三个条件1、决议只有在被proposers提出后才能批准2、每次只批准一个决议3、只有决议确定被批准后learners才能获取这个决议