Redis 분산 잠금을 구현하는 방법과 해당 애플리케이션 시나리오는 무엇입니까?

소개

Lock은 개발 과정에서 매우 일반적인 도구이며, 비관적 잠금, 낙관적 잠금, 배타적 잠금, 공정한 잠금, 불공정 잠금 등 많은 개념에 익숙해야 합니다. Java에 익숙하지 않은 경우, 이 기사를 참조하십시오. 언급해야 할 Java "잠금" 이 기사는 매우 포괄적입니다. 그러나 초보자에게는 이러한 잠금의 개념을 아는 것이 불가능할 수 있습니다. 실제 작업 경험이 부족하기 때문에 잠금의 실제 사용 시나리오를 이해하지 못하는 경우 Volatile, 동기화 및 ReentrantLock 세 가지 키워드를 사용하여 Java에서 스레드 안전성을 얻을 수 있습니다. 1차 기본면접(실력이 있어야 함)

분산 시스템에서 Java 잠금 기술은 두 시스템의 코드를 동시에 잠글 수 없으므로 분산 잠금을 통해 구현해야 합니다. 분산 잠금을 능숙하게 사용하는 것도 주요 개발자가 마스터해야 하는 기술입니다.

1. 인터뷰어:

분산 잠금을 사용해야 하는 시나리오를 경험한 적이 있나요?

문제 분석: 이 질문은 주로 소개로 사용됩니다. 먼저 분산 잠금을 사용해야 하는 시나리오와 분산 잠금이 해결해야 하는 문제가 무엇인지 이해해야 합니다. 이 전제 하에서 구현 원리를 더 잘 이해하는 데 도움이 됩니다. 분산 잠금.

분산 잠금 사용 시나리오는 일반적으로 다음 시나리오를 충족해야 합니다.

• 시스템은 분산 시스템이므로 Java 잠금은 더 이상 잠글 수 없습니다.

• 도서관의 유일한 사용자 데이터 등 공유자원을 운영합니다.

• 동기 액세스, 즉 여러 프로세스가 공유 리소스를 동시에 운영합니다.

답변: 프로젝트에서 분산 잠금을 사용하는 시나리오의 예를 말씀드리겠습니다.

소비 포인트는 신용카드, 전자상거래 웹사이트, 선물 교환 포인트 등을 포함한 다양한 시스템에서 사용할 수 있습니다. 다음은 "소비 지점"의 작업입니다. 이는 잠금이 필요한 일반적인 시나리오입니다.

이벤트 A:

선물용 포인트 사용을 예로 들면 전체 포인트 소비 과정은 간단히 3단계로 나뉩니다.

A1: 사용자가 제품을 선택하고 교환을 시작한 후 주문을 제출합니다.

A2: 시스템은 사용자의 남은 포인트를 판독합니다. 사용자의 현재 포인트가 충분한지 여부를 결정합니다.

A3: 사용자 포인트가 차감됩니다.

이벤트 B:

시스템은 간단한 3단계로 사용자에게 포인트를 분배합니다.

B1: 해당 날짜에 사용자가 받을 수 있는 포인트를 계산합니다.

B2: 사용자의 원래 포인트를 읽습니다.

B3: 이 시간을 원본에 추가합니다. 포인트 포인트 적립

그렇다면, 사용자가 포인트를 소비하는 동시에 포인트가 쌓이면 어떻게 될까요?(사용자 포인트는 동시에 운영됩니다.)

가정: 사용자가 포인트를 소비하는 동안 오프라인 작업은 포인트를 계산하고 사용자에게 포인트를 발급하는 것입니다(예: 그날 사용자의 소비 금액을 기준으로). 이 두 가지 작업이 동시에 수행됩니다. 다음 논리는 약간 복잡하므로 인내심을 갖고 이해하십시오.

사용자 U는 1,000포인트(사용자 포인트를 기록하는 데이터는 공유 자원으로 이해될 수 있음)를 보유하고 있으며, 이번 상환에는 999포인트가 소모됩니다.

잠금 해제 상황: 이벤트 A 프로그램이 포인트를 읽기 위한 2단계에 도달하면 A:2 작업에서 읽은 결과는 1000포인트입니다. 남은 포인트가 이 상환에 충분하다고 판단된 다음 3A 단계가 실행됩니다. 3번의 작업(1000 - 999 = 1)에 대해 포인트가 차감됩니다. 일반 결과는 사용자에게 여전히 1포인트입니다. 하지만 이때 이벤트 B도 실행 중입니다. 이번에는 사용자 U에게 100포인트가 발급됩니다. 두 스레드가 동시에 이를 수행합니다(동기 액세스). A: 2 -> B :2 -> A:3 -> B:3 A:3이 완료되기 전에(점수 차감, 1000 - 999) 이벤트 B의 스레드에서 사용자 U의 총점을 읽습니다. U님의 총 포인트가 1100포인트가 되었는데, 999포인트의 선물을 헛되이 교환했는데, 당연히 기대한 결과에 미치지 못했습니다.

어떤 사람들은 어떻게 이렇게 우연하게도 동시에 사용자 포인트를 운영할 수 있고, CPU도 그렇게 빠르다는 걸까요? 사용자가 충분하고 동시성이 충분히 크면 조만간 머피의 법칙이 적용될 것입니다. 위의 버그가 나타나는 것은 시간 문제일 뿐이며, 블랙 업계에 갇힐 수도 있습니다. 이때 개발자로서 이 숨겨진 위험을 해결하려면 의 사용법을 이해해야 합니다. 잠금 해제.

(코드 작성은 엄격한 작업입니다!)

Java 자체는 두 가지 기본 잠금 구현을 제공합니다. 하나는 JVM에 의해 구현되고 JDK에서 제공되는 잠금은 동기화되며 많은 원자 연산 클래스는 애플리케이션이 스레드 안전합니다. 독립형 또는 단일 프로세스 애플리케이션인 경우 이 두 잠금을 사용하여 잠금을 구현할 수 있습니다.

그러나 현재 대부분의 인터넷 회사 시스템은 코드가 여러 시스템에 배포되기 때문에 Java와 함께 제공되는 동기화 또는 잠금이 더 이상 분산 환경에서 잠금 요구 사항을 충족할 수 없습니다. 이 문제를 해결하기 위해 분산 잠금이 등장했습니다. 분산 잠금의 특성은 다중 프로세스이며 메모리는 여러 물리적 시스템에서 공유될 수 없습니다. 일반적인 솔루션은 메모리 계층의 간섭을 기반으로 합니다. Redis 또는 ZooKeeper 분산 잠금.

(더 자세히 분석할 수 없습니다. 면접관이 더 이상 만족하지 않습니까?)

2. 면접관:

Redis 분산 잠금 구현 방법

현재 분산 잠금 문제를 해결하기 위한 두 가지 주요 구현 방법이 있습니다. 1. 하나는 Redis Cluster 모드를 기반으로 하고, 다른 하나는... 2. Zookeeper 클러스터 모드를 기반으로 합니다.

이 두 가지를 우선적으로 마스터하시면 면접에 기본적으로 문제가 없을 것입니다.

답변:

1. Redis 기반 분산 잠금

방법 1: setnx 명령을 사용하여 잠금

public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {
		// 第一步：加锁
    Long result = jedis.setnx(lockKey, requestId);
    if (result == 1) {
        // 第二步：设置过期时间
        jedis.expire(lockKey, expireTime);
    }
}

코드 설명:

setnx 명령은 lockKey가 존재하지 않는 경우 설정을 의미합니다. 키는 Redis에 저장됩니다. 성공적으로 저장한 후 결과가 1을 반환하면 설정이 성공한 것입니다. 1이 아닌 경우에는 실패했으며 다른 스레드에서 이미 설정했음을 의미합니다. setnx命令，意思就是 set if not exist，如果lockKey不存在，把key存入Redis，保存成功后如果result返回1，表示设置成功，如果非1，表示失败，别的线程已经设置过了。

expire()

expire(), 교착 상태를 방지하기 위해 만료 시간을 설정합니다. 잠금이 설정된 후 삭제되지 않으면 잠금이 항상 존재하는 것과 동일하여 교착 상태가 발생한다고 가정합니다.

(이때 면접관에게도 "하지만"이라는 점을 강조하고 싶습니다)

생각해 보세요. 위의 제 방식의 문제점은 무엇인가요? 계속해서 면접관에게 설명해주세요...

잠금에는 두 단계가 있습니다. 첫 번째 단계는 jedis.setnx이고, 두 번째 단계는 만료 시간을 설정하는 jedis.expire입니다. 프로그램이 첫 번째 단계를 실행하고 예외가 발생합니다. 예, 두 번째 단계 jedis.expire(lockKey,expireTime)가 실행되지 않았습니다. 이는 잠금에 만료 시간이 없으며 교착 상태가 발생할 수 있음을 의미합니다. 이 문제를 개선하는 방법은 무엇입니까?

개선 사항:

public class RedisLockDemo {
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";
    /**
     * 获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean getLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
				// 两步合二为一，一行代码加锁并设置 + 过期时间。
        if (1 == jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime)) {
            return true;//加锁成功
        }
        return false;//加锁失败
    }
}

코드 설명:

잠금 및 만료 시간 설정을 한 줄의 코드, 원자적 작업으로 결합합니다.

(면접관님께서는 추가 질문을 하기 전 매우 만족해하셨습니다.)

3. 면접관: 잠금 해제 작업은 어떻습니까?

답변:

잠금 해제는 키 삭제를 의미합니다

del 명령을 사용하여 잠금 해제

public static void unLock(Jedis jedis, String lockKey, String requestId) {
    // 第一步： 使用 requestId 判断加锁与解锁是不是同一个客户端
    if (requestId.equals(jedis.get(lockKey))) {
        // 第二步： 若在此时，这把锁突然不是这个客户端的，则会误解锁
        jedis.del(lockKey);
    }
}

코드 설명: requestId를 사용하여 잠금 및 잠금 해제가 동일한 클라이언트 및 jedis.del(lockKey)에서 수행되는지 확인합니다. 두 단계는 원자적 작업이 아니며 이론상 첫 번째 if 판단 작업을 실행한 후 잠금이 실제로 만료되어 다른 스레드에 의해 획득된 것으로 나타납니다. 이는 jedis.del(lockKey) 작업을 수행하는 시간이며 이는 동일합니다. 다른 사람의 잠금을 해제하는 것은 불합리합니다. 물론 이는 매우 극단적인 상황입니다. unLock 메소드의 첫 번째 및 두 번째 단계에서 다른 비즈니스 작업이 없으면 위의 코드를 온라인으로 던져도 실제로 문제가 발생하지 않을 수 있습니다. 높지 않으면 이 결함은 전혀 노출되지 않으므로 문제는 크지 않습니다.

하지만 코드 작성은 힘든 작업이고, 완벽하려면 완벽해야 합니다. 위 코드의 문제를 해결하기 위한 개선 사항이 제안되었습니다.

코드 개선:

public class RedisTool {
    private static final Long RELEASE_SUCCESS = 1L;
    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;
    }
}

코드 설명:

제디스 클라이언트의 평가 방법과 단 한 줄의 스크립트를 사용하여 방법 1과 관련된 원자성 문제를 해결하세요.

3. 인터뷰어:

ZooKeeper를 기반으로 한 분산 잠금 구현 원리

답변: 여전히 포인트 소비 및 포인트 적립의 예입니다. 이벤트 A와 이벤트 B는 동시에 포인트를 수정해야 하며 두 머신은 올바른 비즈니스 논리는 한 시스템이 먼저 실행하고 다른 시스템이 먼저 실행되도록 하는 것입니다. 이렇게 하면 A:2 -> 2 -> A는 발생하지 않습니다. :3 -> B:3 포인트를 많이 쓸수록 포인트도 많이 소모됩니다. (이런 버그가 온라인에 올라오면 사장님이 화를 내실 수도 있겠네요.)

무엇을 해야 할까요? 사육사 분산 잠금을 사용하십시오.

머신이 요청을 받은 후 먼저 사육사에 대한 분산 잠금을 획득하고(zk가 znode를 생성함) 작업을 수행한 다음 다른 머신도 znode를 생성하려고 시도하지만 차단되어 생성할 수 없음을 발견합니다. 일단 생성되면 첫 번째 컴퓨터의 실행이 완료될 때까지만 기다렸다가 잠금을 얻을 수 있습니다.

ZooKeeper의 순차 노드 기능을 사용하여 /lock/ 디렉터리에 3개의 노드를 생성하면 ZK 클러스터는 생성된 순서대로 노드를 생성합니다. 노드는 /lock/0000000001, /lock으로 나누어집니다. /0000000002, /lock/ 0000000003, 마지막 숫자는 순차적으로 증가하고 노드 이름은 zk로 완성됩니다.

ZK에도 임시 노드라는 노드가 있습니다. 임시 노드는 클라이언트가 ZK 클러스터에서 연결을 끊으면 자동으로 삭제됩니다. EPHEMERAL_SEQUENTIAL은 임시 시퀀스 노드입니다.

분산 잠금의 기본 논리는 ZK에 노드의 유무를 잠금 상태로 사용하여 분산 잠금을 구현하는 것입니다.

• 클라이언트는 create() 메서드를 호출하여 "/dlm-locks/"라는 파일을 생성합니다. 잠금 이름/잠금 -" 임시 시퀀스 노드.

• 클라이언트는 getChildren("lockname") 메서드를 호출하여 생성된 모든 하위 노드를 가져옵니다.

• 클라이언트가 모든 하위 노드의 경로를 얻은 후 1단계에서 생성한 노드가 모든 노드 중 가장 작은 시퀀스 번호를 갖는 것을 발견하면 생성한 시퀀스 번호가 먼저 순위를 매기는지 확인합니다. 첫 번째, 그 다음에는 이 클라이언트가 잠금을 획득했으며 이전에는 다른 클라이언트가 잠금을 획득하지 않은 것으로 간주됩니다.

• 생성된 노드가 전체 노드 중 가장 작은 노드가 아닌 경우, 생성한 노드보다 시퀀스 번호가 작은 가장 큰 노드를 모니터링한 후 대기 상태로 진입해야 합니다. 모니터링되는 자식 노드가 변경된 후 자식 노드를 획득하고 잠금 획득 여부를 결정합니다.

잠금을 해제하는 과정은 생성된 자식 노드를 실제로 삭제하는 비교적 간단하지만, 노드 삭제 실패 등 비정상적인 상황을 고려해야 합니다.

추가 보충

분산 잠금은 데이터베이스의 문제도 해결할 수 있습니다🎜

方法一：

利用 Mysql 的锁表，创建一张表，设置一个 UNIQUE KEY 这个 KEY 就是要锁的 KEY，所以同一个 KEY 在mysql表里只能插入一次了，这样对锁的竞争就交给了数据库，处理同一个 KEY 数据库保证了只有一个节点能插入成功，其他节点都会插入失败。

这样 lock 和 unlock 的思路就很简单了，伪代码：

def lock ：
    exec sql: insert into locked—table (xxx) values (xxx)
    if result == true :
        return true
    else :
        return false
def unlock ：
    exec sql: delete from lockedOrder where order_id='order_id'

方法二：

使用流水号+时间戳做幂等操作，可以看作是一个不会释放的锁。

위 내용은 Redis 분산 잠금을 구현하는 방법과 해당 애플리케이션 시나리오는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!