RDB:
RDB是在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据 恢复。
优点:使用单独子进程来进行持久化,主进程不会进行任何IO操作,保证了redis的高性能
缺点:RDB是间隔一段时间进行持久化,如果持久化之间redis发生故障,会发生数据丢失。所以这种方式更适合 数据要求不严谨的时候
AOF:
Append-only fifile,将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部,在append操作返回后(已经写 入到文件或者即将写入),才进行实际的数据变更,“日志文件”保存了历史所有的操作过程;当server需要数据恢复时,可以直接replay此日志文件,即可还原所有的操作过程。AOF相对可靠,它和mysql中bin.log、apache.log、
zookeeper中txn-log简直异曲同工。AOF文件内容是字符串,非常容易阅读和解析。
优点:可以保持更高的数据完整性,如果设置追加fifile的时间是1s,如果redis发生故障,最多会丢失1s的数据;且 如果日志写入不完整支持redis-check-aof来进行日志修复;AOF文件没被rewrite之前(文件过大时会对命令进行 合并重写),可以删除其中的某些命令(比如误操作的flushall)。
缺点:AOF文件比RDB文件大,且恢复速度慢。
Redis 主从复制
- 持久化保证了即使redis服务重启也不会丢失数据,但是当redis服务器的硬盘损坏了可能会导致数据丢失,通过redis的主从复制机制就可以避免这种单点故障(单台服务器的故障)。
- 主redis中的数据和从上的数据保持实时同步,当主redis写入数据时通过主从复制机制复制到两个从服务上。
- 主从复制不会阻塞master,在同步数据时,master可以继续处理client请求.
- 主机master配置:无需配置
主从复制的搭建
1、复制一份Redis,之前的Redis使用的端口是6379,现在改为6380
2、修改从机的redis.conf文件,这里是修改replicaof属性
修改为:主机的ip和端口号,更准确的来说是指定的是bind后面主机的ip
删除从机中的dump.rdb文件
启动从机的服务以及客户端
启动主机的服务以及客户端,主机和从机的区别就是在于IP地址和端口号的区别,由于只开启了一个虚拟机,所以主从机均在同一个IP地址上
在主机上输入命令 info replication 可以查看到从机的信息
在从机上输入 该命令 info replication 也能查看到主机的信