Redis에서 트랜잭션 메커니즘과 낙관적 잠금을 구현하는 방법-PHP 튜토리얼-php.cn

Redis에서 트랜잭션 메커니즘과 낙관적 잠금을 구현하는 방법

小云云

풀어 주다： 2023-03-17 22:14:01

원래의

2590명이 탐색했습니다.

Redis 트랜잭션 메커니즘 MySQL과 같은 다른 데이터베이스에서 트랜잭션은 일련의 작업을 나타냅니다. 이 작업 세트는 모두 실행되거나 전혀 실행되지 않습니다. 이 글에서는 주로 Redis의 트랜잭션 메커니즘과 낙관적 잠금을 소개합니다. 트랜잭션 실행을 통한 Redis의 낙관적 잠금 분석은 이를 필요로 하는 친구가 모두에게 도움이 될 수 있기를 바랍니다.

Redis의 현재 지원은 비교적 간단합니다. Redis는 클라이언트가 시작한 트랜잭션의 명령이 중간에 다른 클라이언트 명령을 삽입하지 않고도 지속적으로 실행될 수 있다는 것만 보장할 수 있습니다. 클라이언트가 링크에서 다중 명령을 실행하면 링크는 트랜잭션 컨텍스트로 들어갑니다. 연결의 후속 명령은 즉시 실행되지 않지만 exec 명령이 실행되면 먼저 대기열에 배치됩니다. 대기열의 모든 명령.

Multi 开启事务：
127.0.0.1:6379[1]> multi #开启事务
OK
127.0.0.1:6379[1]> set age 15 #数据操作命令
QUEUED
127.0.0.1:6379[1]> set age 20 #数据操作命令
QUEUED
127.0.0.1:6379[1]> exec #执行事务
1) OK
2) OK
127.0.0.1:6379[1]> get age
"20"
Discard：取消事务，该命令实际是清空事务队列中的命令并退出事务上下文，也就是事务回滚。
127.0.0.1:6379[1]> get age
"20"
127.0.0.1:6379[1]> multi 
OK
127.0.0.1:6379[1]> set age 25
QUEUED
127.0.0.1:6379[1]> set age 30
QUEUED
127.0.0.1:6379[1]> discard #清空事务队列
OK
127.0.0.1:6379[1]> get age
"20"

로그인 후 복사

redis 트랜잭션 문제에 주의하세요. 일반적으로 트랜잭션 대기열에서 트랜잭션이 실패하면 전체 트랜잭션이 롤백되지만 다른 트랜잭션 명령은 Redis에서 롤백되지 않습니다.

낙관적 잠금: Redis는 대부분 데이터 버전(version)의 기록 메커니즘을 기반으로 구현됩니다. 이는 데이터에 버전 식별자를 추가하는 것입니다. 데이터베이스 테이블을 기반으로 하는 버전 솔루션에서는 일반적으로 데이터베이스 테이블에 버전 필드를 추가하여 이를 수행합니다. 데이터를 읽을 때 이 버전 번호를 함께 읽고, 나중에 업데이트할 때 이 버전 번호에 1을 추가하세요. 이때 제출된 데이터의 버전 번호를 데이터베이스 테이블의 해당 레코드의 현재 버전 번호와 비교하여 제출된 데이터의 버전 번호가 데이터베이스의 현재 버전 번호보다 높으면 업데이트됩니다. 그렇지 않으면 만료된 데이터로 간주됩니다.

watch 모니터링: watch 명령은 주어진 키를 모니터링합니다. exec 중에 watch를 호출한 이후 모니터링되는 키가 변경된 경우 전체 트랜잭션이 실패합니다. 또한 watch를 여러 번 호출하여 여러 키를 모니터링할 수 있으므로 지정된 트랜잭션 키에 낙관적 잠금이 추가됩니다. watch 키는 전체 링크에 유효하며 트랜잭션에서도 마찬가지입니다. 링크가 끊어지면 시계와 거래가 모두 자동으로 지워집니다. 물론 exex, Discard 및 unwatch 명령은 링크의 모든 모니터링을 자동으로 지웁니다.

Redis에서 낙관적 잠금 구현:

age 키가 있다고 가정하면 두 개의 세션을 열어 age에 값을 할당합니다.

session1:

127.0.0.1:6379> get age
"10"
127.0.0.1:6379> watch age #打开对age键的监控（监控其他操作是否对age键有修改操作）
OK
127.0.0.1:6379> multi #开启事务上下文
OK

로그인 후 복사

session2:

127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> get age
"20"

로그인 후 복사

session2에서 age를 직접 조작합니다.

session1을 다시 살펴보세요:

127.0.0.1:6379> set age 30 #在session2中操作age后，我们在session1中继续操作age
QUEUED
127.0.0.1:6379> exec #执行事务 返回nil 事务执行不成功。
(nil)
127.0.0.1:6379> get age
"20"

로그인 후 복사

여기서 우리는 session1의 데이터 버전이 이미 성공적으로 실행될 수 없다는 것을 발견했습니다. 데이터베이스 데이터 버전보다 작습니다. 이는 Redis의 낙관적 잠금입니다.