GlusterFS的分布式锁

“Glusterfs锁，并没有中央锁服务器的概念。它可以使用一个或多个节点作为锁管理节点，而底层直接使用系统上的锁机制，所以本身并不需要作过多的工作。它需要保证的是，锁的事务性，即要么锁成功，要么不锁。对于多个锁节点，这个尤其重要，必须所有节点都锁上，才是加锁成功。不能一个节点加锁成功，而其他节点不成功，这样容易引起死锁。”

GlusterFS锁由记录锁构成，即通过fcntl实现，可对文件的某一区域进行加锁，而不是直接对整个文件加锁。采用这种细粒度锁的实现，有利于多客户端对同一文件不同区域的并行写操作。如上所述，GlusterFS的锁机制可分为两部分理解，一是底层的文件系统锁，对应xlator/locks模块；二是上层的事务锁，对应不同的集群模式。

一、文件系统锁

代码上看，GlusterFS锁是由xlators/locks实现，它是一个Translator，一般直接在Server端的posix 文件系统上加载，即直接对Server端的本地文件系统上的文件加锁(记录锁)，当然，xlator/locks实现的锁机制最终会反应到Server端本地文件系统上的锁。它的主要原理是：如同不同客户端对同一文件的重叠区域写，则将此写请求插入一等待队列，由flush操作调度；否则，可并行读写。

二、事务锁

逻辑上看，不同的集群模式有不同的处理流程，会有不同的处理逻辑来保证锁的事务性。读操作处理流程相对简单，以下主要分析写流程。

对AFR，由于要同时向多个存储节点写文件，为保证数据一致性，必须先获得各个存储节点的锁，然后才能执行写操作。这会涉及多个锁管理节点，只要有一个节点没有加锁成功，必须放弃之前从其余各节点获取的锁，并重新尝试获取所有节点的锁。

对DHT，由于文件写只会对应一个存储节点，所以一旦节点定位成功，写操作相对简单。

对Stripe，首先通过计算，定位某文件片对应的存储节点，然后才获取对应节点的锁，由于每一分片只涉及一个存储节点，类似DHT，写操作的处理也比较简单。

转自：http://blog.csdn.net/kidd_3/article/details/7665004