【分布式】Chubby与Paxos

　　Chubby的命名空间，包括文件和目录，我们称之为节点（Nodes，我们以数据节点来泛指Chubby的文件或目录）。在同一个Chubby集群数据库中，每一个节点都是全局唯一的。和Unix系统一样，每个目录都可以包含一系列的子文件和子目录列表，而每个文件中则会包含文件内容。Chubby没有符号链接和硬连接的概念。

　　Chubby上的每个数据节点都分为持久节点和临时节点两大类，其中持久节点需要显式地调用接口API来进行删除，而临时节点则会在其对应的客户端会话失效后被自动删除。也就是说，临时节点的生命周期和客户端会话绑定，如果该临时节点对应的文件没有被任何客户端打开的话，那么它就会被删除掉。因此，临时节点通常可以用来进行客户端会话有效性的判断依据。

　　Chubby的每个数据节点都包含了少量的元数据信息，其中包括用于权限控制的访问控制列表（ACL）信息，同时每个节点的元数据还包括4个单调递增的64位标号：

　　① 实例标号，用于标识创建该数据节点的顺序，节点的创建顺序不同，其实例编号也不相同，可以通过实例编号来识别两个名字相同的数据节点是否是同一个数据节点，因为创建时间晚的数据节点，其实例编号必定大于任意先前创建的同名节点。

　　② 文件内容编号（针对文件），用于标识文件内容的变化情况，该编号会在文件内容被写入时增加。

　　③ 锁编号，用于标识节点锁状态的变更情况，该编号会在节点锁从自由状态转化到被持有状态时增加。

　　④ ACL编号，用于标识节点的ACL信息变更情况，该编号会在节点的ACL配置信息被写入时增加。

　　2.4 锁和锁序列器

　　分布式环境中锁机制十分复杂，消息的延迟或是乱序都有可能引起锁的失效，如客户端C1获得互斥锁L后发出请求R，但请求R迟迟没有到达服务端（网络延迟或消息重发等），这时应用程序会认为该客户端进程已经失败，于是为另一个客户端C2分配锁L，然后在发送请求R，并成功应用到了服务器上。然而，之前的请求R经过一波三折后也到达了服务器端，此时，它可能不瘦任何锁控制的情况下被服务端处理，而覆盖了客户端C2的操作，也是导致了数据不一致问题。

　　在Chubby中，任意一个数据节点均可被当做一个读写锁来使用：一种是单个客户端排他（写）模式持有这个锁，另一种则是任意数目的客户端以共享（读）模式持有这个锁，Chubby放弃了严格的强制锁，客户端可以在没有获取任何锁的情况下访问Chubby的文件。

　　Chubby采用了锁延迟和锁序列器两种策略来解决上述由于消息延迟和重排序引起的分布式锁问题，对于锁延迟而言，如果一个客户端以正常的方式主动释放了一个锁，那么Chubby服务端将会允许其他客户端能够立即获取到该锁；如果锁是以异常情况被释放的话，那么Chubby服务器会为该锁保留一定的时间，这称之为锁延迟，这段时间内，其他客户端无法获取该锁，其可以很好的防止一些客户端由于网络闪断的原因而与服务器暂时断开的场景。对于锁序列器而言，其需要Chubby的上层应用配合在代码中加入相应的修改逻辑，任何时候，锁的持有者都可以向Chubby请求一个锁序列器，其包括锁的名字、锁模式（排他或共享）、锁序号，当客户端应用程序在进行一些需要锁机制保护的操作时，可以将该锁序列器一并发送给服务端，服务端收到该请求后，会首先检测该序列器是否有效，以及检查客户端是否处于恰当的锁模式，如果没有通过检查，那么服务端就会拒绝该客户端的请求。

　　2.5 事件通知机制

　　为了避免大量客户端轮询Chubby服务端状态所带来的压力，Chubby提供了事件通知机制，客户端可以向服务端注册事件通知，当触发这些事件时，服务端就会向客户端发送对应的时间通知，消息通知都是通过异步的方式发送给客户端的。常见的事件如下

　　① 文件内容变更 ② 节点删除 ③ 子节点新增、删除 ④ Master服务器转移

　　2.6 缓存

　　其是为了减少客户端与服务端之间的频繁的读请求对服务端的压力设计的，会在客户端对文件内容和元数据信息进行缓存，虽然缓存提高了系统的整体性能，但是其也带来了一定复杂性，如如何保证缓存的一致性。其通过租期机制来保证缓存的一致性。

　　缓存的生命周期和Master租期机制紧密相关，Master会维护每个客户端的数据缓存情况，并通过向客户端发送过期信息的方式来保证客户端数据的一致性，在此机制下，Chubby能够保证客户端要么能够从缓存中访问到一致的数据，要么访问出错，而一定不会访问到不一致的数据。具体的讲，每个客户端的缓存都有一个租期，一旦该租期到期，客户端就需要向服务端续订租期以继续维持缓存的有效性，当文件数据或元数据被修改时，Chubby服务端首先会阻塞该修改操作，然后由Master向所有可能缓存了该数据的客户端发送缓存过期信号，使其缓存失效，等到Master在接收到所有相关客户端针对该过期信号的应答（客户端明确要求更新缓存或客户端允许缓存租期过期）后，再进行之前的修改操作。

　　2.7 会话

　　Chubby客户端和服务端之间通过创建一个TCP连接来进行所有的网络通信操作，这称之为会话，会话存在生命周期，存在超时时间，在超时时间内，客户端和服务端之间可以通过心跳检测来保持会话的活性，以使会话周期得到延续，这个过程称为KeepAlive（会话激活），如果能够成功地通过KeepAlive过程将Chubby会话一直延续下去，那么客户端创建的句柄、锁、缓存数据等将仍然有效。

　　2.8 KeepAlive请求

　　Master服务端在收到客户端的KeepAlive请求时，首先会将该请求阻塞住，并等到该客户端的当前会话租期即将过期时，才为其续租该客户端的会话租期，之后再向客户端响应这个KeepAlive请求，并同时将最新的会话租期超时时间反馈给客户端，在正常情况下，每个客户端总是会有一个KeepAlive请求阻塞在Master服务器上。

　　2.9 会话超时

　　客户端也会维持一个和Master端近似相同（由于KeepAlive响应在网络传输过程中会花费一定的时间、Master服务端和客户端存在时钟不一致的现象）的会话租期。客户端在运行过程中，按照本地的会话租期超时时间，检测到其会话租期已经过期却尚未收到Master的KeepAlive响应，此时，它将无法确定Master服务端是否已经中止了当前会话，这个时候客户端处于危险状态，此时，客户端会清空其本地缓存并将其标记为不可用，同时客户端还会等待一个被称作宽限期的时间周期，默认为45秒，若在宽限期到期前，客户端与服务端之间成功地进行了KeepAlive，那么客户端就会再次开启本地缓存，否则，客户端就会认为当前会话已经过期了，从而终止本次会话。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!