Redis保存数据的方式有两种：
1.快照持久化
2.AOF持久化
快照持久化
默认redis是会以快照的形式将数据持久化到磁盘的（一个二进制文件，dump.rdb，文件名字可以指定）。
快照持久化选项
save save 60 10000 60秒内有10000次写入
stop-writes-on-bgsave-error yes
如果启用如上的快照（RDB），在一个存盘点之后，可能磁盘会坏掉或者权限问题，redis将依然能正常工作
rdbcompression yes
是否将字符串用LZF压缩到.rdb 数据库中，如果想节省CPU资源可以将其设置成no，但是字符串存储在磁盘上占用空间会很大，默认是yes
rdbchecksum yes
rdb文件的校验，如果校验将避免文件格式坏掉，如果不校验将在每次操作文件时要付出校验过程的资源新能，将此参数设置为no，将跳过校验
在配置文件中的格式是：save N M表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。
例如：save 60 10000 60秒内有10000次写入
如果用户配置了多个save配置选项，那么当任意一个save配置选项的条件被满足时Redis就会触发一次BGSAVE命令。
创建快照的方法：
1.客户端通过向Redis发送BGSAVE命令创建快照。
2.客户端通过向Redis发送SAVE命令创建快照。
3.save配置选项的条件满足时触发BGSAVE命令。
4.Redis通过SHUTDOWN命令接收到关闭服务器命令请求时，或者接收到标准TERM信号时，会执行SAVE命令。
5.一个Redis服务器连接另一个Redis服务器并向对方发送SYNC命令时，主服务器会执行BGSAVE命令(如果主服务器正在执行BGSAVE命令或者刚执行完BGSAVE命令的情况除外)。
BGSAVE与SAVE
BGSAVE命令是由Redis调用fork来创建一个子进程，子进程负责将快照写入硬盘，而Redis继续处理命令请求，而SAVE命令发出后Redis服务器在快照创建完毕之前不再响应任何其他命令，也就是说SAVE是一个阻塞命令，但是SAVE的执行效率要比BGSAVE更高，更快，一般只有在没有足够的内存去执行BGSAVE命令时才使用SAVE命令创建快照。
AOF持久化
# 是否开启AOF，默认关闭（no）
appendonly yes
# 指定 AOF 文件名
appendfilename appendonly.aof
# Redis支持三种不同的刷写模式：
appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no
no-appendfsync-on-rewrite no
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb
用户可以手动执行BGREWRITEAOF来重写AOF文件，重写的目的主要是移除重复冗余的命令来重启AOF文件，减小AOF文件的大小。
开启简单的事务
使用multi命令开启，exec命令提交，实际在开启multi命令后执行的命令并没有执行，这些命令会写到缓冲器，等待exec执行的时候，一次性执行。
[java]
- jedis=JedisPoolUtil.getResource();
- Transaction tx = jedis.multi();
- for(int i=0;i<10;i++){
- tx.set("key"+i, "value:"+i);
- }
- List<Object> results = tx.exec();
另外可以调用watch()方法来监控key，如果调用后key值发生变化，则整个事务会执行失败。
另外，事务中某个操作失败，并不会回滚其他操作。这一点需要注意。
还有，我们可以使用discard()方法来取消事务。
登录 | 立即注册