redis

redis的持久化

在redis中已经提供了两种持久化的方案

RDB: redis提供的一种基于快照机制实现的持久化方案, 而快照就类似于照相机, 会将一个服务器某个时刻的一个状态整体保存下来, 快照文件一般都非常的小,只有几kb左右

优点: 由于持久化的文件非常小, 适合于做灾难恢复

缺点: 由于redis中持久化的时机问题, 会存在数据丢失的问题

AOF: redis提供的一种基于日志机制实现的持久化方案, 会将用户操作的所有的命令整体的记录下来保存到日志文件中,一般文件都比较庞大

优点: AOF机制可以让将用户所有的命令都记录下来, 顾其数据保存的比较完整, 不容易丢失

缺点: 持久化的文件比较庞大, 不利于灾难恢复

RDB保存机制: redis默认是开启RDB机制

save 900 1 : 在900秒之内,如果有一个数据进行修改,就会执行一下保存

save 300 10  : 在300秒之内, 如果有10个以上的数据被修改, 就会执行一下保存

save 60 10000 : 在60秒之内, 如果有10000个以上的数据被修改. 就会执行一下保存

当服务器宕机, 最大丢失数据量为在不到5分钟的时间里丢掉9999个数据

一般情况下redis的不会出现宕机的现象, 除非redis中的数据将内存撑爆了, 但这个现象在大公司是不会出现的

AOF的保存机制:redis默认不开启

如何开启AOF:

打开redis的配置文件,修改下列两个参数即可

appendonly yes //默认此项是no,没有启动AOF机制

appendfsync everysec  //appendfsync的取值: [always everysec no]

always: 总是, 只要有新的命令执行, 就将其保存到文件中

优点: 数据保存最完整, 几乎不会丢掉数据

缺点: 大大降低了redis的性能

everysec: 每秒钟执行一次保存

此种保存不会大幅度的降低redis的性能,但是会丢失最大1s的数据

no: 不执行保存, 由操作系统自动调用保存(linux一般30分钟刷新一次内存)

一般不使用

redis的主从复制架构

主节点可以读写，从节点只能读不能写

redis当中的sentinel架构

类似zookeeper，当主节点挂掉后可以进行选举