트랜잭션의 모든 작업은 데이터베이스에서 분할할 수 없습니다. 모두 완료되거나 아무것도 실행되지 않습니다.
트랜잭션 실행은 데이터를 한 상태에서 다른 상태로 변환합니다. 트랜잭션이 시작되기 전과 트랜잭션이 끝난 후에는 데이터베이스의 무결성 제약 조건을 위반하지 않습니다.
트랜잭션을 격리하려면 각 읽기/쓰기 트랜잭션의 개체가 다른 트랜잭션의 작업 개체와 분리되어야 합니다. 즉, 트랜잭션이 제출되기 전에 다른 트랜잭션에 표시되지 않아야 합니다.
데이터베이스가 트랜잭션을 실행한 후 데이터 수정 사항이 지속되고 저장되어야 합니다. 데이터베이스를 재시작할 때 데이터의 값은 수정된 값이어야 합니다.
Redis 트랜잭션 실행에는 다음과 같은 세 단계가 포함됩니다.
클라이언트는 MULTI 명령을 사용하여 명시적으로 트랜잭션을 시작합니다.
서버는 클라이언트가 보낸 특정 작업(예: 데이터 추가, 삭제, 수정)을 수신하여 트랜잭션에서 실행합니다. 이러한 작업은 Redis 자체에서 제공하는 데이터 읽기 및 쓰기 명령입니다. 이러한 명령은 클라이언트에서 서버로 전송되지만 Redis 인스턴스는 이러한 명령을 명령 대기열에 일시적으로 저장만 하고 즉시 실행하지는 않습니다.
EXEC 명령이 수신되어 실행될 때만 Redis는 트랜잭션을 커밋하고 실제로 트랜잭션 대기열에 있는 모든 명령을 실행합니다.
MULTI: 트랜잭션 열기
EXEC: 트랜잭션을 제출하고 명령 대기열의 모든 작업 명령을 실행합니다.
DISCARD: 트랜잭션을 포기하고 명령 대기열을 지우지만 트랜잭션 롤백을 지원할 수 없습니다.
WATCH: 트랜잭션 실행 중에 하나 이상의 키 값이 변경되는지 감지합니다. 변경된 경우 현재 트랜잭션의 실행이 중단됩니다.
시나리오 1: 트랜잭션이 큐에 추가될 때 트랜잭션을 실행할 때 오류가 보고되면 Redis는 트랜잭션의 원자성을 보장하기 위해 트랜잭션 실행을 중단합니다.
상황 2: 명령이 대기열에 입력될 때 오류가 보고되지 않지만 실제로 실행될 때 오류가 보고됩니다. 트랜잭션의 원자성을 보장할 수 없습니다.
사례 1에 대한 설명 예
127.0.0.1:6379> multi OK 127.0.0.1:6379> set t1 v1 QUEUED 127.0.0.1:6379> set t2 v2 QUEUED 127.0.0.1:6379> setget t3 (error) ERR unknown command 'setget' 127.0.0.1:6379> set t4 v4 QUEUED 127.0.0.1:6379> exec (error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379> get t4 (nil)
설명: exec 명령을 실행하기 전에 구문 오류가 발생하면(존재하지 않는 명령이 사용됨) 명령이 대기열에 추가되면 Redis는 오류를 보고하고 다음을 기록합니다. 오류가 발생하고 Exec 명령이 실행될 때까지 기다립니다. 이후 Redi는 제출된 모든 명령을 거부하고 트랜잭션 실행이 실패합니다. 이 경우 Reid의 트랜잭션은 원자성을 지원할 수 있습니다.
사례 2의 예
127.0.0.1:6379> multi OK 127.0.0.1:6379> incr s2 QUEUED 127.0.0.1:6379> set a1 v1 QUEUED 127.0.0.1:6379> set a2 v2 QUEUED 127.0.0.1:6379> exec 1) (error) ERR value is not an integer or out of range 2) OK 3) OK 127.0.0.1:6379> get a2 "v2"
설명: s2의 값은 v2입니다. incr 명령을 실행할 때 incr은 정수 유형 값만 추가할 수 있기 때문에 오류가 보고됩니다. 그러나 이 경우 Redis 트랜잭션은 그렇지 않은 것으로 나타났습니다. 후속 명령은 성공적으로 실행될 수 있으므로 이 경우 트랜잭션의 원자성을 보장할 수 없습니다.
첫 번째 경우에는 트랜잭션 자체가 포기되므로 트랜잭션의 일관성이 보장될 수 있습니다.
두 번째 경우에는 잘못된 명령은 실행되지 않지만 올바른 명령은 정상적으로 실행될 수 있습니다. , 데이터베이스의 일관성은 변경되지 않습니다.
Redis 지속성이 RDB로 설정된 경우 트랜잭션 실행 시 생성된 RDB 스냅샷이 실행되지 않으므로 트랜잭션 명령 작업의 결과가 저장되지 않습니다. RDB 스냅샷, 복구를 위해 RDB 스냅샷을 사용할 때 데이터베이스의 데이터도 일관됩니다.
Reids 지속성이 AOF로 설정되어 있고 트랜잭션 작업이 AOF 로그에 기록되기 전에 인스턴스가 실패하면 AOF 로그를 사용하여 복원된 데이터베이스 데이터는 일관성이 있습니다. AOF 로그에 일부 작업만 기록된 경우 redis-check-aof를 사용하여 트랜잭션에서 완료된 작업을 지울 수 있으며 복구 후에도 데이터베이스의 일관성이 유지됩니다.
Redis 트랜잭션 격리를 달성하려면 watch 명령을 사용해야 합니다. Watch의 원칙은 트랜잭션이 실행되기 전에 하나 이상의 키 변경 사항을 모니터링할 때 트랜잭션이 실행을 위해 EXEC 명령을 호출할 때 WATCH 메커니즘이 먼저 모니터링된 키가 다른 클라이언트에 의해 수정되었는지 여부를 확인한다는 것입니다. 리스너의 값이 수정되면 트랜잭션 격리가 파기되는 것을 방지하기 위해 트랜잭션 실행이 중단됩니다.
예제 설명
클라이언트 1:
127.0.0.1:6379> get blance "100" 127.0.0.1:6379> watch blance OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> decrby blance 10 QUEUED 127.0.0.1:6379> incrby blance 10 QUEUED 127.0.0.1:6379> exec (nil)
클라이언트 2:
127.0.0.1:6379> get blance "100" 127.0.0.1:6379> set blance 90 OK 127.0.0.1:6379> get blance "90"
설명: 클라이언트 1은 시계를 사용하여 트랜잭션을 시작한 후 잔액 값을 변경하는 작업을 수행하여 다른 클라이언트를 시뮬레이션합니다. 트랜잭션 실행 중에 시계에서 모니터링하는 데이터가 변경된 후 클라이언트 1의 EXEC 명령이 실행되지 않은 것으로 나타났습니다.
Redis 트랜잭션은 지속성을 지원할 수 없습니다. Redis가 RDB 모드를 사용하는 경우 트랜잭션이 실행된 후 다음 RDB 스냅샷이 실행되기 전에 Redis 인스턴스가 충돌하는 경우 트랜잭션에 의해 수정된 데이터가 지속성을 보장할 수 없습니다. Redis는 AOF 모드를 채택하므로 지속성 구성이 no, Everysec 또는 Always인 경우 데이터 손실이 발생할 수 있습니다. 따라서 Redis가 채택하는 지속성 모드에 관계없이 트랜잭션 내구성이 지원되지 않습니다.
위 내용은 Redis 트랜잭션을 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
