redis┃面试官问我redis事务和mysql事务的区别，我

1、前言

面试官：我看你简历上写了熟悉redis，看来工作中用的很多吧？

我：是的，我们项目中经常用到redis（来，随便问，看我分分钟秒杀你）

面试官：那你给我说说redis的事务和mysql的事务有什么区别吧

我：额。。。事务还有区别？？？？

面试官：比如说redis的事务是不支持原子性和持久性的，包括他们的实现原理等方面也是有很大区别的。

我：学到了。。。。。。

2、正文

事务的四大特性

ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。

说的是一个事物内所有 *** 作就是最小的一个 *** 作单元，要么全部成功，要么全部失败。这是最基本的特性，保证了因为一些其他因素导致数据库异常，或者宕机。

一个事务可以封装状态改变（除非它是一个只读的）。事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。

一致性有下面特点：

在现实中，事务系统遭遇并发请求时，这种串行化是有成本的， Amdahl法则描述如下：它是描述序列串行执行和并发之间的关系。

“一个程序在并行计算情况下使用多个处理器所能提升的速度是由这个程序中串行执行部分的时间决定的。”

大多数数据库管理系统选择（默认情况下）是放宽一致性，以达到更好的并发性。

事物的隔离性，基于原子性和一致性，因为事物是原子化，量子化的，所以，事物可以有多个原子包的形式并发执行，但是，每个事物互不干扰。

但是，由于多个事物可能 *** 作同一个资源，不同的事物为了保证隔离性，会有很多锁方案，当然这是数据库的实现，他们怎么实现的，我们不必深究。

持久性，当一个事物提交之后，数据库状态永远的发生了改变，即这个事物只要提交了，哪怕提交后宕机，他也确确实实的提交了，不会出现因为刚刚宕机了而让提交不生效，是要事物提交，他就像洗不掉的纹身，永远的固化了，除非你毁了硬盘。

事务命令

mysql：

Begin：显式的开启一个事务

Commit：提交事务，将对数据库进行的所有的修改变成永久性

Rollback：结束用户的事务，并撤销现在正在进行的未提交的修改

redis：

Multi：标记事务的开始

Exec：执行事务的commands队列

Discard：结束事务，并清除commands队列

默认状态

mysql：

mysql会默认开启一个事务，且缺省设置是自动提交，即每成功执行sql，一个事务就会马上commit，所以不能rollback，

redis：

redis默认不会开启事务，即command会立即执行，而不会排队，并不支持rollback

使用方式

mysql（包含两种方式）：

用Begin、Rollback、commit显式开启并控制一个 新的 Transaction

执行命令 set autocommit=0，用来禁止当前会话自动commit，控制 默认开启的事务

redis：

用multi、exec、discard，显式开启并控制一个Transaction。

（注意：这里没有强调 “新的” ，因为默认是不会开启事务的）。

实现原理

mysql：

mysql实现事务，是基于undo/redo日志

undo记录修改前状态，rollback基于undo日志实现

redo记录修改后的状态，commit基于redo日志实现

既然是基于redo日志实现记录修改后的状态，那么大家应该也知道，redo日志是innodb专有的，所以innodb会支持事务

在mysql中无论是否开启事务，sql都会被立即执行并返回执行结果，只是事务开启后执行后的状态只是记录在redo日志，执行commit之后，数据才会被写入磁盘

（以上内容后面我会详细在mysql篇给大家讲到，大家可以先简单了解下）

所以，上述代码，insertSelective 将会被立即赋值（无论是否开启事务，只是结果或未被写入磁盘）：

redis:

redis实现事务，是基于commands队列

如果没有开启事务，command将会被立即执行并返回执行结果，并且直接写入磁盘

如果事务开启，command不会被立即执行，而是排入队列，并返回排队状态（具体依赖于客户端（例如：spring-data-redis）自身实现）。

调用exec才会执行commands队列

以上代码如果没有开启事务， *** 作被立即执行，a将会被立即赋值（true/false）

如果开启事务， *** 作不会被立即执行，将会返回null值，而a的类型是boolean，所以将会抛出异常：

Redis事务不支持Rollback（重点）

事实上Redis命令在事务执行时可能会失败，但仍会继续执行剩余命令而不是Rollback（事务回滚）。如果你使用过关系数据库，这种情况可能会让你感到很奇怪。然而针对这种情况具备很好的解释：

redis 事务中的错误

事务期间，可能会遇到两种命令错误：

客户端会在EXEC调用之前检测第一种错误。 通过检查排队命令的状态回复（***注意：这里是指排队的状态回复，而不是执行结果***），如果命令使用QUEUED进行响应，则它已正确排队，否则Redis将返回错误。如果排队命令时发生错误，大多数客户端将中止该事务并清除命令队列。然而：

这是由于INCR命令的语法错误，将在调用EXEC之前被检测出来，并终止事务（version2.6.5+）。

EXEC命令执行之后发生的错误并不会被特殊对待：即使事务中的某些命令执行失败，其他命令仍会被正常执行。

阿牛去一家中意的公司面试，本以为凭借以往丰富的经验，肯定手到擒来，结果第一个问题，我就“出门右拐”了。

问题就是：MySQL是怎么保证事务一致性的？

回到家阿牛翻阅资料，终于搞懂了，在这里分享给大家。

定义

在搞清楚问题答案之前，先搞清楚以下几个名词以及大致的用处

redo log：

通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)、Innodb特有的，他在存储引擎层。循环写的，空间固定会用完。作用是crash-safe能力

binlog：

是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ” 是 MySQL 的 Server 层实现的，所有引擎都可以使用。是可以追加写入的,“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。作用是数据归档

undo log：

有两个作用：提供回滚和多个行版本控制(MVCC)。

在数据修改的时候，不仅记录了redo，还记录了相对应的undo，如果因为某些原因导致事务失败或回滚了，可以借助该undo进行回滚。

SQL执行的过程

了解了以上名词之后，让我们看一下“一条更新SQL语句执行的过程是什么？”

如图1有几个关键步骤：

1、先查找记录所在的Innodb页在不在内存里；如果不在内存里则将记录所在的页加载在内存里；根据SQL语句在内存中将记录更新

2、将更新前的记录写入undolog

3、根据记录的更新值将变更写入redolog（buffer）中，并将状态变更为prepare

4、将变更记录到逻辑日志

5、redolog日志中的状态修改为commit，返回结束

至此：一条更新语句的过程结束

上面的步骤中有些同学可能会有一些疑问：为什么更新一条记录要把一整页数据加载到内存里答：因为Innodb引擎中，最小的存储单位是页为什么一定要加载到内存里？答：因为所有的计算 *** 作都是在内存里， *** 作完成后最终才写回磁盘为什么要写入redolog，直接写入磁盘，然后写入binlog就好了啊？答：这将在下面会提到，请往后看

为了加深理解，准备了下面2张图辅助理解

以图3为例，让我们看看在每个步骤出现异常的时候，到底怎么保证事物一致性的吧！1、步骤123，所有的 *** 作最多还只是内存里，如果出现宕机、断电等异常，  记录不会有任何变动，事物是一致的2、步骤4刚执行完，断电了，因为redolog还处在prepare状态，   这时候事物也是一致的3、步骤5记录binlog的过程中断电了，这时候要保证主从一致性，  事物也是不生效的，最终也是一致的4、步骤6、7如果中间任何一个时刻断电了，这时候情况就不一样了，事物是生效的，因为redolog、binlog的数据都是完整的，服务器重启后可以按照xid来去查看binlog、redolog中是否都存在，  都存在该事物就是生效的。上面就是怎么保证事务一致性的根本原因

为什么要使用redolog？

回答这个问题之前，我们先看看redolog用图形表示的

图4是redolog的形象一点的表现，并不是说redolog 长这个样子，只是为了更形象；一般情况下redolog一组4个文件，每个文件1个G，其中write pos是指redolog当前写到什么位置了，check point是指上次刷脏结束的位置，当write log和check point重合时，所有的进程停止，开始新一轮的刷脏 *** 作。刷完后redolog清空开始下一轮的写入，往返重复。

可能这样表示有点抽象，让我们看下图5

从上图中可以看的更形象一点，在sql执行的时候，会有磁盘IO将数据页加载到内存，然后在内存中将数据修改，修改后的数据页在内存中叫做脏页（叫脏页因为和磁盘中的数据不一致啊），又因为在内存中容易丢失，所以将数据页的变更记录如redolog中，随着记录插入、更新等 *** 作的增多，redolog空间慢慢的满了，这时候就开始刷脏 *** 作了，page cleaner thread线程会将所有的脏页数据刷新到磁盘，使得变更最终被持久化到磁盘。

讲到这里一定还会有人不太理解，刷脏之前断电了咋办？

这就是redolog的另一个重要的作用，crash-safe能力，实现的逻辑是这样的，断电后内存的数据都没了，重启后读取redolog文件，因为redolog文件记录的是在Innodb页x的m处做了y的修改，所以根据redolog将涉及到的Innodb页重新加载到内存，根据redolog的记录将内存中的数据重新修改，这样就能恢复断电前的数据了。

                                                                     完

下期预告：还是MySQL，敬请期待

本文首发自： 程序员阿牛

---