|
分布式锁是一个在分布式环境中重要的原语，它表明不同进程间采用互斥的方式操作共享资源。本文将谈谈分布式相关的内容。 文章来源：360技术 原创作者：曹思远 分布式锁概述 从进程锁到分布式锁 在单进程环境中，为了 防止多线程同时对共享资源进行读写操作，我们通常使用内核或者类库实现线程间的互斥。 当扩展到分布式系统下，我们需要提供相同功能的分布式锁服务，不同的主机通过该服务获取一把锁，而获取该锁的机器就可以排他性的访问共享资源。 在单机环境下，操作系统知道自己进程的状态，当进程挂掉的时候该进程会释放自己持有的锁资源，但在分布式环境下，存在宕机、网络分区、时延等各种异常状态，因此需要给分布式锁提供新的特性：可用性。 分布式锁的系统分类 基于锁资源的安全性，可以将分布式锁分为以下两部分： 基于异步复制的分布式系统，例如：redis、mysql基于paxos协议的分布式一致性系统，例如：etcd、zookeeper 基于异步复制的分布式系统，存在丢锁的风险，不够安全，通常使用TTL机制承担细粒度的锁服务，该系统接入简单，适用于对事件很敏感，期望设置一个较短的有效时间，执行短期任务，丢锁对业务影响相对可控的服务。 基于paxos协议的分布式系统，通过一致性协议保证数据的多副本，数据的安全性高，通常使用lease机制承担粗粒度的锁服务，适用于对安全性很敏感，希望长期持有锁，不希望发生丢锁现象的服务。 基于 redis 的分布式锁 通常可以使用setnx（ set if n ot e x ists）实现排他的获取锁操作，但是由于分布式系统中进程可能随时宕机，因此获取锁时，需要添加TTL保证锁不会因为进程挂掉之后变成死锁状态，但是此时又出现了第二个问题，那就是setnx和expire操作必须是原子操作，因为setnx之后，如果进程挂掉，expire有可能没有机会执行，这同样会导致死锁。正确的操作如下： SET lock_name value NX EX lock_timeEX second：设置 key 的过期时间，单位是秒NX：当 key 不存在的时候进行设置，等同于 SETNX 操作 释放锁时，只需要调用DEL命令删除锁即可： DEL lock_name 需要注意的是，这里有可能出现错误删除锁的问题。场景如下： 进程A加锁成功，锁超时时间20秒。由于进程A业务逻辑执行过长，20秒之后，锁过期自动释放。此时进程B接着加锁，加锁成功后，执行业务逻辑。这期间，进程A结束执行，使用DEL释放锁。 这样就导致进程A错误的释放进程B的锁。因此，为了QQ靓号出售平台不被错误的释放锁，我们在加锁的时候需要设置UUID。例如： SET lock_name uuid NX EX lock_time 释放锁时，需要先获取锁的UUID，如果是自己分配的，则释放锁。但是这里的比较和释放操作必须是原子操作，否则会出现获获取锁比对的时候正确，此时正好TTL过期，另一个进程加锁成功，这样的话还是会出现错误释放锁的操作。可以使用Lua脚本实现判断与删除的原子操作。 基于 etcd/zookeeper 的分布式锁 排他锁（exclusive locks） 排他锁（写锁、独占锁）表现如下： 进程p1对数据d1加上排他锁，那么在整个加锁期间，只允许进程p1对数据d1进行读取和更新操作，其他任何进程都不能再对整个数据进行任何类型的操作。直到p1释放排他锁。 通过在zk/etcd上的数据节点来表示一个锁 上面/exclusive_lock/lock1节点，就可以被定义为一个锁。 获取锁： 创建排他锁：需要获取排他锁的时候，所有的客户端都会试图调用create()接口，在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock1。zk/etcd会保证在所有的客户端中，最终只有一个客户端能够创建成功，那么就可以为该客户端获取锁。watch排他锁：所有没有成功获取锁的客户端就要到/exclusive_lock节点上注册一个子节点变更的watcher监听，用于实时监听lock1节点的变更情况。 释放锁即移除该临时节点。由于 /exclusive _lock/lock1是一个临时节点（et cd通过租约，通过发送心跳来续租），因此需要考虑以下情况 ： 已经获取锁的client发生了宕机，那么zk/etcd上整个临时节点就会被移除正常完成业务之后，client会主动删除临时节点 无论在什么情况下移除lock节点，zk/etcd都会通知所有watcher /exclusive_lock的客户端。这些客户端在接受到通知之后，再次重新发起分布式锁获取，即重复获取锁过程。 共享锁（shared locks） 共享锁（读锁）表现如下： 进程p1对数据d1加上共享锁，那么当前事务只能对d1进行读取操作，其他事务也只能对整个数据加共享锁，直到该数据对象上的所有共享锁都被释放。 与排他锁的区别是，加上排他锁之后，数据只对一个事务可见，而加上共享锁之后，数据对所有事务可见。 定义锁： 同样是通过zk/etcd上的数据节点表示一个锁，格式可以参考/shared_lock/[hostname]-请求类型-序号 的临时节点。 例如：下图中/shared_lock/host1-R-001就代表了一个共享锁 需要获取共享锁时，所有客户端都会到/shared_lock整个节点下创建一个临时顺序节点。 如果当前是读请求，创建/shared_lock/192.168.0.1-R-01节点如果是写请求，创建/shared_lock/192.168.0.1-W-02节点 根据共享锁的定义， 不同的事务可以对同一数据对象进行读取操作更新操作必须在当前没有任何事务进行读写操作的情况下进行 zk/etcd的读写顺序： 创建完节点，获取/shared_lock节点下的所有子节点，并对该节点注册子节点变更的watcher监听确定自己的节点序号，在所有子节点中的顺序对于读请求：如果没有比自己小的子节点，或者所有比自己小的子节点都是读请求，那么自己已经成功获取到共享锁，可以开始业务逻辑如果比自己小的节点中有写请求，那么需要进入等待对于写请求：如果自己不是序号最小的子节点，那么就需要进入等待接收到watcher通知后，重复步骤1 释放锁与排他锁是一致的： 例子： 主机10.16.0.1先进行读操作，完成后，将节点/shared_lock/10.16.0.1-R-000001删除剩余4台机器均收到节点移除通知，然后重新从/shared_lock节点上获取一份新的子节点列表每个主机判读自己的读写顺序。接着，主机10.16.0.2检测到自己已经是需要最小的了，于是开始执行写操作，而其他主机发现没有轮到自己进行读取或者更新操作，于是继续等待继续上面循环 |
|
|
来自： 新用户26922hFh > 《待分类》
