Redis事务

Table of Contents

作为存储服务，业内往往用事务来检验其可靠性和安全性。在Redis中，事务表现为隔离性、持久性、弱原子性，最终的效果就是弱一致性（区别于BASE中的最终一致性，Redis的弱一致性就是表示一致性很弱）。

事务相关的命令有：MULTI、EXEC、WATCH、DISCARD、UNWATCH

服务端会将客户端提供的事务内的命令放入事务队列中，从这个队列中执行命令时会一直阻塞其他连接的命令，直到队列中的命令执行完。

对Redis来说，事务不能回滚。理由是如果要实现回滚，需要更复杂的技术实现，违反了Redis简单高效的原则。

如果仿照MySQL来实现Redis的回滚，那么每个事务在执行时都要保存一份回滚日志，每次执行事务中的写命令时都需要写对应的回滚日志，事务执行结束后清除回滚日志（因为是单线程执行命令，回滚要比MySQL简单很多）。

事务中的命令在执行前，会先检查语法（入队时检查），如果语法错误，那么所有的命令都不会执行。如果语法没问题，但是执行时出现错误，那么事务仍会执行接下来的命令。

Redis使用单线程来处理命令，并且保证执行事务队列时不会中断去执行其他连接的命令，因此具有隔离性。

Redis有两种持久化机制: RDB和AOF。RDB机制缺乏实时存储，但是AOF机制能够保证命令执行后同步到硬盘（appendsync选项设置为always时）。

此外，在执行EXEC命令前执行SAVE命令能够保证事务的持久性，但是效率很低。

执行事务时会阻塞其他命令执行，而pipeline不会
pipeline会将命令一次性打包发送到服务单，而事务会一条一条发送
pipeline是客户端的行为，是将多条命令打包到一起发送给服务端。服务端解析这些命令然后执行，并不清楚是否是pipeline。如果这些命令数据较少，能够一次性的写入服务端的输入缓冲区，那么这些命令的执行就不会被打断，但是如果这些命令数据较大，那么这些命令就可能会被分成多次发送给服务端，命令的执行就可能会被打断