分布式锁的技术选型及思考
Posted GitChat精品课
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式锁的技术选型及思考相关的知识,希望对你有一定的参考价值。
锁和分布式锁
在计算机中,锁的作用是解决在并发状态下的共享资源互斥问题,保证在同一时间只有一个进程/线程可以掌握资源的控制权。
例如以下几种情况:
文件锁的实现是为了解决不同用户同时读写同一文件的并发问题而出现的,防止导致文件的内容被破坏。
使用数组实现的队列,在 push 操作的地方一般需要加锁来解决槽位的争夺问题,防止出现多次 push 冲突从而导致数据丢失问题。
对于12306来说,火车票就是他的资源,最终放票的时候需要锁来保证票、人、座位唯一对应。
……
上面的例子中其实就包含了我们通常讲的传统单机锁和我要讲的分布式锁。
单机环境下,资源竞争者都是来自机器内部((进程/线程),那么实现锁的方案只需要借助单机资源就可以了,比如借助磁盘、内存、寄存器来实现。
但是对于分布式环境下,资源竞争者生存环境更复杂了,原有依赖单机的方案不再发挥作用,这时候就需要一个大家都认可的协调者出来,帮助解决竞争问题,那这个协调者称之为分布式锁。
上面这个例子就像两个职员产生的矛盾,只要公司的领导出面就可以解决。而当两个公司产生竞争矛盾的时候,就需要司法机关出面,是同一个道理。
简单的说,分布式锁就是解决分布式环境下资源竞争问题的手段。
分布式锁的应用场景
所有分布式环境下会出现资源竞争的地方都需要分布式锁的协调,除了上面介绍的 12306 放票,还有类似共享文档平台编辑问题、王者荣耀选择英雄、全局自增主键等应用需要用到。简单介绍一下在类似公司内部 Wiki 等多人协作编辑平台的使用场景。
Wiki 中的多人在线编辑
场景2:另一个 case,我是 Z 同学,在我前面别人都已经填完了,我有一个陋习,喜欢在保存的时候连续按3-5下 Ctrl+s,而每一个 Ctrl+s 都会触发一个请求,但是每个请求处理大概1s钟,但是实际请求都在 20ms 内发出去了。
问题同上面,如何保证不重复的追加记录呢?
假设你的存储服务和存储架构是这样的:
一般的处理代码是这样的:
//根据docid获取文件内容,从分布式文件系统取,时间不可控
nowFileContent = getFileByDocId(docId) //do something,类似diff,追加操作
newFileContent = doSomeThing() //存储到文件系统
setNewFileContent(docId,newFileContent)
对于场景1讲到的 A、C 两个请求同时到达代码段,但是由于网络原因,A 先拿到文档内容,C 在 A 写入前读到文件内容,所以最终的结果是两者会丢失一个写入。
所以需要对读写操作做一次加锁,保证事务的完整、一致。
下图是《现代操作系统》中的插图,这里的效果也希望如此。
Wiki 这类场景属于长耗时事务的资源处理问题,锁的出现保证不会因为事务中的读写间跨度耗时大导致写覆盖的情况,使得请求排队,顺序处理。
解决方案选择
我遇到的问题也是类 Wiki 这类长事务的问题,遇到问题第一想法是去看网上的解决方案。
网上 mysql、ZK、Redis 各种实现方式很多,我需要选择哪种?怎么选择?我需要权衡哪些方面?
以前看分布式书的时候,一个被提到很多次的词是:trade-off,我理解是取舍或者是权衡吧。
作为一个 Web 开发者,我需要考虑的主要包含下面几个部分:
实现我的功能是否 OK,耗时是否满足在线需求?
实现难度、学习成本;
运维成本。
那么按照这几个标准来看一下现在的可选方案:
选好了方案,下面就是实现了。如果我们最终实现了这个锁,对它的要求是什么呢?实现MySQL 单主架构,写都会到 master,有瓶颈。ZK 的方式需要自己搭建、运维,而且需要堆机器,利用率不高。最终采用了 Redis 来实现,流量/存储都可以扩容,运维也不需要自己。
lock 实现必须要是原子操作,同时保证任何时候只有一个竞争者是独占的;
unlock 必须是原子的,同时保证只有自己可以解锁自己;
不能出现死锁,当进程挂掉之后不影响其他的加锁行为;
支持 Twemproxy 模式下的架构和单机;
耗时可以接受。
基于上述要求我的实现如下(只提供了大致,删除了敏感信息):
<?phpclass LockUtility{ const DEFAULT_UNLOCK_TIME = 4 ; const COMMON_REDISKEY_PREFIX = 'xxxxx' ; /** * @brief * * @param $ukey 需要加锁的key * @param $unlockTime 锁持有时长 * * @return */ public function __construct($ukey,$unlockTime=self::DEFAULT_UNLOCK_TIME){ $this->_objRedis = RedisFactory::getRedis(); $this->_redisKey = self::COMMON_REDISKEY_PREFIX.$ukey; $this->_unLockTime = $unlockTime ; //为单次加锁生成唯一guid $this->_guid = genGuid(); } /** * @brief 对给定的key进行加锁处理 * * @return * * true 表示加锁成功 * * 抛出异常则表示加锁未成功,根据业务选择自己的care的级别 * 异常错误码 : * 1.网络错误: ErrorCodes::REDIS_ERROR 视业务严谨度,这个错误是否忽略 * 2.锁被占用: ErrorCodes::LOCK_IS_USED 明确确定锁被别人占有 */ public function lock(){ /* * 设置锁的过程需要是原子的,所以采用了set来操作 * SET key value [EX seconds] [PX milliseconds] [NX|XX] * Redis 2.6.12 版本开始支持通过set 指定参数完成setexnx功能 * * php 语法 : $redis->set('key', 'value', Array('xx', 'px'=>1000)); * */ $setRet = $this->_objRedis->set($this->_redisKey,$this->_guid,array('nx', 'ex' => $this->_unLockTime)); //返回false表示请求锁失败 if(false === $setRet){ //锁被占用,抛异常 throw new Exception("get Lock Failed!Locking",Constants_ErrorCodes::LOCK_IS_USED); } //redis返回null,是网络、机器授权、语法错误等等 if(is_null($setRet)){ //网络错误、异常 throw new Exception("Request Redis Failed",Constants_ErrorCodes::REDIS_ERROR); } return $setRet ; } /** * @brief 解除对某个key的锁定,原则上不需要关心返回值,可以多次调用 * * @return * 1 redis会话成功,并且成功删除了key * 0 redis会话成功,但是待删除的key已经不存在 * */ public function unlock(){ //Reids 2.6 版本增加了对 Lua 环境的支持,解决了长久以来不能高效地处理 CAS (check-and-set)命令的缺点 $luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" ; $delRet = $this->_objRedis->eval($luaScript,array($this->_redisKey,$this->_guid),1); if(is_null($delRet)){ //redis返回null,是网络、机器授权、语法错误等等 throw new Exception("Request Redis Failed",Constants_ErrorCodes::REDIS_ERROR); } return $delRet ; } }
代码写出来之后是否解决了上面的问题呢?我们来看一下单机和集群 Redis 方案下的使用。
阅读全文请扫描
下方二维码,
还可以加入读者圈与作者聊天~:
以上是关于分布式锁的技术选型及思考的主要内容,如果未能解决你的问题,请参考以下文章