持久化
原因: redis是内存数据库,数据保存在内存中,如果服务器宕机内存数据丢失,所以为了数据安全性,会将内存的数据进行落盘
RDB持久化: 每隔一段时间将内存中的数据落盘
RDB持久化默认开启
RDB持久化机制: 在持久化的时候会调用linux的fork函数[复制一个与主进程一模一样的进程,与主进程共用资源、计数器等],后续由复制的进程负责持久化,主进程没有任何IO操作,主要负责客户端的读写请求
触发条件:
1、自动触发
在配置文件中配置 save time change[在time时间内进行了change次修改/写入操作,此时会触发rdb持久化]
2、手动触发
flushall: 是先清空所有数据,然后再保存[此时落盘文件中没有任何数据]
save
bgsave
shutdown: 停止redis-server的时候将数据落盘
save与bgsave的区别:
save: 复制的进程独享所有资源,主进程没有资源可用,会阻塞客户端的操作(在进行rdb的时候,客户端是不能进行读写的,所有资源都在从进程中)
bgsave: 复制的进程与主进程共享资源,不会阻塞客户端的操作(副进程一边快照,主进程一边读写数据,共享cpu内存等资源。)
RDB持久化的优点:
1、RDB持久化的是内存的数据,占用的空间相对AOF来说更新
2、RDB持久化自始至终都只有一个文件,加载速度更快,便于容灾恢复
RDB持久化缺点: 可能丢失最后一段时间没有持久化的数据
AOF持久化: 将每个写指令落盘<br /> AOF持久化默认是禁用。<br /> 如果同时开启RDB、AOF持久化,redis启动的时候优先加载AOF持久化文件<br /> 触发条件:<br /> appendfsync always: 每个写指令都会触发一次持久化<br /> appendfsync everysec: 每秒触发一次持久化<br /> appendfsync no: 不持久化,由操作系统来进行持久化<br /> redis-server的时候加载AOF持久化文件的时候,如果文件有问题,此时会清除有问题的指令<br /> AOF持久化优点: 如果配置中配置的appendfsync always,最多丢失一条数据<br /> AOF持久化缺点: 因为AOF保存的是操作指令,所以占用空间比较大<br /> RDB与AOF的应用场景:<br /> 1、如果redis是作为缓存存在,此时两个都可以不配<br /> 2、如果redis作为数据库存在,此时两个最好都配
4、事务
事务的指令:
multi: 开启事务
exec: 执行事务中所有指令
事务中指令不会立即指令,会先加入到队列中,等到exec指令执行的时候才会执行事务队列中所有指令
如何开启事务:
multi
指令操作
…
exec
redis事务中的指令如果是运行出错,不会影响其他指令的执行,如果是编译出错[命令名称写错,命令格式写错],整个事务的所有指令都不会指令
redis中采用的是乐观锁
redis的乐观锁:
每条数据都有一个版本号,后续客户端在操作数据完成之后会修改版本号,如果一个线程在操作完成之后写入之前发现版本改变,此时代表数据以及被改变过,所以此时写操作会撤销。
如何使用锁:
watch key
multi
指令操作
…
exec
通过watch监控key对应数据的版本号,此时如果在事务执行的时候发现版本号改变,事务中所有指令会撤销。
5、主从复制
原因: 如果并发量很高,单个redis服务器负载压力比较重,所以通过读写分离分散负载压力,读写分离就是主从复制[主节点负责写操作,从节点负责同步主节点数据以及读的操作]
如何建立主从:
1、临时建立
在客户端中执行 slaveof masterip port
2、永久建立
在配置文件中配置 slaveof masterip port
如何恢复从节点的身份为主节点: slaveof no one
查看角色信息: info replication
主从中如果主节点宕机,从节点不会自动提升为主节点
从节点每次启动都是从主节点拉取全部数据
从节点启动拉取数据的流程:
1、从节点启动之后会向主节点发送一个sync命令,表示需要同步数据
2、主节点会进行rdb操作将内存数据持久化到磁盘
3、主节点将rdb数据发给从节点
4、从节点将rdb加载到内存
5、后续主节点接收到写操作的时候会将写指令缓存发给从节点,从节点根据写指令加载数据
如果从节点很多,因为从节点都是从主节点同步数据,所以主节点IO负载可能会比较大,所以可以配置主->主->从
从节点选举为主节点的机制: 优先级[优先级低的优先参选]、偏移量[偏移量大的优先参选]、进程id[进程号小的优先参选]
哨兵机制
原因: 主从复制中如果主节点宕机,从节点不能自动提升为主节点,所以需要一个专门的角色检测到主节点宕机之后将从节点提升为主节点
哨兵原理:
1、哨兵会向主从节点每隔1秒发送一个PING指令,如果节点在指定时间内没有返回PONG,代表节点可能存在故障
2、如果是主节点没有返回PONG,此时哨兵会标记主节点为S-DOWN
3、如果主节点被标记为S-DOWN,此时其他哨兵会向该Master发送PING
4、后续所有的哨兵会投票,如果N个哨兵认为主节点有问题,此时主节点会标记为O-DOWN,此时会提升从节点为主节点
N是在哨兵配置文件中配置的: sentinel monitor master名称 masterip port N
6、redis集群(相当于多个主从复制)
原因: redis主从复制时主节点与从节点存储的数据都是一样的,所以此时数据相当于单机存储,而单个服务器资源有限,所以为了提高存储容量以及并发量,此时可以使用多个主从,将这多个主从组成集群[每个主从存储一部分数据]。
solt: redis集群中有多个主从,每个主从存储一部分数据,每个主从管理一部分solt,后续数据究竟存储到哪个主从中,是根据key计算之后得到solt,然后查看solt在哪个主从中就将数据存储到哪个主从
写入数据:
1、重定向: 将数据重新发送到其他主从中
redis-cli -c
2、多键操作:
redis中只能重定向一次,不能多次重定向,所以如果是多键操作,可能需要多次重定向,redis不支持
所以为了能够多键操作,此时应该: mset {xx}key1 value1 {xx}key2 value2 ..[在存储数据的时候,是根据xx计算数据应该存储到哪个solt中]
读取数据:
因为写入的时候是多键操作,读取的时候必须: mget {xx}key1 {xx}key2
集群中某个主从中如果主节点宕机,会自动提升从节点为主节点