帮人做网站收费合法吗,河北项目网手机版,做软件的声称发现网站漏洞,光明网一、RDB和AOF持久化
redis的数据一般保存在内存#xff0c;那么当突然宕机#xff0c;岂不是数据就丢失了#xff0c;因此redis实现了将数据持久化的方式#xff1a;RDB和AOF两种持久化方式。
1.1 RDB持久化#xff08;bgsave#xff09;
redis支持快照的方式进行数据…一、RDB和AOF持久化
redis的数据一般保存在内存那么当突然宕机岂不是数据就丢失了因此redis实现了将数据持久化的方式RDB和AOF两种持久化方式。
1.1 RDB持久化bgsave
redis支持快照的方式进行数据持久化将redis的内存数据直接保存在磁盘上生成RDB文件。
主要流程主进程fork出来子进程然后主进程继续接收用户请求子进程开始进行数据拷贝。这里有个问题需要考虑当子进程进行数据拷贝的时候主进程还在接收请求那么主进程就会在内存上进行修改此时主子进程内存将会分离。
那么redis什么时候进行数据持久化呢在redis中会有一些配置来设置这个频率。例如
save 900 1
save 300 60
save 60 10000
但是RDB得缺点也很明显如果频率太快那么RDB执行频率高导致性能下降。如果频率太慢那么在中间这段时间可能造成数据丢失。 1.2 AOF持久化
由于RDB的持久化存在数据丢失问题因此redis在RDB的基础上又开始支持aof模式。这中模式简单来讲就是将redis的写命令写入到一个文件中append of file。 例如当用户set一个key的时候除了将内存中的key进行修改还会将set命令写入到aof文件中这样一来即使redis宕机那么我们也能从aof文件中将数据恢复。 那么有一个问题redis本来是内存数据库数据操作非常快当加入aof的时候却进行了io磁盘操作这岂不是很慢
redis中是通过aof缓冲区来解决的当redis执行写命令的时候将命令放入到内存缓冲区中当到达一秒的时候every second将缓冲区得到数据刷入到磁盘。 1.3 AOF重写瘦身
由于aof文件是记录的写命令因此随着时间的推移aof文件将会非常大如果aof文件过大那么在redis重启的时候数据恢复将会非常慢。
因此我们需要解决这个问题。
两种方案
1、重新遍历内存将数据重新写入一个新的aof中。
2、执行一次RDB然后将执行过程中的写命令aof。即RDBAOF形式。
当aof文件过大就会执行aof重写。此时将会开辟一个新的子进程进行重写主进程依然继续处理用户请求。子进程遍历内存将数据以命令的形式写入新的aof中。
注意此过程主进程还依然执行那么新的写命令怎么办呢这里引入了【aof重写缓冲区】新的命令将会放入这个缓冲区中当子进程重写结束后将aof重写缓冲区的数据在放入aof文件中。 二、Redis主从架构
之前我们讲的原理都是在redis单个机器上单点的机器从可用性和稳定性上来说都太弱了因此需要进行主从架构提升系统性能高可用。 1、在集群中启动3个实例
2、在其中两个机器下执行 slaveof或者replicateof 主ip 主port 来进行连接
通过日志可以看到当某个机器链接主服务器的时候主服务器打印如下日志
其中重要的几个信息
1、replication id
2、BGSAVE
通过这两个信息可以看出在主从同步的一开始需要副本id信息和rdb文件。
同时用info命令来查看主服务器的状态
可以看到除了上述两个信息之外还有两个信息 1、offset 偏移量
2、lag 积压 2.1 主从同步原理
2.1.1 第一次同步全量同步
当从节点第一次链接主节点 主节点将会把全量数据都发送从节点。
1、首先先把master的版本发送从节点。
2、执行bgsave将master数据快照然后发送从节点。从节点加载RDB文件
3、master将新的操作命令放入baklog文件中并发送到从节点中从节点执行baklog
4、后续链接过程中master不断将baklog里面的命令发送给slave。 那么master是如何知道slave是第一次链接呢。
这里就用到了重要的参数replication id如果slave的replicationid和maser的不一样则说明是第一次。
那么master是如何不断的发送baklog呢
这里就用到了offset 偏移量当slave的offset小于master的offset则说明slave落后于master需要及时同步。 2.1.2 非第一次同步增量同步
当slave进行重启的时候重新链接master的时候会发起增量同步这个时候slave将replicationid和offset传给master。master将offset之后的数据发送给slave。 需要注意baklog文件是一个环形如果slave远远落后于master那么slave将无法进行增量同步。 此时只能进行全量同步。 在这里顺便提一下在全量同步的过程中需要rdb所以性能可能比较慢是否有手段来提升性能呢
1、无磁盘复制。即在生成RDB文件的时候不去写磁盘而是直接写入网络io流中。【适用于磁盘满网速快的环境】
2、控制单个redis的内存大小这样RDB文件也不会很大
3、可以尝试利用主--从--从架构减轻master压力 2.2 哨兵机制
redis的哨兵主要是为了检测redis主从架构的可用性。另外哨兵会协调主从之间的选举。redis的每个哨兵会不断地间隔一秒向主从发送ping。
主观下线如果某个哨兵发现某个机器掉线则认为主观下线。
客观下线如果其他哨兵也发现机器掉线超过了配置的阈值则认为客观下线。 如果一旦机器被认定为客观下线如果是主服务器挂了则需要开始选举那么如何选举呢。 最重要的一点是当前slave机器的offsetoffset约新则优先级越高。
这里和zk不一样zk是自己协调而redis是由哨兵协调哨兵根据各个slave的offset的偏移情况而哨兵针对主服务器的协调才和zk一样 1. **收集候选从服务器列表**当 Sentinel 实例们确认主服务器已经下线时它们会开始寻找合适的从服务器作为新的主服务器。Sentinel 实例会根据从服务器的优先级、复制偏移量等因素进行评估筛选出一个候选从服务器列表。
2. **发起投票请求**每个 Sentinel 实例都会向其他 Sentinel 实例发送一个包含候选从服务器列表的投票请求。投票请求中包含了每个候选从服务器的信息如 ID、优先级、复制偏移量等。
3. **接收并处理投票请求**收到投票请求的 Sentinel 实例会对请求中的候选从服务器列表进行评估然后返回自己的投票结果。每个 Sentinel 实例都可以根据自己的策略和规则来决定投给哪个候选从服务器。
4. **统计投票结果**发起投票请求的 Sentinel 实例会等待一段时间收集其他 Sentinel 实例的投票结果。当超过半数的 Sentinel 实例返回投票结果时就可以确定哪个从服务器得到了最多的票数。
5. **选择得票最多的从服务器作为新的主服务器**得到最多票数的从服务器将成为新的主服务器。Sentinel 实例会选择一个 Sentinel 实例作为代表负责执行故障转移操作将选定的从服务器转变为新的主服务器。 6. **更新从服务器配置**代表 Sentinel 实例会向其他从服务器发送命令修改它们的配置使它们指向新的主服务器。
7. **监控新的主服务器**故障转移完成后Sentinel 实例会继续监视新的主服务器以及其他从服务器确保整个集群的健康状态。 三、Redis集群架构
redis的主从模式存在一些缺点
1、这种基于主从的模式需要主和从之间进行rdb复制而RDB复制是一个耗性能的操作因此一般来讲redis的内存不宜设置过大。但是如果不设置过大那就意味着存储能力弱如果有大量数据进行存储那怎么办
2、主从模式主要是为了抗住高并发的读。但是写操作还是打到主节点。如果有高并发的写操作那该怎么办呢
因此redis提供了集群模式。
集群模式下由多个master构成并且每个master都分配一定的slot。 参考
互联网大厂技术-Redis-集群模型、架构原理、难点应用场景、高频面试问题详解_redis主观下线 客观下线-CSDN博客
