6.1.3　复制与一致性

Bigtable系统保证强一致性，同一个时刻同一个子表只能被一台Tablet Server服务，也就是说，Master将子表分配给某个Tablet Server服务时需要确保没有其他的Tablet Server正在服务这个子表。这是通过Chubby的互斥锁机制保证的，Tablet Server启动时需要获取Chubby互斥锁，当Tablet Server出现故障，Master需要等到Tablet Server的互斥锁失效，才能把它上面的子表迁移到其他Tablet Server。

Bigtable的底层存储系统为GFS（参见前面4.1节）。GFS本质上是一个弱一致性系统，其一致性模型只保证“同一个记录至少成功写入一次”，但是可能存在重复记录，而且可能存在一些补零（padding）记录。

Bigtable写入GFS的数据分为两种：

●操作日志。当Tablet Server发生故障时，它上面服务的子表会被集群中的其他 Tablet Server加载继续提供服务。加载子表可能需要回放操作日志，每条操作日志都有唯一的序号，通过它可以去除重复的操作日志。

●每个子表包含的SSTable数据。如果写入GFS失败可以重试并产生多条重复记录，但是Bigtable只会索引最后一条写入成功的记录。

Bigtable本质上是构建在GFS之上的一层分布式索引，通过它解决了GFS遗留的一致性问题，大大简化了用户使用。