myeclipse启动weblogic后无法获得文件锁_Google的锁，才是分布式锁？

早年Google的四大基础设施&＃xff0c;分别是GFS, MapReduce, BigTable, Chubby, 前三个比较有名&＃xff0c;今天来说说最后一个&＃xff0c;Chubby。

Chubby是什么&＃xff1f;

Chubby是早年Google四大基础设施之一&＃xff0c;提供粗粒度的分布式锁服务。

Chubby的使用者不需要关注复杂的同步协议&＃xff0c;而是通过已经封装好的客户端直接调用锁服务&＃xff0c;通过分布式锁&＃xff0c;满足各种分布式场景下的一致性需求。

Chubby有什么典型的业务场景&＃xff1f;

Chubby具有广泛的应用场景&＃xff0c;例如&＃xff1a;

(1)GFS选主&＃xff1b;

(2)BigTable中的表锁&＃xff1b;

Chubby的内核本质是什么&＃xff1f;

Chubby本质上是一个分布式文件系统&＃xff0c;存储大量小文件。每个文件就代表一个锁&＃xff0c;并且可以保存一些应用层面的小规模数据。

用户通过打开、关闭、读取文件来获取共享锁或者独占锁&＃xff1b;并通过反向通知机制&＃xff0c;向用户发送更新信息。

Chubby系统设计目标是什么&＃xff1f;

Chubby系统设计之初&＃xff0c;主要想满足以下几点&＃xff1a;

(1)粗粒度的锁服务&＃xff1b;

(2)高可用、高可靠&＃xff1b;

(3)可直接存储服务信息&＃xff0c;而无需另建服务&＃xff1b;

(4)高扩展性&＃xff1b;

Chubby的整体架构是怎么样的&＃xff1f;

Chubby架构并不复杂&＃xff0c;如上图所示&＃xff0c;其核心是这两个重要组件&＃xff1a;

(1)Chubby客户端&＃xff1a;以库的方式提供&＃xff0c;可以通过相应API接口&＃xff0c;申请锁服务&＃xff0c;获取数据信息&＃xff0c;同时保持与服务端的连接&＃xff1b;

(2)Chubby服务端&＃xff1a;服务端集群&＃xff0c;一般由5个节点组成(至少3个节点)&＃xff0c;其中一台主节点(master)&＃xff0c;维护与客户端的所有通信&＃xff1b;其他节点不断和主节点通信&＃xff0c;获取用户操作&＃xff1b;

在系统实现时&＃xff0c;还使用了以下特性&＃xff1a;

(1)客户端缓存&＃xff0c;以减少对主节点的访问&＃xff1b;

(2)反向通知机制&＃xff0c;锁变化时&＃xff0c;会反向通知客户端&＃xff1b;

Chubby的实现关键点有哪些&＃xff1f;

其一&＃xff0c;文件系统。

Chubby文件系统类似于简单的unix文件系统。

文件系统由许多Node组成&＃xff0c;每个Node代表一个文件&＃xff0c;或者一个目录。文件系统使用Berkeley DB来保存每个Node的数据。文件系统提供的API很少&＃xff1a;创建文件系统、文件操作、目录操作等简易操作。

其二&＃xff0c;基于ICE的通信机制。

Chubby基于ICE的通信机制&＃xff0c;核心就是异步&＃xff0c;部分组件负责发送&＃xff0c;部分组件负责接收。

其三&＃xff0c;客户端与主节点通信。

(1)使用长连接&＃xff0c;连接有效期内&＃xff0c;锁服务、客户端缓存数据均一直有效&＃xff1b;

(2)定时双向keepalive&＃xff1b;

(3)出错回调&＃xff1b;

下面将说明正常、客户端租约过期、主节点租约过期、主节点出错等情况。

(1)正常情况

keepalive会周期性发送&＃xff0c;它有两方面功能&＃xff1a;

一来&＃xff0c;延长租约有效期&＃xff0c;携带事件信息告诉客户端更新。

二来&＃xff0c;执行回调&＃xff0c;例如文件内容修改、子节点增删改、主节点出错等。

(2)客户端租约过期

客户端没有收到主节点的keepalive&＃xff0c;租约随之过期&＃xff0c;将会进入一个“危险状态”。由于此时不能确定主节点是否已经终止&＃xff0c;客户端必须主动让本地缓存失效&＃xff0c;同时&＃xff0c;进入一个寻找新的主节点的阶段。

这个阶段中&＃xff0c;客户端会轮询服务集群&＃xff0c;访问非主节点的其他节点&＃xff0c;当客户端收到一个肯定的答复时&＃xff0c;他会向新的主节点发送keepalive信息&＃xff0c;告之自己处于“危险状态”&＃xff0c;并和新的主节点建立会话&＃xff0c;然后把本地缓存中的信息刷新。

(3)主节点租约过期

主节点一段时间没有收到客户端的keepalive&＃xff0c;会进入一段等待期&＃xff0c;此期间内客户端仍没有响应&＃xff0c;则主节点认为客户端失效。失效后&＃xff0c;主节点会把客户端获得的锁&＃xff0c;打开的临时文件清理掉&＃xff0c;并通知各副本节点&＃xff0c;以保持一致性。

(4)主服务器出错

主节点出错&＃xff0c;需要内部进行重新选举&＃xff0c;各副本节点只响应客户端的读取命令&＃xff0c;而忽略写命令。

其四&＃xff0c;服务器集群间的一致性操作。

这里需要解决的问题是&＃xff0c;当主节点收到客户端请求时(主要是写)&＃xff0c;如何将操作同步到其他服务器节点&＃xff0c;以保证数据的一致性。

(1)节点数目

一般来说&＃xff0c;节点数为5&＃xff0c;至少要是3。

(2)关于复制

收到客户端请求时&＃xff0c;主节点会将请求复制到所有成员&＃xff0c;并在消息中添加最新被提交的请求序号。副本节点收到这个请求后&＃xff0c;获取主节点处被提交的请求序号&＃xff0c;然后执行这个序列之前的所有请求&＃xff0c;并把其记录到内存的日志里。

各副本节点会向主节点回复消息&＃xff0c;主节点收到半数以上的消息(集群包含5个节点时&＃xff0c;至少要收到3个节点)&＃xff0c;才能够进行确认&＃xff0c;执行请求&＃xff0c;并返回客户端。

画外音&＃xff1a;半数以上确认&＃xff0c;才认为成功。

如果某个副本节点出现暂时的故障&＃xff0c;没有收到部分消息也没关系&＃xff0c;副本节点重新启动后&＃xff0c;主动从主节点处获得已执行的&＃xff0c;自己却还没有完成的日志&＃xff0c;并进行执行。

画外音&＃xff1a;像不像MySQL的binlog。

最终&＃xff0c;所有成员都会获得一致性的数据&＃xff0c;正常情况下&＃xff0c;至少有3个节点包含一致&＃xff0c;且最新的数据。

最后&＃xff0c;举几个Chubby使用场景的例子。

例子一&＃xff0c;集群选主

(1)集群中每个节点都试图创建/打开同一个文件&＃xff0c;并在该文件中记录自己的服务信息&＃xff0c;任何时刻&＃xff0c;肯定只有一个服务器能够获得该文件的控制权&＃xff1b;

(2)首先创建该文件的节点成为主&＃xff0c;并写入自己的信息&＃xff1b;

(3)后续打开该文件的节点成为从&＃xff0c;并读取主的信息&＃xff1b;

画外音&＃xff1a;是不是很巧妙&＃xff1f;

例子二&＃xff0c;进程监控

(1)各个进程都把自己的状态写入指定目录下的临时文件里&＃xff1b;

(2)监控进程通过阅读该目录下的文件信息来获得进程状态&＃xff1b;

(3)各个进程随时有可能死亡&＃xff0c;因此指定目录的数据状态会发生变化&＃xff1b;

(4)通过事件机制通知监控进程&＃xff0c;读取相关内容&＃xff0c;获取最新状态&＃xff0c;达到监控目的&＃xff1b;

总结

Google Chubby提供粗粒度锁服务&＃xff0c;它的本质是一个松耦合分布式文件系统。开发者不需要关注复杂的同步协议&＃xff0c;直接调用库来取得锁服务&＃xff0c;并保证了数据的一致性。

最后要说明的是&＃xff0c;最终Chubby系统代码共13700多行&＃xff0c;其中ICE自动生成6400行&＃xff0c;手动编写约8000行。

这就是Google牛逼的地方&＃xff1a;强大的工程能力&＃xff0c;快速稳定的实现&＃xff0c;快速解决各种业务问题。

近期被罚了&＃xff0c;原创功能被关了&＃xff0c;申诉也失败了&＃xff1a;

《账号被罚了&＃xff0c;有点不开心》

《账号被罚了&＃xff0c;申诉的结果出来了&＃xff0c;果然》