分布式锁管理器与分布式数据库的区别及Bigtable相关技术问询

核心结论 #

Bigtable没有用Paxos或其衍生共识算法实现tablet的复制，它的高可用和持久化是靠Chubby+GFS的组合支撑的，自身没内置共识协议。

针对你的疑问逐一解释 #

1. 为什么论文没提Bigtable自身的共识算法？ #

Bigtable的架构设计是典型的"职责外包"：

• 分布式锁、元数据一致性这类需要共识的场景，完全交给基于Paxos的Chubby来做——比如保证每个tablet同一时间只被一个服务器接管（对应论文5.2节的规则），从根源避免多写冲突。
• 数据的持久化和冗余存储，则直接依赖GFS的多副本机制（论文5.3节明确tablet状态存在GFS）。GFS本身已经通过多副本复制解决了数据丢失和高可用问题，Bigtable没必要再自己实现一层共识复制。

2. tablet分配规则与GFS存储的真实作用 #

• 单tablet单服务器：这是Chubby独占锁的直接结果——tablet服务器必须先拿到Chubby上对应tablet的锁，才能对外提供读写服务。这是为了保证写入的单点性，防止多个服务器同时修改同一个tablet，和复制完全是两回事。
• GFS存储tablet状态：GFS会自动给存储的SSTable、操作日志创建多副本，就算某个tablet服务器挂了，只要GFS的副本还在，新的服务器就能从GFS拉取完整数据恢复服务。

3. 服务器故障的处理逻辑 #

当tablet服务器故障时：

• Chubby的租约会因为服务器心跳中断到期，对应的tablet锁自动释放。
• Bigtable Master会定期扫Chubby的锁状态，发现释放的tablet锁后，把这个tablet重新分配给其他可用的服务器。
• 新服务器从GFS拉取该tablet的所有SSTable和未合并的日志，回放日志恢复到最新状态，然后就能对外提供服务了。
  整个过程根本不需要共识算法参与，全靠Chubby的锁管理和GFS的冗余存储撑着。

内容的提问来源于stack exchange，提问作者V. Semeria