DISCARD 거래 취소, 거래 실행 포기 블록 내 모든 명령. |
|
EXEC
모든 트랜잭션 블록 내에서 명령을 실행합니다. |
|
MULTI
거래 블록의 시작을 표시합니다. |
|
UNWATCH
WATCH 명령으로 모든 키의 모니터링을 취소합니다. |
|
WATCH key [key …]
하나 이상의 키를 모니터링합니다. 트랜잭션이 실행되기 전에 이 키(또는 이러한 키)가 다른 명령에 의해 변경되면 트랜잭션이 중단됩니다. |
|
Case
정상실행
거래 포기
모두 연속
오류, 모두 연속, 실행되지 않음
적의 채권자
이 문제에 대해 Redis의 트랜잭션 지원을 이해하는 방법
Redis는 트랜잭션을 부분적으로 지원합니다. 이 부분에서는 올바른 트랜잭션은 실행되고 잘못된 트랜잭션은 실행되지 않습니다.
case: 감시 모니터링
비관적 잠금. /optimistic lock/CAS( 확인 및 설정)
Pessimistic Lock은 이름에서 알 수 있듯이 매우 비관적입니다. 데이터를 얻으러 갈 때마다 다른 사람이 데이터를 수정할 것이라고 생각하므로 매번 잠그게 됩니다. 당신이 데이터를 얻으면 다른 사람들도 그것을 얻고 싶어할 것입니다. 이 데이터는 잠금을 얻을 때까지 차단됩니다. 이러한 많은 잠금 메커니즘은 행 잠금, 테이블 잠금, 읽기 잠금, 쓰기 잠금 등과 같은 기존 관계형 데이터베이스에서 사용되며 작업 전에 모두 잠깁니다.
테이블 잠금: 테이블 전체를 잠급니다. 그러나 이 테이블에는 많은 양의 데이터가 있을 수 있습니다. 이때 프로세스는 대규모 변경을 수행해야 하므로 대기하는 스레드가 점점 더 많아집니다.
행 잠금: 각 레코드를 잠급니다.
낙관적 잠금
낙관적 잠금(Optimistic Lock)은 이름에서 알 수 있듯이 매우 낙관적입니다. 데이터를 얻으러 갈 때마다 다른 사람이 수정하지 않을 것이라고 생각합니다. 잠그지만 업데이트할 때 이 기간 동안 다른 사람이 데이터를 업데이트했는지 여부를 판단합니다. 버전 번호와 같은 메커니즘을 사용할 수 있습니다. 낙관적 잠금은 처리량을 향상시킬 수 있는 다중 읽기 애플리케이션 유형에 적합합니다.
낙관적 잠금 전략: 업데이트를 수행하려면 제출된 버전이 현재 레코드 버전보다 커야 합니다.
낙관적 잠금은 맹목적으로 낙관적이지 않습니다. 예를 들어 Zhang San은 WeChat 계정을 변경하고 Li Si는 QQ 계정을 변경합니다. 동시에 처음에는 버전 번호가 모두 1 이었고 Zhang San이 WeChat ID 변경을 완료하고 제출했습니다. 이때 버전 번호가 1에서 2로 변경되었습니다. Li Si도 수정을 마친 후 제출했습니다. 이때 1에서 3으로 변경하면 예외가 발생하여 다시 수정됩니다.
낙관적 잠금은 일반적으로 직장에서 사용됩니다
신용 카드의 사용 가능한 잔액과 미결제 잔액을 초기화하는 데 사용됩니다
조작하지 말고 먼저 모니터링한 다음 멀티를 열어 두 금액 변경이 동일한 거래 내에서 이루어지도록 하세요.
모니터링 중 다른 트랜잭션이 공유 데이터를 수정하여 트랜잭션 실행이 실패하는 것으로 확인되었습니다. 데이터를 수정하기 전에 시계를 잠가야 합니다. 그렇지 않으면 오류가 발생합니다. 누군가 내 데이터를 수정하면 예외를 보고하겠습니다.
위조가 있습니다
키가 모니터링됩니다. 키가 수정되면 다음 트랜잭션 실행이 무효화됩니다.
unwatch
watch 명령으로 모든 키 모니터링을 취소합니다 모니터링이 완료되면 exec가 실행되기 전에 추가된 잠금은 취소됩니다
요약
관찰 명령은 낙관적 잠금과 유사하며, 트랜잭션이 커밋될 때 키 값이 다른 클라이언트에 의해 변경된 경우(예: 목록이 변경된 경우) 다른 클라이언트에 의해 푸시/팝되면 전체 트랜잭션 큐가 실행되지 않습니다. 트랜잭션이 실행되기 전에 WATCH 명령을 통해 여러 키를 모니터링합니다. WATCH 이후 키 값이 변경되면 EXEC 명령으로 실행된 트랜잭션이 중단됩니다. 그리고 Nullmulti가 반환됩니다. 호출자에게 트랜잭션 실행이 실패했음을 알리는 대량 응답
3단계
• 열기: MULTI로 트랜잭션 시작 • 대기열에 추가: 여러 명령을 트랜잭션에 추가합니다. 대신, 실행을 기다리는 트랜잭션 큐에 배치됩니다
• 실행: EXEC 명령에 의해 트랜잭션이 트리거됩니다
3 특징
개별 격리 작업: 트랜잭션의 모든 명령이 직렬화되고 순서대로 실행됩니다. 트랜잭션이 실행되는 동안 다른 클라이언트가 보낸 명령 요청으로 인해 중단되지 않습니다. 격리 수준에 대한 개념이 없습니다. 대기열에 있는 명령은 제출될 때까지 실제로 실행되지 않습니다. 트랜잭션이 제출되기 전에 실제로 명령이 실행되지 않기 때문입니다. 따라서 트랜잭션 내에서 트랜잭션 외부에서 쿼리하면 업데이트를 볼 수 없습니다. 이것은 매우 골치 아픈 문제입니다
원자성이 보장되지 않습니다. 동일한 Redis 트랜잭션에서 명령이 실행되지 않으면 후속 명령은 롤백 없이 계속 실행됩니다. 기존 ACID에서는 AI를 따르지 않습니다