Redis-事务与单线程事件处理模型

Redis的事务是基于单线程的两阶段不完全事务（主要是不支持原子性），它仅仅是保证事务里的操作会被连续独占的执行。因为是单线程架构，在执行完事务内所有指令前是不可能再去同时执行其他客户端的请求的。

Redis作者追求简单，简单才不会出错，使得代码不用处理平时最让人头痛的并发而大幅简化，作者认为CPU不是瓶颈，内存与网络带宽才是，当top看到单个CPU 100%时，单核CPU称为瓶颈，此时就是垂直扩展的时候了。

我们知道Mysql等传统关系型数据库一般都满足ACID，下面来看一看Redis是否满足ACID

它不保证原子性——所有指令同时成功或同时失败，只有决定是否开始执行全部指令的能力，没有执行到一半进行回滚的能力。当系统突然宕机，Mysql也能根据binlog恢复，而Redis不可以。

redis 事务在执行过程中发生错误或进程被终结，都能保证数据的一致性（Consistency）。因为redis 使用单线程串行方式来执行事务的，在执行事务期间不会对事务进行中断（一致性）。

它没有隔离级别的概念，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题，所以满足隔离性（Isolation）。

但当redis 服务器使用AOF 持久化模式并appendfsync 设置为always 时，程序执行操作命令后会调用sync 函数将数据保存到硬盘里，因此redis 事务也可以具有持久性（Durability）。

是通过select * from table where for update将数据加锁，导致其他线程或事务不能更新该数据。

InnoDB基于系统版本号实现乐观锁（只在可重复读和提交读隔离级别下工作），每行记录后面保存了隐藏两个列，一个是创建或者修改这条记录的时候当前系统的版本号（每次操作都将版本号加1），一个是删除此行记录是当前系统的版本号，一个记录修改，一个记录删除标识。

当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据，事务失败。

redis 是通过watch 命令监控数据是否发生变化实现乐观锁的。当watch 的对象被更改，比如某个list已被别的客户端push/pop过了，会导致事务放弃执行。

不同场景下Mysql（InnoDB存储引擎）事务与Redis事务的比较

背景：tom1 账户当前有1000元，tom2 账户当前有500元

mysql 开启事务后事务中的sql 语句在commit 之前就已经执行了sql 语句的（同一事务内可重复读，InnoDB默认隔离级别），只是并未真正提交到数据库。
redis 使用multi 开启事务后，编写的sql 语句都进入queue 队列中（Redis没有隔离级别的概念，sever单线程模式，不会并发读），待执行exec 提交事务时才一次性按进入queue 队列的顺序提交到数据库。
同样针对回滚，mysql 执行rollback 会将提交的数据回滚，redis 因为没有提交到数据，使用discard 只是单纯取消在queue 中的sql 语句。

mysql 事务即使遇到错误的语句也会提交正确的sql 到数据库（正确语句提交，发生错误的语句抛出异常，但是不影响事务的提交），需要程序员控制当遇到语句异常时进行回滚。
redis 与mysql 不同，提交事务时会先检查queue 中有语法是否有错误，如果有语法错误则会discard 整个事务中操作命令语句。

mysql 和redis 事务当遇到操作对象类型不正确的时候都会提交执行事务，但是Mysql可以检测这个错误然后通知客户端，如果客户端要求错误回滚，则能将已经执行操作回滚，而Redis没有这个权限：只有决定是否开始执行全部指令的能力，没有执行到一半进行回滚的能力。