Redis——事务&持久化

一、 事务处理

　　Redis对事务的支持比较简单，或者说它的事务是有缺陷的。它只能保证一个Client发起的事务中的命令可以连续执行，中间不会插入其它client端的命令。缺陷在于，如果一个client将两条命令放到一个事务了，执行的时候第二条命令发送错误，但此时Redis的事务不会回滚第一条命令。如下图：

　　


　　Redis事务的执行原理如下：当client端发起multi命令时，这个连接会进入一个事务上下文，该连接后续的命令不会立即执行，而是先放到一个缓冲队列中，当执行exec命令时，Redis会依次执行队列中所有命令。

　　1.1 开启/执行事务（multi/exec）

　　

　　1.2 取消事务（discard）

　　

　　1.3 乐观锁

大多数是基于教据版本（version）的记录机制实现的。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个” version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1。此时，将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库当前版本号，则予以更新，否则认为是过期数据。

举例：

假设有一个age的key，我们开两个Session对age进行赋值操作，然后看一下结果。

　　


　　


　　


　　watch命令会监视给定的key，当exec时候，如果监视的key从调用watch后发生过变化，则整个事务会失败。也可以调用watch多次监视多个key．这样就可以对指定的key加乐观锁了。注意watch的key是对整个连接有效的，事务也一样。如果连接断开，监视和事务都会被自动清除。当然了exec,discard,unwatch命令都会清除连接中的所有监视。

二、 持久化机制

Redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到硬盘来保证持久化。Redis支持两种持久化方案：

　　2.1 snapshotting（快照—存数据—默认方式）

快照是默认的持久化方式。这种方式是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置Redis在n秒内如果超过m个key被修改就自动做快照。如下图：

　　

　　2.2 aof（存操作）

　　由于快照方式是在一定间隔时间做一次的，所以如果Redis被意外down掉的话，就会丢失最后一次快照后的所有修改。aof方式比快照方式有更好的持久化性，是由于在使用aof时，Redis会将每一个收到的写命令都通过write函数追加到文件中，当Redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

　　当然由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上．这样aof仿式的持久化也还是有可能会丢失部分修改．我们可以通过配置文件告诉Redis我们想要通过fsync涵数强制os写入到磁盘的时机。如下图：

　　


　　我们查看appendonly.aof文件可以看到，里面存的都是Redis的操作：