MySQL과 Redis 트랜잭션 비교(그림 및 텍스트)

이 기사의 내용은 MySQL과 Redis 트랜잭션(그림 및 텍스트)의 비교에 관한 것입니다. 필요한 친구가 참고할 수 있기를 바랍니다.

간단히 말하면, 트랜잭션은 원자성(A원자성 또는 불가분성), 일관성(C일관성), 격리(I solation, 독립성이라고도 함), 내구성의 4가지 조건(ACID)을 충족해야 합니다. (D유연성).

제목으로 보아 둘 다 사사건건인데 차이점은 무엇인가요? 두 개의 데이터베이스부터 하나씩 풀어보겠습니다.

MySQL은 관계형 데이터베이스에 속하고 Redis는 비관계형 데이터베이스에 속합니다. 트랜잭션에 대한 해석이 다릅니다. 关系型数据库 ， Redis 属于 非关系型数据库，两者对事务有着不同的解释。

（相关推荐：MySQL教程，Redis教程）

Redis

[1] Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：

• 批量操作在发送 EXEC 命令前被放入队列缓存。
• 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
• 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段：

• 开始事务。
• 命令入队。
• 执行事务。

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

操作错误

看着有点儿绕口，那就实际执行一下 看一下结果。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set tr_1 233
QUEUED
127.0.0.1:6379> lpush tr_1 666
QUEUED
127.0.0.1:6379> set tr_2 888
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK

在上面的事务中，设置了一个 key 为 tr_1 的字符串数据，然后又通过 lpush 来添加元素，这很明显是错误的操作方式，当我们提交事务候出现了一个操作错误，这时候我们来看看 tr_1 的值是什么。

127.0.0.1:6379> get tr_1
"233"

通过 get 命令来的tr_1 内容还是 233 ，并没有变，那再看一下其他的。

127.0.0.1:6379> keys *
1) "tr_2"
2) "tr_1"
127.0.0.1:6379> get tr_2
"888"
127.0.0.1:6379>

这里可以看到 tr_2 存在，并打印了值，这时候我们发现，即使出现了操作错误 ，但是错误并没有致使执行停止，错误之后的语句也执行了并成功执行，似乎符合上面提到的 中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

语法错误

NO~，这时候还有另外一种情况 语法错误

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set tr_1 233
QUEUED
127.0.0.1:6379> lpush tr_1 666
QUEUED
127.0.0.1:6379> set
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> set 233
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> set tr_2 888
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> keys *
(empty list or set)

当我们执行到 set时没有给任何参数，第二次执行时故意少给了一个参数。可以看到报了 语法错误，最后提交事务，也告诉了我们事务因为错误被丢失了，接着用 keys *检索发现确实如此。

文档释义

这里可以官方文档中提到的

Errors inside a transaction

// 在执行过程中 可能会遇到两种错误命令错误。

During a transaction it is possible to encounter two kind of command errors:

// 1.命令无法进入队列 ，比如 ：参数数量错误，命令名错误...，或者某些关键错误 如内存不足

• A command may fail to be queued, so there may be an error before EXEC is called. For instance the command may be syntactically wrong (wrong number of arguments, wrong command name, ...), or there may be some critical condition like an out of memory condition (if the server is configured to have a memory limit using the maxmemorydirective).

// 2. 对键进行错误的操作 如上面的 对字符串使用 lpush

• A command may fail after EXEC is called, for instance since we performed an operation against a key with the wrong value (like calling a list operation against a string value).

// 客户端检查键入的命令，大多数时候会在调用 exec 前发现第一类

(관련 권장 사항: MySQL 자습서, Redis 튜토리얼)🎜

Redis

🎜[1] Redis 트랜잭션은 한 번에 여러 명령을 실행할 수 있습니다. , 그리고 다음 두 가지 중요한 보장이 제공됩니다: 🎜

• 배치 작업은 EXEC 명령을 보내기 전에 대기열 캐시에 저장됩니다.
• EXEC 명령을 받은 후 트랜잭션 실행이 시작됩니다. 트랜잭션의 명령 중 하나라도 실행에 실패하면 나머지 명령은 계속 실행됩니다.
• 트랜잭션 실행 프로세스 중에 다른 클라이언트가 제출한 명령 요청은 트랜잭션 실행 명령 시퀀스에 삽입되지 않습니다.

🎜거래는 시작부터 실행까지 다음 세 단계를 거칩니다. 🎜

• 거래 시작.
• 대기열에 참여하는 명령입니다.
• 거래를 실행합니다.

🎜🎜 단일 Redis 명령의 실행은 원자성이지만 Redis는 트랜잭션의 원자성을 유지하기 위한 메커니즘을 추가하지 않으므로 Redis 트랜잭션의 실행은 원자성이 아닙니다. 🎜🎜🎜🎜트랜잭션은 패키지된 배치 실행 스크립트로 이해될 수 있지만 배치 명령은 원자성 작업이 아닙니다. 중간 명령이 실패해도 이전에 실행된 명령이 롤백되거나 후속 명령이 실행되지 않습니다. . 🎜🎜

연산 오류

🎜좀 복잡해 보이는데 실제로 실행해서 결과를 확인해 보겠습니다. 🎜

`SELECT * FROM `user` LIMIT 50` (0.000 秒)

🎜위 트랜잭션에서는 키가 tr_1인 문자열 데이터가 설정된 다음 lpush를 통해 요소가 추가됩니다. 이는 분명히 잘못된 작동 방식입니다. 트랜잭션을 커밋했는데 작업 오류가 발생했습니다. 이때 tr_1의 값을 살펴보겠습니다. 🎜

select version();
SET AUTOCOMMIT=0;
begin;
select * from user where title in ('A','B') for update;
update user set  money = money + 1000 where title = 'A';
update user set money = money - 1000 where title = 'B';
select * from user where title in ('A','B');
commit;

🎜get 명령을 통해 얻은 tr_1의 내용은 여전히 ​​🎜233🎜이며 변경되지 않았습니다. 🎜rrreee🎜여기서 tr_2가 존재하고 그 값이 출력되는 것을 볼 수 있습니다. 이때 작업 오류가 발생하더라도 오류가 발생하지 않는 것을 확인했습니다. 오류 이후의 명령문도 성공적으로 실행되어 위에서 언급한 내용과 일치하는 것 같습니다. 🎜 중간에 명령이 실패해도 이전 명령이 롤백되지는 않습니다. 후속 명령은 실행되지 않습니다. 🎜🎜

구문 오류

🎜NO~ 이번에 또 다른 상황이 발생했습니다 구문 오류🎜rrreee🎜 set를 실행하면 For가 없습니다. 모든 매개변수가 있는 경우 두 번째 실행 중에 하나의 매개변수가 의도적으로 제공됩니다. 구문 오류가 보고되어 마침내 트랜잭션이 제출되었으며 오류로 인해 트랜잭션이 손실되었음을 알 수 있습니다. 그런 다음 keys *를 사용하여 작업을 수행했습니다. 검색해 보니 실제로 그런 경우가 있었습니다. 🎜

문서 해석

🎜여기에서 공식 문서에 언급된 내용을 찾을 수 있습니다.🎜

거래 내부 오류

🎜// 작업 중에 두 가지 유형의 오류 명령 오류가 발생할 수 있습니다. 실행 . 🎜🎜트랜잭션 중에 두 가지 종류의 명령 오류가 발생할 수 있습니다:🎜🎜// 1. 명령을 대기열에 입력할 수 없습니다: 잘못된 매개변수 수, 잘못된 명령 이름. .. 또는 메모리 부족과 같은 심각한 오류🎜

• 명령이 대기열에 추가되지 않아 EXEC가 호출되기 전에 오류가 발생할 수 있습니다. 예를 들어 명령의 구문이 잘못되었을 수 있습니다(인수 개수가 잘못됨). , 잘못된 명령 이름, ..) 또는 메모리 부족 상태와 같은 심각한 상황이 있을 수 있습니다(서버가 maxmemory 지시문을 사용하여 메모리 제한을 갖도록 구성된 경우).

🎜 // 2. 위의 문자열에 lpush를 사용하는 등 키에 잘못된 작업을 수행합니다.🎜

• EXEC 이후 명령이 실패할 수 있습니다. 예를 들어 잘못된 값을 가진 키에 대해 작업을 수행했기 때문에 호출됩니다(예: 문자열 값에 대해 목록 작업 호출).

🎜// 클라이언트는 입력된 명령을 확인합니다. Exec 전에 유형 1 오류가 발견되기 전에 호출됩니다. 명령 실행이 QUEUED를 반환하면 명령이 정상적으로 대기열에 들어간다는 의미입니다. 대부분의 경우 클라이언트는 거래를 종료하고 포기합니다. 🎜

Clients used to sense the first kind of errors, happening before the EXEC call, by checking the return value of the queued command: if the command replies with QUEUED it was queued correctly, otherwise Redis returns an error. If there is an error while queueing a command, most clients will abort the transaction discarding it.

关于 Redis 暂时看到这里 接下来看到 MySQL

MySQL

众所周知，MySQL 只有 InnoDB 引擎支持 事务，在启用 MySQL 事务之前需要先停掉自动提交

测试表结构 user

列	类型	注释
id	int(11) 自动增量	主键ID
money	int(11) [0]	金钱
title	varchar(500) NULL	称呼

在这里来模拟一个转账的操作：A给B转100元。

步骤解析 A+100 元，B -100元，即两步虽然很简单，简单走一下流程。

可以看到，没有问题，那么我们从中人为的制造一些问题呢？

操作错误

列	类型	注释
id	int(11) 自动增量
money	int(11) unsigned [0]
title	varchar(500) NULL

这里我们把 money 字段变成了无符号，即不能小于 0，并且，调整数据库中的数据如下。

`SELECT * FROM `user` LIMIT 50` (0.000 秒)

修改	id	money	title
编辑	1	10000	A
编辑	2	0	B

接着执行下面的 SQL

select version();
SET AUTOCOMMIT=0;
begin;
select * from user where title in ('A','B') for update;
update user set  money = money + 1000 where title = 'A';
update user set money = money - 1000 where title = 'B';
select * from user where title in ('A','B');
commit;

问题出现了，这里报出了错误，但是可以看到 前面的 SQL 已经是已执行的了，结果已经发生了变化，从这里看，似乎和 Redis 的处理差不多，除了错误之后语句继续执行。但是 值的注意的是， 在我们实际开发中，这种情况程序会直接抛出异常，以供我们在 catch 块中执行 rollback ，以回滚操作确保数据完整，即使是单独使用 MySQL 命令行 我们也可以用存储过程来对异常进行回滚。

语法错误

刚刚看到 Redis 当遇到 语法错误 时会自动丢弃事务，阻止提交，那 MySQL 呢？

答案：不会，MySQL 在顺序执行时，如果未对异常进行处理，总会将成功执行的的提交，而不会触发自动终止，但是我们可以在程序执行时进行放弃提交。

Redis 为什么没有回滚？

Redis 的官方文档给出了这样的解释

// 只有在使用错误的语法调用时才会失败Redis命令（并且在命令排队期间无法检测到问题），或者对于持有错误数据类型的键，Redis命令可能会失败：这意味着实际上失败的命令是编程错误的结果，以及在开发过程中很可能检测到的一种错误，而不是在生产中。

• Redis commands can fail only if called with a wrong syntax (and the problem is not detectable during the command queueing), or against keys holding the wrong data type: this means that in practical terms a failing command is the result of a programming errors, and a kind of error that is very likely to be detected during development, and not in production.

// Redis内部简化且速度更快，因为它不需要回滚的能力。

• Redis is internally simplified and faster because it does not need the ability to roll back.

总结

数据库    自动回滚条件	操作错误	语法错误
MySQL	✖	✖
Redis	✖	✔

但是 MySQL 支持手动回滚，实际开发过程中可以自行手动对已提交的操作进行回滚操作，更加友好。

위 내용은 MySQL과 Redis 트랜잭션 비교(그림 및 텍스트)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!