单点Redis的问题:
1.数据丢失问题:Redis是内存存储,重启服务器之后数据丢失
2.并发能力问题:单点Redis虽然并发能力强,但是还是无法满足更高的并发量
3.故障恢复问题:如果Redis宕机,则服务不可用,需要解决手段
4.存储能力问题:Redis基于内存,单点能存储的数据量无法满足海量数据。
Redis持久化:
1.RDB持久化:RDB全称Redis Database Backup file(Redis数据备份文件),也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。快照文件称为RDB文件,默认是保存在当前运行目录。
Redis停机时会自动执行一次RDB,保证我们数据不丢失。
Redis内部有触发RDB机制,可以在REdis.conf文件中找到。
Redis的其他配置文件也可以在redis.conf文件中设置
bgsave开始时会fork主进程得到一个子进程,子进程共享主进程的内存数据,完成cork后读取内存数据并写入RDB文件。
AOF:AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件,可以看做是命令日志文件。
RDB和AOF的区别:
Redis主从集群数据同步原理:
master如何判断slave是不是第一次来同步数据:
1.Replication ID :简称replid,是数据集的标记,ID一致说明是同一个数据集。每一个,aster都有唯一的replid,slave会继承master节点的replid
2.offset:偏移量,随着记录在repl_baklog中的数据增多而增大。slave完成同步时也会记录当前同步的offset,如果slave的offset小于master的offset,说明slave的数据落后master,需要更新。
Redis哨兵集群:
哨兵的作用:
1.redis提供了哨兵(Sentinel)机制来实现主从集群的自动故障恢复,哨兵的结构和作用如下:
服务状态监控:Sentinel基于心跳机制监测服务状态,每隔1秒向集群的每个实例发送ping命令:
1.主管下线:如果某sentinel节点发现某实例未在规定时间响应,则认为该实例主观下线
2.客观下线:若超过指定数量(quorum)的sentinel都认为该实例主观下线,则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。
集群故障恢复原理:一旦发现master故障,sentinel需要在salve中选择一个作为新的master,选择依据是这样的:
1.首先会判断slave节点与master节点断开时间的长短,如果超过指定值(down-aafter-milliseconds * 10)则会排除该slave节点
2.然后判断slave接待你的slave-priority值,越小优先级越高,如果值为0则永不参与选举
3.如果slave-prority一样,则会判断slave节点的offset值,值越大说明数据越新,优先级越高
4.最后判断slave节点的运行id大小,值越小优先级越高
故障转移流程:
1.sentinel给备选的slave1节点发送slaveof no one命令,让该节点成为master
2.sentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令,让这些slave成为新master的从节点,开始从新的master上同步数据。
3.最后,sentinel将故障节点标记为slave,当故障节点恢复后会自动成为新的master的slave节点
分片集群结构:
海量数据问题。
高并发写问题。
使用分片集群可以解决,特征:
1.集群中可以有多个master,每个master保存不同数据
2.每个master都可以有多个slave节点
3.master之间通过ping检测彼此健康状态。
4.客户端请求都可以访问集群任意节点,最终都会转发到正确的节点。