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


你可能感兴趣的:(GlusterFS的分布式锁)