Redis 업무를 철저하게 이해하는 데 도움이 되는 기사

이 글은 Redis에 대한 관련 지식을 제공하며, 주로 트랜잭션 관련 내용을 소개합니다. 이는 기본적으로 명령 모음입니다. 트랜잭션은 트랜잭션 실행 프로세스 중에 여러 명령을 동시에 실행하도록 지원합니다. 대기열에서 순차적으로 살펴보겠습니다. 모두에게 도움이 되기를 바랍니다.

추천 학습: Redis 동영상 튜토리얼

Redis 트랜잭션 소개

Redis는 간단한 트랜잭션 기능만 제공합니다. 그 본질은 명령 집합입니다. 트랜잭션은 한 번에 여러 명령의 실행을 지원합니다. 트랜잭션 실행 중에 대기열의 명령은 다른 클라이언트가 제출한 명령 요청이 실행에 삽입되지 않습니다. 이 트랜잭션의 명령 순서입니다. 명령의 실행 과정은 순차적으로 실행되지만 원자성은 보장되지 않습니다. MySQL과 같은 격리 수준이 없으며 문제가 발생한 후 데이터 및 기타 고급 작업을 롤백할 수 있습니다. 이에 대해서는 나중에 자세히 분석하겠습니다.

Redis 기본 트랜잭션 지침

Redis에서는 트랜잭션과 관련된 다음과 같은 기본 지침을 제공합니다.

MULTI가 트랜잭션을 열면 Redis는 EXEC를 사용하여 이러한 명령을 원자적으로 순차적으로 실행할 때까지 실제로 실행하지 않고 대기열에 후속 명령을 추가합니다. EXEC 트랜잭션 블록의 모든 명령 실행DISCARD트랜잭션을 취소하고 트랜잭션 블록의 모든 명령 실행 포기WATCH트랜잭션이 다음과 같은 경우 하나 이상의 키를 모니터링합니다. 실행 전에 이러한 키가 다른 명령에 의해 수정되면 트랜잭션이 종료되고 트랜잭션의 어떤 명령도 실행되지 않습니다. UNWATCH는 WATCH에 의한 모든 키 모니터링을 취소합니다. > 명령 MULTI开启事务，Redis 会将后续命令加到队列中，而不真正执行它们，直到后续使用EXEC来原子化的顺序执行这些命令 EXEC执行所有事务块内的命令 DISCARD取消事务，放弃执行事务块内所有的命令 WATCH监视一个或多个 key，若事务在执行前，这些 key 被其他命令修改，则事务被终端，不会执行事务中的任何命令 UNWATCH取消 WATCH命令对所有 keys 的监视

一般情况下，一个简单的 Redis 事务主要分为如下几个部分：

执行命令MULTI开启一个事务。 开启事务之后，执行命令的多个命令会依次被放入一个队列，放入成功则会返回QUEUED消息。 执行命令EXEC提交事务，Redis 会依次执行队列中的命令，并依次返回所有命令的结果。（若想放弃提交事务，则执行DISCARD）。

下图简单介绍了下 Redis 事务执行的过程：

实例分析

下面我们来通过一些实际具体例子，来体会下 Redis 中的事务。前面我们也说到 Redis 的事务不是正真的事务，是无法完全满足标准事务的ACID

일반 상황 아래에서 간단한 Redis 트랜잭션은 크게 다음과 같은 부분으로 나뉩니다.

트랜잭션을 시작하려면 MULTI 명령을 실행합니다. 트랜잭션이 시작된 후 명령을 실행하는 여러 명령이 순서대로 대기열에 배치됩니다. 배치가 성공하면 QUEUED 메시지가 반환됩니다. 트랜잭션을 제출하려면 EXEC 명령을 실행하세요. Redis는 대기열에 있는 명령을 순서대로 실행하고 모든 명령의 결과를 순서대로 반환합니다. (트랜잭션 커밋을 포기하려면 DISCARD를 실행하세요.)

다음 그림은 Redis 트랜잭션 실행 과정을 간략하게 소개합니다.

예제 분석

몇 가지 실제 사례를 통해 Redis에서 트랜잭션을 경험해 보겠습니다. 또한 앞서 Redis 트랜잭션은 실제 트랜잭션이 아니며 표준 트랜잭션의 ACID 특성을 완전히 충족할 수 없다고 언급했습니다. 다음 예를 통해 Redis의 "파산 버전" 트랜잭션에 어떤 문제점이 있는지 살펴보겠습니다.

[A] 정상적으로 제출을 실행한 후

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
127.0.0.1:6379> SET b 2
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
127.0.0.1:6379> GET a
"1"
127.0.0.1:6379> GET b
"2"

트랜잭션을 연 후 제출된 명령이 대기열(QUEUED)에 추가됩니다. EXEC를 실행한 후 명령이 단계별로 실행되고 결과가 반환됩니다. 이는 트랜잭션 시작 및 커밋과 같이 MySQL에서 일반적으로 사용하는 트랜잭션 작업과 유사해 보입니까?

[B] 정상적으로 거래 취소

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
127.0.0.1:6379> SET b 2
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> 
127.0.0.1:6379> GET a
(nil)
127.0.0.1:6379> GET b
(nil)

거래 개시 후, 거래를 계속하고 싶지 않다면 DISCARD를 이용해 취소해 주세요. 이전에 제출한 명령은 실제로 실행되지 않으며, 관련 키 값은 그대로 유지됩니다. . 이는 또한 트랜잭션 시작 및 롤백과 유사하게 MySQL 트랜잭션과 유사해 보입니다.

[C]WATCH 모니터링 키

-- 线程 1 中执行
127.0.0.1:6379> del a
(integer) 1
127.0.0.1:6379> get a
(nil)
127.0.0.1:6379> SET a 0
OK
127.0.0.1:6379> WATCH a
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
----------------------------------------- 线程 2 中执行
----------------------------------------- 127.0.0.1:6379> SET a 2
----------------------------------------- OK
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> GET a
"2"

트랜잭션을 시작하기 전에 a의 값을 관찰한 후 트랜잭션을 시작하세요. a의 값을 다른 스레드(SET a 2)에 설정한 후 EXEC를 실행하여 트랜잭션을 실행하면 결과가 nil이 되며 이는 트랜잭션이 실행되지 않았음을 의미합니다. WATCH 이후 값이 변경되어 거래가 취소되었습니다.

🎜이는 트랜잭션이 시작된 시간과 아무런 관련이 없으며 MULTI 및 다른 스레드가 a의 값을 설정하는 순서와 관련이 없다는 점에 유의해야 합니다. WATCH 후에 변경되는 한. 트랜잭션 시작 여부와 상관없이 트랜잭션 실행(EXEC) 시에는 트랜잭션이 취소됩니다. 🎜일반적인 상황에서 EXEC 및 DISCARD 명령을 실행하면 기본적으로 UNWATCH가 실행됩니다. 🎜🎜[D] 구문 오류🎜

127.0.0.1:6379> SET a 1
OK
127.0.0.1:6379> SET b 2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 11
QUEUED
127.0.0.1:6379> SETS b 22
(error) ERR unknown command 'SETS'
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> GET a
"1"
127.0.0.1:6379> GET b
"2"

🎜Redis가 트랜잭션을 시작할 때 추가된 명령에 구문 오류가 있으면 트랜잭션 제출이 실패합니다. 이 경우 트랜잭션 대기열의 어떤 명령도 실행되지 않습니다. 위의 예시처럼 a와 b의 값은 모두 원래 값입니다. 🎜명령 이름 오류, 명령 매개 변수 오류 등 EXEC 이전에 발생하는 이러한 종류의 오류는 EXEC가 실행되기 전에 감지됩니다. 따라서 이러한 오류가 발생하면 트랜잭션이 취소되고 트랜잭션에 포함된 모든 명령이 삭제됩니다. 실행되지 않습니다. (이 상황이 약간 롤백처럼 보일까요?) 🎜🎜[E] 런타임 오류🎜

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
127.0.0.1:6379> SET b hello
QUEUED
127.0.0.1:6379> INCR b
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
127.0.0.1:6379> GET a
"1"
127.0.0.1:6379> GET b
"hello"

当 Redis 开启一个事务后，添加的命令没有出现前面说的语法错误，但是在运行时检测到了类型错误，导致事务最提交失败（说未完全成功可能更准确点）。此时事务并不会回滚，而是跳过错误命令继续执行。
如上面的例子，未报错的命令值已经修改，a 被设置成了 1，b 被设置为了 hello，但是报错的值未被修改，即 INCR b 类型错误，并未执行，b 的值也没有被再更新。

Redis 事务与 ACID

通过上面的例子，我们已经知道 Redis 的事务和我们通常接触的 MySQL 等关系数据库的事务还有有一定差异的。它不保证原子性。同时 Redis 事务也没有事务隔离级别的概念。下面我们来具体看下 Redis 在 ACID 四个特性中，那些是满足的，那些是不满足的。
事务执行可以分为命令入队（EXEC 执行前）和命令实际执行（EXEC 执行之后）两个阶段。下面我们在分析的时候，很多时候都会分这两种情况来分析。

原子性（A）

上面的实例分析中，[A]，[B]，[C]三种正常的情况，我们可以很明显的看出，是保证了原子性的。
但是一些异常情况下，是不满足原子性的。

如 [D] 所示的情况，客户端发送的命令有语法错误，在命令入队列时 Redis 就判断出来了。等到执行 EXEC 命令时，Redis 就会拒绝执行所有提交的命令，返回事务失败的结果。此种情况下，事务中的所有命令都不会被执行了，是保证了原子性的。 如 [E] 所示的情况，事务操作入队时，命令和操作类型不匹配，此时 Redis 没有检查出错误（这类错误是运行时错误）。等到执行 EXEC 命令后，Redis 实际执行这些命令操作时，就会报错。需要注意的是，虽然 Redis 会对错误的命令报错不执行，但是其余正确的命令会依次执行完。此种情况下，是无法保证原子性的。 在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。此时，如果开启了 AOF 日志，那么只会有部分事务操作被记录到 AOF 日志中。使用redis-check-aof工具检测 AOF 日志文件，可以把未完成的事务操作从 AOF 文件中去除。这样一来，使用 AOF 文件恢复实例后，事务操作不会被再执行，从而保证了原子性。若使用的 RDB 模式，最新的 RDB 快照是在 EXEC 执行之前生成的，使用快照恢复之后，事务中的命令也都没有执行，从而保证了原子性。若 Redis 没有开启持久化，则重启后内存中的数据全部丢失，也就谈不上原子性了。 一致性（C）

一致性指的是事务执行前后，数据符合数据库的定义和要求。这点在 Redis 事务中是满足的，不论是发生语法错误还是运行时错误，错误的命令均不会被执行。

EXEC 执行之前，入队报错（实例分析中的语法错误）

事务会放弃执行，故可以保证一致性。

EXEC 执行之后，实际执行时报错（实例分析中的运行时错误）

错误的命令不会被执行，正确的命令被执行，一致性可以保证。

EXEC 执行时，实例宕机

若 Redis 没有开启持久化，实例宕机重启后，数据都没有了，数据是一致的。
若配置了 RDB 方式，RDB 快照不会在事务执行时执行。所以，若事务执行到一半，实例发生了故障，此时上一次 RDB 快照中不会包含事务所做的修改，而下一次 RDB 快照还没有执行，实例重启后，事务修改的数据会丢失，数据是一致的。若事务已经完成，但新一次的 RDB 快照还没有生成，那事务修改的数据也会丢失，数据也是一致的。
若配置了 AOF 方式。当事务操作还没被记录到 AOF 日志时，实例就发生故障了，使用 AOF 日志恢复后数据是一致的。若事务中的只有部分操作被记录到 AOF 日志，可以使用 redis-check-aof清除事务中已经完成的操作，数据库恢复后数据也是一致的。

隔离性（I） 并发操作在 EXEC 执行前，隔离性需要通过 WATCH 机制来保证 并发操作在 EXEC 命令之后，隔离性可以保证

情况 a 可以参考前面的实例分析 WATCH 命令的使用。
情况 b，由于 Redis 是单线程执行命令，EXEC 命令执行后，Redis 会保证先把事务队列中的所有命令执行完之后再执行之后的命令。

持久性（D）

Redis가 지속성을 활성화하지 않으면 모든 데이터가 메모리에 저장됩니다. 다시 시작하면 데이터가 손실되므로 현재로서는 트랜잭션의 내구성을 보장할 수 없습니다.
Redis의 지속성이 켜져 있으면 인스턴스가 충돌하고 다시 시작될 때 데이터가 여전히 손실될 수 있으므로 내구성을 완전히 보장할 수 없습니다.
따라서 Redis 트랜잭션이 반드시 내구성을 보장할 수는 없으며, 특별한 경우에만 내구성이 보장된다고 할 수 있습니다.

Redis가 Persistence를 켠 후에도 여전히 데이터가 손실되는 이유에 대해 저자는 Redis Persistence 및 마스터-슬레이브와 관련된 별도의 기사를 편집하여 간략하게 소개합니다.
RDB 모드가 구성된 경우 트랜잭션이 실행된 후 다음 RDB 스냅샷이 실행되기 전에 Redis 인스턴스가 충돌하고 데이터가 손실됩니다.
AOF 모드가 구성되고 AOF 모드의 세 가지 구성 옵션이 없습니다. , Everysec, 항상 데이터 손실이 발생할 수 있습니다.

요약하자면 Redis 트랜잭션은 ACID를 지원합니다.

일정한 원자성을 가지지만 롤백을 지원하지 않습니다. 일관성과 격리성을 충족하며 내구성을 보장할 수 없습니다. Redis 트랜잭션은 롤백을 지원하지 않습니다.

공식 웹사이트를 살펴보세요. 설명:

롤백은 어떻습니까?
Redis는 롤백 지원이 Redis의 단순성과 성능에 큰 영향을 미치기 때문에 트랜잭션 롤백을 지원하지 않습니다.

트랜잭션 롤백이 필요한 대부분의 상황은 프로그램 오류로 인해 발생합니다. 이러한 상황은 일반적으로 개발 환경에서 발생하며 프로덕션 환경에서는 이 오류가 발생해서는 안 됩니다.
예를 들어 논리 오류의 경우 1을 더해야 하는데 결과는 2를 더한 것으로 기록됩니다. 이러한 상황은 롤백으로는 해결할 수 없습니다.
Redis는 단순성과 효율성을 추구하지만, 전통적인 트랜잭션의 구현은 상대적으로 복잡하여 Redis의 디자인 아이디어에 어긋납니다. Redis의 속도를 즐기면 더 이상 바랄 것이 없습니다.

추천 학습: Redis 비디오 튜토리얼

위 내용은 Redis 업무를 철저하게 이해하는 데 도움이 되는 기사의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!