上一章博客redis学习---上讲的是redis常用的数据类型,接下来讲的是redis的持久化和主从复制与哨兵模式、事务、发布订阅。
一、redis持久化
redis持久化分为rdb 和aof这两种。其中rdb是默认开启的,aof是默认关闭的。
1.rdb
1.1 rdb介绍:
在指定的时间间隔内将内存中的数据集快照写入磁盘。
也就是行话将的Snapshot快照,它回复时时将快照文件直接读到内存里。
1.2 rdb的工作流程:
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都 结束了,再用这个临时文件替换上次持久化好的文件。
整个过程中,主进程时不进行任何IO操作的,这就确保了极高的性能。
1.3 rdb的设置及操作:
如果需要进行大规模数据的恢复,且对于数据的恢复的完成性不是非常敏感,那RDB方式要比AOF方式更 加的高效。RDB的缺点时最后一次持久化后的数据可能丢失。
备份默认设置:save 60 10000 (可以在配置文件中修改)
是1分钟内改了1万次,或5分钟内改了10次,或15分钟内改了1次。
是1分钟内改了1万次,或5分钟内改了10次,或15分钟内改了1次。
停止使用rdb:config set save ""
1.4 快照操作:
① save直接保存 其他不管。② bgsave会在后台异步进行快照操作,快照同时还可以响应客户的请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
③ 执行flushall 也会产生dump.rdb文件,但是里面是空的,无意义。
1.5 rdb的优劣势
rdb的优势:适合大规模的数据恢复,对数据完整性和一直性要求不高。
rdb的劣势:在一定间隔时间做一次备份,所以如果redis意外的down掉的话,就会丢失最后一次快照后的所以修改。Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑。
rdb的劣势:在一定间隔时间做一次备份,所以如果redis意外的down掉的话,就会丢失最后一次快照后的所以修改。Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑。
2. aof
2.1 aof介绍
以日志的形式来记录每个写操作,将redis执行过的所有写指令记录下来(读取操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
2.2 aof修复及加载
如果aof和rdb同时存在,先加载aof。
aof错误修复 redis-check-aof --fix **.aof
aof错误修复 redis-check-aof --fix **.aof
2.3 aof持久化策略的配置
no 表示不执行fsync,由操作系统保证数据同步到磁盘,速度最快。
always 表示每次写入都执行fsync,以保证数据同步到磁盘。
everysec 表示每秒执行一次fsync,可能会导致丢失这1s数据。
appendfsync everysec
rewrite 默认是64M 100%的时候增加一倍
2.4 aof的优劣势
aof的优势:
①每秒同步:appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好。
② 每修改同步:appendfsyns everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失。
③ appendfsync no 从不同步
aof的劣势:
① 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢与rdb
② aof运行效率要慢与rdb,每秒同步策略效率较好,不同步效率和rdb相同
3. rdb和aof的总结
3.1 rdb持久化方式能够在制定的时间间隔能对你的数据进行快照存储。
3.2 aof持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,aof命令以redis协议追加保存每次写的操作的文件末尾。redis还能对aof文件进行后台的重写,使得aof文件的体积不至于过大。
3.3 只做缓存:如果你希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。
3.4 同事开启两种持久化方式:
3.4.1 在这种情况下,当redis重启的时候会优先载入aof文件来恢复原始的数据,因为在通常情况下 aof文件保存的数据集要比rdb文件保存的数据集要完整。
3.4.2 rdb的数据不实时,同时使用两者时服务器重启也只会找aof文件。那要不要只使用aof呢?作者建议不要,因为rdb更适合用于备份数据库(aof在不断的变化不好备份),快速重启,而且不会有aof 可能潜在的bug,留着作一个万一的手段。
二、redis事务
1.1 redis事务介绍
可以一次执行多个命令,本质是一组命令的集合。一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其它命令插入,不许加塞。
1.2 redis事务做什么
一个队列中,一次性、顺序性、排他性的执行一系列命令。
1.3 事务的命令
discard:取消事务,放弃执行事务快内的所以命令,
exec:执行所有事务块内的命令。
multi:标记一个事务块的开始。
unwatch:取消watch命令所有key的监视。
exec:执行所有事务块内的命令。
multi:标记一个事务块的开始。
unwatch:取消watch命令所有key的监视。
atch key...: 监视一个或多个key,如果在事务执行之前这个或这些key被其他命令所修改,那么事务将被打断,一旦执行exec之前加的监控锁都会被取消掉了。
1.4 事务小结
watch指令,类似乐观锁,事务提交时,如果key的值已被别的客户端改变,比如某个list已被别的客户端push/pop过了,整个事务队列都不会被执行。
通过watch命令在事务执行之前监控了多个Keys,倘若在watch之后有任何key的值发生了变化,exec命令执行的事务都将被放弃,同时发回Nullmulti-bulk应答以通知调用者事务执行失败。
三、redis的发布订阅
1.1 redis的发布订阅介绍
进程间的一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接受消息。
1.2 redis的发布订阅操作
订阅命令:subscribe 频道1 频道2 频道3
发送消息:publish 频道 消息
订阅的终端你就会接受到相应频道发送的消息。
四、redis的复制(Master/Slave)
1.1 redis复制介绍
行话:也就是我们所说的主从复制,主机数据更新后根据配置和策略,自动同步到备机的master、slaver机制,master以写为主,slave以读为主。
1.2 主从复制作用
1.2.1 读写分离。
1.2.2 灾难恢复。
1.3 操作
1.3.1 配从(库)不配主(库)
1.3.2 从库配置:slaveof 主库ip 主库端口 注意:每次与master断开之后,都需要重新连接,除非你配
置redis.conf文件Info replication。
1.3.3 查看redis服务启动 :info replication
1.3.4 备份主机数据:slaveof ip 端口号
主要是从机slave 就会拷贝主机的所有数据
从库转主库:slaveof no one
1.4 主从复制情况
1.4.1 主机添加数据,配置从机后从机会从主机同步全部数据。
1.4.2 主机有相应的键值数据,从机不能覆盖主机的键值。
1.4.3 主机宕机后,从机不宕机,那么从机还是从机保持不变。但是主机重启后从机会同步主机的全部数据。
1.4.4 从机宕机后,主机保持不变,那么从机重启后就变成主机,除非重新命令成为从机或者写入配置文件中。
1.4.5 主从机确定后,从机的数据和主机完全保持一致。从机原有的数据会被删除。
1.5 主从复制原理
1.5.1 Slave启动成功连接到master后会发送一个sync命令。
1.5.2 Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集的命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步。
1.5.3 复制分为:
① 全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
② 增量复制:Master继承将新的所有收集到的修改命令依次传给slave,完成同步
1.5.4 但是只要重新连接master,一次完成同步(全量复制)将被自动执行。
五、哨兵模式
1. 哨兵模式介绍
反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。
2. 哨兵模式配置
2.1 自定义sentinel.conf文件,名字绝对不能错。
2.2 配置哨兵,填写内容:
2.2.1 sentinel monitor 被监控数据库(自己起的名字)ip(127.0.0.1 端口号(6379)1(票数)
2.2.2 最后一位是票数,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机。
2.2.3 启动哨兵:Redis-sentinel /**/sentinel.conf目录按照实际创建的sentinel.conf文件为主。
2.2.4 当master挂掉之后,投票开始,有可能选不出主机会继续选择。选中主机后重新主从继续开工,可以通过info replication查查看。
2.2.5 当之前宕掉的master重新启动回来,不会和现在的master冲突,会变成从机继续工作。
一组sentinel能够同时监控多个Master。
3. 复制的缺点(哨兵模式和主从复制)
复制延时:由于所有的写操作都是先在Master上操作,然后同步更新到slave上,所以从master同步到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,slave机器数量的增加也会使这个问题更加严重。
实例:
public class jedisTest {
public static void main(String[] args)
{
Jedis jedis = new Jedis("127.0.0.1",6379);
System.out.println(jedis.ping());
jedis.set("k1","v1");
jedis.set("k2","v2");
jedis.set("k3","v3");
System.out.println(jedis.get("k3"));
Set<String> sets = jedis.keys("*");
System.out.println(sets.size());
}
}
以上就是redis的学习,介绍了redis部分功能。如果要和java连接,下载jedis-2.1.0.jar和commons-pool-1.6.jar。然后就可以在java中操作redis。