Redis 단일 스레드를 잠가야 하는 이유는 무엇입니까?

개인적으로 이해하기로는 redis는 단일 스레드이지만 여러 클라이언트가 동시에 액세스할 수 있으며 각 클라이언트는 하나의 스레드를 갖습니다. 클라이언트 액세스 간에 경쟁이 있습니다.

여러 클라이언트가 동시에 존재하므로 작업의 원자성이 보장되어야 합니다. 예를 들어, 은행 카드 공제의 경우 잔액 확보, 판단, 공제 및 환급이 거래로 구성되어야 하며, 그렇지 않으면 오류가 발생할 수 있습니다.

기존 독립형 애플리케이션 배포의 경우 ReentrantLcok 또는 동기화와 같은 Java 동시성 관련 잠금을 사용할 수 있습니다. 상호 배제 제어를 위해. 그러나 비즈니스 개발의 요구에 따라 원래의 단일 머신 배포 시스템은 동시에 서비스를 제공하기 위해 여러 머신과 여러 JVM에 점차적으로 배포되었으며 이로 인해 원래 단일 머신 배포의 동시성 제어 잠금 전략이 유효하지 않게 되었습니다. 이 문제는 공유 리소스에 대한 액세스를 제어하기 위해 JVM 간 상호 배제 메커니즘이 필요합니다. 이것이 분산 잠금이 해결하려는 문제입니다. (추천 학습: Redis 동영상 튜토리얼)

분산 잠금 구현 조건

1. , 단일 애플리케이션과 마찬가지로 언제든지 단 하나의 클라이언트만 잠금을 유지할 수 있도록 해야 합니다

2. 신뢰성, 시스템 안정성 보장 및 교착 상태 방지

3. 일관성, 잠금을 잠근 사람만 잠금을 해제할 수 있고 A의 잠금을 사용자 B가 잠금 해제할 수 없는지 확인하세요.

Redis는 분산 잠금을 구현합니다. 사람마다 문제가 있을 수 있습니다. 구현 논리가 다릅니다. .

분산 환경에서 데이터 일관성 문제는 늘 중요한 화두였지만, 단일 프로세스의 상황과는 다릅니다. 분산형 상황과 독립형 상황의 가장 큰 차이점은 멀티스레드가 아닌 멀티프로세스라는 점입니다. 멀티 스레드는 힙 메모리를 공유할 수 있으므로 메모리를 마크 저장 위치로 간단히 사용할 수 있습니다. 프로세스가 동일한 물리적 시스템에 있지 않을 수도 있으므로 태그는 모든 프로세스가 볼 수 있는 위치에 저장되어야 합니다.

일반적인 깜짝 세일 시나리오는 주문 서비스의 여러 인스턴스가 배포되는 것입니다. 예를 들어, 반짝 세일 품목이 4개 있는 경우 첫 번째 사용자가 3개 품목을 구매하고 두 번째 사용자가 2개 품목을 구매하는 경우 이상적으로는 첫 번째 사용자는 구매에 성공하고 두 번째 사용자에게는 구매 실패 메시지가 표시되며 그 반대의 경우도 마찬가지입니다. . 실제로 일어날 수 있는 상황은 두 사용자 모두 4개의 재고를 갖고 첫 번째 사용자는 3개를 구입하는 것입니다. 재고를 업데이트하기 전에 두 번째 사용자가 2개 품목을 주문하고 재고를 2개로 업데이트하여 오류가 발생합니다.

일반적인 잠금 방식은 다음과 같습니다.

데이터베이스 기반 분산 잠금 구현

캐시 기반 달성 redis와 같은 분산 잠금 잠금

Zookeeper를 기반으로 분산 잠금 구현

Redis 관련 기술 문서를 더 보려면 Redis 데이터베이스 사용 튜토리얼#🎜을 방문하세요. 🎜#칼럼 스터디!

위 내용은 Redis 단일 스레드를 잠가야 하는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!