关于Redis持久化和集群模式(主从,哨兵,去中心化)使用和介绍
持久化:
持久化介绍
把内存中的数据存储到磁盘的过程。同时也可以把磁盘中的数据加载到内存中
持久化实现
redis实现持久化的方式提供了两种:
RDB
快照模式，数据备份和恢复速度快。缺点: 数据完整性差。数据可能丢失多。
AOF
日志追加: 数据完整性高。缺点: 数据备份和恢复速度慢。
如果两种模式都打开了默认会优先使用AOF日志模式;
RDB:
RDB[redis database]:
快照模式。每隔一段时间对内存中的数据进行快照存储。 默认启用该模式RDB触发:
1.手动触发：save和bgsave手动触发rdb。
保存的名称dump.rdb(可通过更改redis.conf文件dbfilename dump.rdb修改保存名称)
save该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。
bgsave:执行该命令时，Redis会在后台(fork())出一个新的线程单独异步进行快照操作,快照同时还可以响应客户端请求(不耽误主线程进行操作)(唯一的多线程操作)
2.自动触发: 通过配置文件。需要修改配置文件:
### SNAPSHOTTING ### save 30 2 10 40 ... 表示:(30 2)每10s/2次 或 (10 40)每10s/40次 才 持久化一次AOF:
AOF[append only file]:
日志[每执行一个写操作]追加模式，默认redis没有开启该模式。需要手动开启。
默认的配置文件redis/redis.conf
appendonly no //是否开启aof模式 appendfilename "appendonly.aof" //aof持久化文件的名称 appendirname "appendonlydir" //aof存放的目录 appendfsync everysec //触发机制
开启aof把配置文件中的appendonly yes即可
当启动redis服务器，会把日志文件中的命令从上到下执行一下。
集群模式:
redis集群作用
提高并发量，提高了可用性。
redis集群模式
主从模式版本3以下出现
哨兵模式版本5以下出现
去中心化模式版本5之前python引入,5之后自带
主从模式
redis主从模式表示
一个主节点跟若干个从节点。
主节点可以负责写操作和读操作。
从节点只负责读操作。
主节点的数据会自动同步到所有的从节点上。
注意:
如果某台slave(从)宕机,恢复后继承主节点仍具有master新增的数据:
从机重启恢复后默认为主机,重新选主变从之后才会继承主节点所有数据master(主)宕机后,slave(从)不会自动选举(主):
意味着主机宕机后只能通过从机进行查找操作,无法进行增删改;搭建redis主从模式
创建主从文件,拷贝redis.conf放入
配置主从需要主从的IP或端口不同,并都启用
若IP相同则:将配置文件中:
6379全部改为新端口
//端口号
port 6379;改为新端口
//启动显示端口号
dbfilename dump.rdb;改为新端口dump6379.rdb(新端口)
//附加文件名
appendfilename "appendonly.aof";改为修改后的文件名(不同端口需要不同文件一个一个启动)
//附加管理名
appenddirname "appendonlydir";改为appendonlydir6379(新端口)
启动
redis-server 配置文件名称.conf
配置主从关系
进入IP:
redis-cli -h 连接IP -p 端口
配从不配主(默认即为主节点),
从节点配置命令
slaveof 主节点IP 主节点port(端口)
查看主从的状态:
info replication
哨兵模式
为了解决主从模式的缺陷:
当主节点宕机后，从节点无法直接上位。
搭建sentinel服务时，尽量搭建奇数个。选举机制,通过哨兵投票制筛选继承者;
监控机制:
Sentinel基于心跳机制检测服务状态,每隔1秒向集群的每个实例发送ping命令;
主管下线:如果某sentinel节点发现某实例未在规定时间响应,则认为该实例主观下线;
客观下线:若超过指定数量(quorum)的sentinel都认为该实例主观下线，则该实例客观下线,quorum值最好超过Sentinel实例数量的一半
选举机制:
一旦发现master故障,sentinel需要在salve中选择一个作为新的master,选择依据是:查看状态:
info replication
首先会判断slave节点与master节点
断开时间长短如果超过指定值(down-after-millisencods*10)则会排除该slave和节点然后判断slave节点的
slave-priority值,越小优先级越高,如果为0则永不参与选举如果slavae-prority一样 则判断
slave_rep_offset值,越大说明数据越新,优先级越高最后判断slave节点的运行id大小,
越小优先级越高;使用:
修改sentinel.conf
sentinel monitor 哨兵命名 IP 端口 哨兵数量
启动哨兵服务
redis-sentinel sentinel.conf出现+switch-master 命名 IP说明启动成功
去中心化模式
原理
redis 集群中
内置了16384个哈希槽当需要在 Redis 集群中放置一个 key-value时
redis 先对 key 使用 crc16 算法算出一个整数结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽
redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。
当你往Redis Cluster中加入一个Key时，会根据crc16(key) mod 16384计算这个key应该分布到哪个hash slot中，一个hash slot中会有很多key和value。你可以理解成表的分区，使用单节点时的redis时只有一个表，所有的key都放在这个表里；改用Redis Cluster以后会自动为你生成16384个分区表，你insert数据时会根据上面的简单算法来决定你的key应该存在哪个分区，每个分区里有很多key。
需求最少三台主机三台从机(主节点中不能有数据):
主从+哨兵模式,
多少个机器就需要多少个redis.conf,文件中:
REDIS CLUSTER 标注下修改为:
cluster-enabled yes
cluster-config-file nodes-端口.conf
启动每个要启用的机器:
redis-server 配置文件名称.conf
分槽，以及设置主从关系 redis-cli --cluster create --cluster-replicas
每个主机的从机数量主机IP:主机端口主机IP:主机端口主机IP:主机端口从机IP:从机端口从机IP:从机端口从机IP:从机端口输入yes确定分配完成去中心化模式搭建;
命令行客户端:
redis-cli -c -h 进入的IP -p 端口