Redis에서 분산 잠금을 구현할 때 주의해야 할 사항은 무엇입니까? [주의사항 요약]

Redis에서 분산 잠금을 구현할 때 주의해야 할 사항은 무엇인가요? 다음 문서에서는 Redis를 분산 잠금으로 사용할 때 주의해야 할 몇 가지 사항을 요약하고 공유하겠습니다. 도움이 되기를 바랍니다.

Redis는 분산 잠금을 구현합니다

최근에 분산 잠금을 읽는 과정에서 좋은 기사를 보고 제가 이해한 바를 특별히 정리했습니다.

Redis 분산 잠금 구현의 세 가지 측면 핵심 요소:

1. 잠그는 가장 쉬운 방법은

setnx 명령을 사용하는 것입니다. 키는 비즈니스에 따라 이름이 지정된 잠금의 고유 식별자입니다. 값은 현재 스레드의 스레드 ID입니다. [관련 권장사항: Redis 동영상 튜토리얼]

예를 들어 제품의 플래시 세일 활동을 잠그고 싶다면 키 이름을 "lock_sale_ID"로 지정할 수 있습니다. 그리고 값은 어떻게 설정되나요? 일시적으로 1로 설정할 수 있습니다. 잠금을 위한 의사 코드는 다음과 같습니다.

setnx(key, 1)스레드가 setnx를 실행하면 1이 반환되어 다른 스레드가 성공적으로 잠금을 획득했음을 나타냅니다. setnx에서는 0을 반환하며 이는 키가 이미 존재하고 스레드가 잠금을 확보하는 데 실패했음을 나타냅니다.

2. 잠금 해제

잠그려면 잠금을 해제해야 합니다. 잠금을 획득한 스레드가 작업을 완료하면 다른 스레드가 들어갈 수 있도록 잠금을 해제해야 합니다. 잠금을 해제하는 가장 간단한 방법은 del 명령을 실행하는 것입니다. 의사 코드는 다음과 같습니다.

del(key) 잠금이 해제된 후에도 다른 스레드는 계속해서 setnx 명령을 실행하여 잠금을 얻을 수 있습니다. 자물쇠.

3. 잠금 시간 초과

잠금 시간 초과는 무엇을 의미하나요? 작업을 실행하는 동안 잠금을 획득한 스레드가 종료되고 잠금을 명시적으로 해제할 시간이 없으면 리소스는 영원히 잠기고 다른 스레드는 다시는 들어올 수 없습니다.

따라서 setnx의 키는 명시적으로 해제되지 않더라도 일정 시간이 지나면 자동으로 잠금이 해제되도록 제한 시간을 설정해야 합니다. setnx는 시간 초과 매개변수를 지원하지 않으므로 추가 지침이 필요합니다.

expire (key, 30) 종합하면, 분산 잠금 구현을 위한 첫 번째 의사코드 버전은 다음과 같습니다.

if（setnx（key，1） == 1）{
    expire（key，30）
    try {
        do something ......
    }catch()　　{　　}　　finally {
       del（key）
    }

}

위의 내용 때문에 의사 코드에는 세 가지 치명적인 문제가 있습니다.

1. setnx의 비원자성 및 만료

스레드가 setnx를 실행하고 성공적으로 잠금을 획득하는 극단적인 시나리오를 상상해 보세요.

setnx가 방금 성공적으로 실행되었습니다. 만료 명령이 실행되기 전에 노드 1이 Duang 소리와 함께 종료되었습니다.

if（setnx（key，1） == 1）{　　//此处挂掉了.....
    expire（key，30）
    try {
        do something ......
    }catch()
　　{
　　}
　　finally {
       del（key）
    }
 
}

이렇게 하면 잠금에는 만료 시간이 설정되지 않고 "불멸" 상태가 되며 다른 스레드는 더 이상 잠금을 얻을 수 없습니다.

어떻게 해결하나요? setnx 명령 자체는 수신 시간 제한을 지원하지 않습니다. Redis 2.6.12 이상에서는 set 명령에 선택적 매개변수를 추가합니다. 의사 코드는 set(key, 1, 30, NX)이며 setnx를 대체할 수 있습니다. .

2. 시간 초과 후 del을 사용하면 실수로 다른 스레드의 잠금이 삭제됩니다.

이것은 스레드가 성공적으로 잠금을 획득하고 시간 초과가 30초로 설정되었다고 가정합니다. .

어떤 이유로 스레드 A가 매우 느리게 실행되고 30초 후에도 실행이 완료되지 않으면 만료 시 잠금이 자동으로 해제되고 스레드 B가 잠금을 획득합니다.

이후 스레드 A는 작업을 완료하고 스레드 A는 del 명령을 실행하여 잠금을 해제합니다. 그러나 현재 스레드 B는 실행이 완료되지 않았습니다. 스레드 A는 실제로 스레드 B에 의해 추가된 잠금을 삭제합니다.

이 상황을 피하는 방법은 무엇입니까? del이 잠금을 해제하기 전에 판단하여 현재 잠금이 사용자가 추가한 잠금인지 확인할 수 있습니다.

구체적인 구현은 잠금 시 현재 스레드 ID를 값으로 사용할 수 있으며, 삭제하기 전에 키에 해당하는 값이 자신의 스레드 ID인지 확인하면 됩니다.

加锁：
String threadId = Thread.currentThread().getId()
set（key，threadId ，30，NX）
doSomething.....
 
解锁：
if（threadId .equals(redisClient.get(key))）{
    del(key)
}

그러나 그렇게 하면 새로운 문제가 발생합니다. 판단과 잠금 해제가 원자가 아닌 두 개의 독립적인 작업이라면.

우리는 모두 완벽을 추구하는 프로그래머이므로 이 부분은 Lua 스크립트를 사용하여 구현해야 합니다:

String luaScript = 'if redis.call('get', KEYS[1]) == ARGV[ 1] 그런 다음 redis.call('del', KEYS[1]) else return 0 end';

redisClient.eval(luaScript , Collections.singletonList( key), Collections.singletonList(threadId));

이런 방식으로 확인 및 삭제 프로세스는 원자적 작업입니다.

3. 동시성

还是刚才第二点所描述的场景，虽然我们避免了线程A误删掉key的情况，但是同一时间有A，B两个线程在访问代码块，仍然是不完美的。

怎么办呢？我们可以让获得锁的线程开启一个守护线程，用来给快要过期的锁“续航”。

当过去了29秒，线程A还没执行完，这时候守护线程会执行expire指令，为这把锁“续命”20秒。守护线程从第29秒开始执行，每20秒执行一次。

当线程A执行完任务，会显式关掉守护线程。

另一种情况，如果节点1 忽然断电，由于线程A和守护线程在同一个进程，守护线程也会停下。这把锁到了超时的时候，没人给它续命，也就自动释放了。

 memcache实现分布式锁

首页top 10, 由数据库加载到memcache缓存n分钟
微博中名人的content cache, 一旦不存在会大量请求不能命中并加载数据库
需要执行多个IO操作生成的数据存在cache中, 比如查询db多次
问题
在大并发的场合，当cache失效时，大量并发同时取不到cache，会同一瞬间去访问db并回设cache，可能会给系统带来潜在的超负荷风险。我们曾经在线上系统出现过类似故障。

解决方法

if (memcache.get(key) == null) {
// 3 min timeout to avoid mutex holder crash
if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
value = db.get(key);
memcache.set(key, value);
memcache.delete(key_mutex);
} else {
 
sleep(50);
retry()；
}
}

在load db之前先add一个mutex key, mutex key add成功之后再去做加载db, 如果add失败则sleep之后重试读取原cache数据。为了防止死锁，mutex key也需要设置过期时间。伪代码如下

Zookeeper实现分布式缓存

Zookeeper的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫做Znode。

Znode分为四种类型：

• 1.持久节点 （PERSISTENT）

默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在 。

• 2.持久节点顺序节点（PERSISTENT_SEQUENTIAL）

所谓顺序节点，就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号：

• 3.临时节点（EPHEMERAL）

和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除：

• 4.临时顺序节点（EPHEMERAL_SEQUENTIAL）

顾名思义，临时顺序节点结合和临时节点和顺序节点的特点：在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。

Zookeeper分布式锁恰恰应用了临时顺序节点。具体如何实现呢？让我们来看一看详细步骤：

• 获取锁

首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端想要获得锁时，需要在ParentLock这个节点下面创建一个临时顺序节点 Lock1。

之后，Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。

这时候，如果再有一个客户端 Client2 前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock2。

Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。

그래서 Client2는 Lock1를 모니터링하기 위해 자신보다 순위가 높은 Lock1 노드에 Watcher를 등록합니다. > > 노드가 존재하는지 여부. 이는 Client2가 잠금 획득에 실패하여 대기 상태에 들어갔다는 의미입니다. Client2向排序仅比它靠前的节点Lock1注册Watcher，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。

这时候，如果又有一个客户端Client3前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock3。

Client3查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock3是不是顺序最靠前的一个，结果同样发现节点Lock3并不是最小的。

于是，Client3向排序仅比它靠前的节点Lock2注册Watcher，用于监听Lock2节点是否存在。这意味着Client3同样抢锁失败，进入了等待状态。

这样一来，Client1得到了锁，Client2监听了Lock1，Client3监听了Lock2。这恰恰形成了一个等待队列，很像是Java当中ReentrantLock所依赖的AQS（AbstractQueuedSynchronizer）。

• 释放锁

释放锁分为两种情况：

1.任务完成，客户端显示释放

当任务完成时，Client1会显示调用删除节点Lock1的指令。

2.任务执行过程中，客户端崩溃

获得锁的Client1在任务执行过程中，如果Duang的一声崩溃，则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。

由于Client2一直监听着Lock1的存在状态，当Lock1节点被删除，Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁。

同理，如果Client2也因为任务完成或者节点崩溃而删除了节点Lock2，那么Cient3就会接到通知。

最终，Client3

이때, 다른 클라이언트 Client3가 잠금을 획득하면 ParentLock에 임시 시퀀스 노드 Lock3를 다운로드하고 생성합니다.

Client3 ParentLock 아래의 모든 임시 시퀀스 노드를 찾아 정렬하고, 생성한 Lock3 노드가 가장 높은 순서를 갖는 노드인지 판단합니다. Lock3 노드가 가장 작지 않습니다.

그래서 Client3는 Lock2를 모니터링하기 위해 자신보다 순위가 높은 Lock2 노드에 Watcher를 등록합니다. 노드가 존재하는지 여부. 이는 Client3도 잠금 획득에 실패하여 대기 상태에 들어갔다는 의미입니다.

이런 식으로, Client1이 잠금을 받았고, Client2가 Lock1을 듣고, Client3가 Lock2를 들었습니다. . 이는 Java에서 ReentrantLock이 의존하는 AQS(AbstractQueuedSynchronizer)와 매우 유사하게 대기 대기열을 형성합니다.

• 잠금 해제

잠금을 해제하는 상황은 두 가지가 있습니다.

1 작업이 완료되면 클라이언트가 해제를 표시합니다. 작업이 완료되면 Client1이 호출을 표시합니다. 노드 Lock1 지시문을 삭제합니다.

🎜🎜🎜2. 프로세스 중에 잠금을 획득한 클라이언트 🎜🎜Client1가 충돌합니다. 작업 실행 중에 Duang이 충돌하면 Zookeeper 서버와의 링크가 끊어집니다. 임시 노드의 특성에 따라 관련 노드인 Lock1은 자동으로 삭제됩니다. 🎜🎜🎜🎜 Client2는 Lock1의 존재 상태를 모니터링하고 있습니다. Lock1 노드가 삭제되면 Client2는 즉시 알림을 받게 됩니다. 이때 Client2는 자신이 생성한 Lock2 노드가 현재 가장 작은 노드인지 확인하기 위해 ParentLock 아래의 모든 노드를 다시 쿼리합니다. 가장 작은 경우에는 Client2가 자연스럽게 잠금을 획득합니다. 🎜🎜🎜🎜마찬가지로 Client2는 작업 완료 또는 노드 충돌로 인해 노드 Lock2도 삭제한 다음 Cient3에 알림을 보냅니다. 🎜🎜🎜🎜마지막으로 Client3이(가) 성공적으로 잠금을 획득했습니다. 🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜Zookeeper와 Redis 분산 잠금의 비교🎜🎜다음 표에는 Zookeeper와 Redis 분산 잠금의 장단점이 요약되어 있습니다.🎜🎜🎜🎜🎜🎜🎜🎜더 많은 프로그래밍 관련 지식을 제공해 주세요. 방문하다 : 🎜프로그래밍 시작하기🎜! ! 🎜

위 내용은 Redis에서 분산 잠금을 구현할 때 주의해야 할 사항은 무엇입니까? [주의사항 요약]의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!