https://github.com/tanyokwok/hdfslock

A distributed lock based on hdfs
https://github.com/tanyokwok/hdfslock

distributed-lock hdfs-lock

Last synced: 4 months ago
JSON representation

A distributed lock based on hdfs

• Host: GitHub
• URL: https://github.com/tanyokwok/hdfslock
• Owner: tanyokwok
• Created: 2017-03-07T02:09:12.000Z (over 9 years ago)
• Default Branch: master
• Last Pushed: 2017-03-07T02:15:40.000Z (over 9 years ago)
• Last Synced: 2024-12-31T12:29:31.820Z (over 1 year ago)
• Topics: distributed-lock, hdfs-lock
• Language: Python
• Size: 1.95 KB
• Stars: 2
• Watchers: 1
• Forks: 0
• Open Issues: 1
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
简介

=====

 DistLock是基于HDFS实现的分布式锁机制。

 该锁的目的是方便HDFS文件锁操作，但是适用于对锁效率要求不高的场景。

 + 主要优势是：分布式锁创建机制，配置简单

使用要求

----------

+ 需要安装HDFS

+ 需要安装pydoop

设计思想

---------

参考zookeeper，redis等分布式锁的设计，在pydoop hdfs api上实现：

+ 在hdfs上面创建一个lock目录(/path/to/lock)

+ 各个节点(拥有唯一ID)在申请锁的时候需要执行如下步骤

    + 创建路径为/path/to/lock/namd-ID.lock的文件

    + 获取/path/to/lock/目录下的所有文件信息

    + /path/to/lock/下的文件按照创建时间排序

    + 如果最先创建的文件的ID，正好为当前节点ID的话，则获得锁。否则，获得锁失败

+ 释放锁操作，删除/path/to/lock目录下的所有文件

合理性

----------

HDFS NameNode上存储的是HDFS文件的元信息，且为单点故障模式。最重要的是，NameNode上的文件创建操作属于事务型的原子操作。即任意一个客户端创建的文件成功，所有客户端立即能够看到这个文件。上面的策略充分利用这种原子操作的特性，保证了分布式锁的互斥。

创建文件作为锁标志可以吗？

------------------

该思路把HDFS文件路径当作竞争资源，首先成功创建lock文件的获得锁，释放锁就是删除文件操作。

+ 每个进程在申请锁的时候查看lock文件是否存在

+ 如果lock文件不存在则创建文件，创建成功则认为自己获得锁

这种思路（使用pydoop）存在严重的问题：

+ 可能存在多个进程同时申请资源，并发现lock文件未创建

+ 此时，多个进程都会创建文件。但是没有任意一个进程会创建失败（使用pydoop hdfs.open_file不会报错，而是返回已经存在的文件句柄）

+ 最终多个进程都会获得锁，显然是错误的。