数据库SQL（十二）：分布式锁服务Chubby

一、概念

提供存储服务并为其他基础设施(GFS和Bigtable) 提供协调服务

• GFS使用Chubby选取master服务器，Bigtable使用chubby指定master服务器并发现、控制相关的子表服务器。

提供粗粒度的分布式锁

• Advisory lock,不是mandatory lock
• 锁持有时间可以长达几天

提供一个文件系统，为小文件提供可靠存储，补充GFS提供的服务做Google内部的名字服务
核心服务:提供分布式共识解决方案

• 其他服务从这一服务衍生
  通常一个数据中心运行一个chubbycell (服务实例)

二、用途

Google没有直接实现包含Paxos算法的函数库来保持数据一致性，而是设计实现了锁服务Chubby

• 单独的锁服务可以保证原有系统架构不发生改变
• 避免应大量系统组件之间的事件通信导致的系统性能下降
  ➢系统中很多事件的发生需要告知其它用户和服务器，使用基于文件系统的锁服务可以将变动写入文件，从而需要了解变动的用户和服务器直接访问文件，
• 相比一致性算法，基于锁的开发接口容易被开发者接受
• 单独的锁服务使用一台服务器可以保证高可用性
  ➢实现chubby服务采用多台服务器实现高可用性，而外部用户则需一台服务器保证高可用性
• Chubby采用建议性锁而不是强制性锁
  ➢当用户访问拥有锁的文件时，强制性锁阻止访问，而建议性锁不会阻止。

三、体系结构

两个部分: client和server, 通过RPC通信

• 客户端每个客户有一个Chubby library,客户端应用调用这个库中的函数
• 服务端称作Chubbycell,通常由5个副本组成，其中一个副本被指定为主副本(master),并且一段时间只有一个master。
  ➢这段时间成为master lease

每个副本维护一个小型数据库，管理Chubby命名空间中的实体，即目录和锁

数据库的一致性使用底层的共识协议、(Paxos算法)实现

基于操作日志

支持创建快照snapshots (在给定时间点上完整的系统状态)

四、文件结构

• Chubby提供基于文件系统的抽象，每一个数据对象是一个文件，文件组织成层次的命名空间，采用目录结构，所有操作在文件的基础上完成

• Chubby的名字空间结构类似于文件系统，这样就使得可以为应用提供特定的API,也可以使用他文件系统的接口，例如GFS

• 文件系统与Unix文件系统类似，文件名形式: /s/chubby_ cell/directory_ name/–/file_ name
  ➢Is指锁服务lock service, 指明是chubby系统的一部分
  ➢Chubby_ cell 是chubby系统的一个特定实例的名字

• 名字空间由文件和目录组成，统称为node。每个node在一个Chubby cell单元中只有一个名称与之关联。

• 实现时，文件系统由多个节点组成，分为永久型和临时型，每个节点是一个文件或目录，包含元数据，三个访问控制列表(ACLs):用于控制读、写操作及修改节点的访问控制列表(ACL)。

• 每个节点的元数据还包含4个严格递增的64位数字，通过它们客户端可以很方便的检测出变化
  ●实例号
  ●内容生成号
  ●锁生成号
  ●ACL生成号

五、访问接口

六、一致性

• Chubby cell有5个副本，通过选举产生主服务器(主副本)，存在一致性问题， 采用Paxos算法
• 客户端所有读写操作由主服务器负责完成，写操作面临数据一致性，采用Paxos算法

本文地址：https://blog.csdn.net/Findyoulucky/article/details/107193353