MySQL의 낙관적 잠금 추론 인벤토리의 원리는 무엇입니까?

1 기본지식

전자상거래 시스템에서 재고를 공제하는 것은 매우 중요한 작업입니다. 예를 들어 플래시 세일 시스템에서는 판매자가 재고를 100개 설정했지만 종료되는 경우를 방지해야 합니다. 1,000개를 팔아 금전적인 손실을 입게 됩니다. 재고를 차감할 때 일반적으로 사용되는 문은 다음과 같습니다.

udpate goods set stock = stock - #{acquire} 
where sku_id = #{skuId} and stock - #{acquire} >= 0

이 문이 어떻게 재고 자원을 보호하기 위해 재고 초과 판매를 효과적으로 방지할 수 있는지 분석해 보겠습니다. 이 기사의 데모에서는 MySQL Innodb 엔진을 사용하고 격리 수준을 반복 가능한 읽기로 설정합니다.

1.1 공유 잠금 및 배타적 잠금

공유 잠금(share Lock)은 읽기 잠금이라고도 합니다. 공유 잠금을 구현하는 문은 다음과 같습니다.

select lock in share mode

배타적 잠금(배타적 잠금)은 쓰기 잠금이라고도 하며 배타적 잠금을 구현합니다. lock 문은 다음과 같습니다.

select for update
update
delete
insert

공유 잠금과 배타적 잠금의 호환성 관계는 다음과 같습니다.

위의 호환성 관계를 예제를 통해 분석합니다. 먼저 테스트 테이블을 작성하고 테스트 데이터를 작성합니다.

CREATE TABLE `test_account` (
  `id` bigint(20) NOT NULL,
  `name` varchar(20) DEFAULT NULL,
  `account` bigint(20) DEFAULT NULL,
  `version` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert  into `test_account`(`id`,`name`,`account`,`version`) values (1,'A',100,1);
insert  into `test_account`(`id`,`name`,`account`,`version`) values (2,'B',200,1);
insert  into `test_account`(`id`,`name`,`account`,`version`) values (3,'C',300,1);

(1) 읽기 및 읽기 호환

공유 잠금은 공유 잠금과 호환됩니다. 다음 예에서 session1은 t3에서 쿼리를 실행하고 session2는 t4에서 쿼리를 실행하여 예상 결과를 얻습니다. 2) 읽기 및 쓰기 상호 배제

공유 잠금과 배타적 잠금은 상호 배타적입니다. 다음 예에서 session1은 시간 t3에 공유 잠금을 추가하고 결과를 올바르게 읽을 수 있지만 session2는 시간 t에 배타적 잠금을 추가하려고 합니다. 시간 t4이지만 현재 세션 2는 잠금을 점유하고 있습니다. 세션 1이 오랫동안 잠금을 해제하지 않으면 세션 2에서 잠금 시간 초과 예외가 발생합니다.

(3) 쓰기-쓰기 상호 배제

배타적 잠금과 배타적 잠금은 다음과 같이 상호 배타적입니다. 예시에서 session1은 t3 시간에 배타적 잠금을 추가했고 그 결과를 올바르게 읽을 수 있지만 session2는 t4 시간에 배타적 잠금을 추가하려고 시도하지만 현재 세션1이 잠금을 점유하고 있으며 세션2는 기다려야 합니다. 세션1이 오랫동안 잠금을 해제하지 않으면 세션2 잠금 시간 초과 예외가 발생합니다.

1.2 현재 읽기 및 스냅샷 읽기

MySQL Innodb 저장소 엔진 구현은 다중 버전 동시성 제어 프로토콜 MVCC를 기반으로 합니다. MVCC 동시성 제어에서는 읽기 작업을 스냅샷 읽기와 현재 읽기로 나눌 수 있습니다.

스냅샷 읽기에는 잠금이 필요하지 않습니다. 읽혀지는 것은 기록의 보이는 버전이며, 기록 버전일 수도 있습니다. 주문 스냅샷과 유사하게, 사용자가 주문한 후 제품 가격이 변경되더라도 주문 스냅샷은 변경되지 않습니다. 현재 읽기 문은 다음과 같이 구현됩니다.

select

다른 트랜잭션에 의해 수정되지 않고 최신 버전의 레코드를 읽으려면 현재 레코드를 잠가야 합니다. 현재 읽기 문의 구현은 다음과 같습니다.

select lock in share mode
select for update
update
delete
insert

예제를 통해 스냅샷 읽기와 현재 읽기를 분석합니다. Session2는 t4에서 레코드를 수정하고 이를 t5에서 제출합니다. Session1은 t6에서 스냅샷 읽기를 수행하고 결과를 읽습니다. 100. 현재 판독은 t7 시간에 수행되었으며, 최신 버전의 레코드가 판독되었습니다.

현재 판독 프로세스는 어떻습니까? 현재 읽기 프로세스를 분석하기 위해 업데이트를 예로 들어 보겠습니다.

프로그램 인스턴스가 처음으로 현재 읽기 요청을 발행하면 스토리지 엔진이 where 조건을 충족하는 첫 번째 레코드를 반환하고 이를 잠그고, 프로그램 인스턴스가 발행합니다. 업데이트 요청이 다시 발생하고 스토리지로 인해 작업 완료 응답이 성공했습니다. where 조건을 만족하는 모든 레코드가 실행될 때까지 순차적으로 실행합니다.

여기서 몇 가지 확장을 수행합니다. RR 수준은 팬텀 읽기 문제를 방지하기 위한 두 가지 메커니즘을 제공합니다. 첫 번째 방법은 현재 트랜잭션이 시작될 때 스냅샷을 읽는 스냅샷 읽기입니다. 현재 읽기에 대한 한 가지 방법은 가상 읽기를 방지하기 위해 Next-Key Lock 메커니즘을 사용하는 것입니다.

2 낙관적 잠금 원리

위의 지식을 질문을 통해 통합합니다. 다음 명령문을 동시에 실행하는 두 개의 스레드가 있습니다. 레코드 id=1의 계정 값이 두 번 성공적으로 공제됩니까?

update test_account set account = account - 100, version = version + 1 
where id = 1 and version = 1

위 문은 낙관적 잠금을 사용합니다. 우리는 낙관적 잠금이 리소스를 보호한다는 것을 알고 있으므로 두 번 공제되지는 않지만 여기서 멈출 수는 없습니다. 1장의 지식을 바탕으로 추가 분석이 필요합니다.

시간 t2에서 session1과 session2는 동시에 업데이트 작업을 실행하므로 업데이트는 배타적 잠금을 추가하므로 둘 중 하나만 성공할 수 있습니다. session1은 성공하고 session2는 배타적 잠금이 해제될 때까지 대기합니다. .

t3 시점에 session1은 트랜잭션을 커밋하고 배타적 잠금을 해제합니다. 이때 session2는 현재 읽기에 대한 잠금을 획득하지만 이때 id=1인 레코드의 버전 값이 2로 변경되었습니다. 업데이트할 데이터를 쿼리할 수 없으므로 레코드가 갱신되지 않습니다.

3 재고 차감의 원리

2장의 낙관적 잠금 원리를 이해했다면 재고 차감의 원리는 이미 명확합니다. 두 스레드가 동시에 재고 차감을 실행하면 재고가 1개만 남는다고 가정합니다. 때가 되면 일어날 것이다 과매도 상황인가?

t2 시간에 session1과 session2는 updatek를 실행하여 동시에 인벤토리를 줄입니다. 업데이트는 배타적 잠금을 추가하므로 둘 중 하나만 성공할 수 있습니다. session1은 성공하고 session2는 배타적 잠금을 대기합니다. 석방되다.

t3 시간에 session1이 트랜잭션을 커밋하고 독점 잠금을 해제합니다. 이때 session2는 현재 읽기에 대한 잠금을 획득하지만 이때 제품 1의 인벤토리는 0이 되고 (여기서 stock - 1 >) ;= 0) 조건이 더 이상 충족되지 않습니다. 문을 실행합니다. 업데이트할 데이터를 쿼리할 수 없으므로 레코드가 업데이트되지 않습니다.

위 내용은 MySQL의 낙관적 잠금 추론 인벤토리의 원리는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!