杭州网站建设响应式,目前基金会网站做的比较好的,seo学习,wordpress cookies因预料之外的输出被阻止文章目录 1、Redis持久化1.1 RDB1.2 AOF1.3 RDB与AOF的对比 2、数据过期策略#xff08;删除策略#xff09;2.1 惰性删除2.2 定期删除 3、数据淘汰策略4、主从复制4.1 主从全量同步4.2 增量同步 5、哨兵模式5.1 服务状态监控5.2 哨兵选主规则5.3 哨兵模式下#xff0c;Redi… 文章目录 1、Redis持久化1.1 RDB1.2 AOF1.3 RDB与AOF的对比 2、数据过期策略删除策略2.1 惰性删除2.2 定期删除 3、数据淘汰策略4、主从复制4.1 主从全量同步4.2 增量同步 5、哨兵模式5.1 服务状态监控5.2 哨兵选主规则5.3 哨兵模式下Redis集群的脑裂 6、分片集群7、Redis快的原因IO多路复用 Redis网络模型7.1 用户空间和内核空间7.2 阻塞IO模型7.3 非阻塞IO模型7.4 IO多路复用 8、面试 1、Redis持久化
1.1 RDB
RDB即Redis Database Backup file导出数据快照到磁盘。如果Redis实例宕机也可读取快照文件恢复数据一般bgsave以防文件过大时阻塞其他请求 也可根据配置触发RDBredis.conf RDB的执行原理bgsave开始时fork主进程得到一个子进程类似克隆把存有映射关系的页表拷贝给了子进程页表中存了分配给进程的内存虚拟地址和物理内存物理地址 的映射关系。子进程根据页表去读取数据并写入RDB文件主进程则继续回去处理客户端请求。 主进程和子进程之间会使用写时复制copy-on-write机制此时原内存空间为read-only主进程如果要进行写操作会拷贝一份数据进行写操作且后面读操作也是基于拷贝的副本去读因此basave期间进行更新的那部分数据不会同步到快照文件中。
1.2 AOF
Append Only File追加文件类似日志文件记录每一个写命令 相关配置redis.conf 记录写命令到AOF文件有不同的策略即刷盘策略 everysec策略适用场景最多。此外多次set同一个key没必要重复记录记录最后一次即可可用bgrewriteaof命令让AOF重写降低文件大小。 关于触发重写的阈值配置 1.3 RDB与AOF的对比 2、数据过期策略删除策略
即数据过期后何时从内存中删除。
惰性删除定期删除
2.1 惰性删除
key过期后不管直到下次get key发现过期就删除否则正常返回 优点不多占用CPU缺点如果有key过期但后面没被get过则这块空间一直得不到释放
2.2 定期删除
每隔一段时间对一定数量的key进行检查删除过期的key。有两种模式
SLOW模式定时任务执行频率默认10hz即每个执行周期100ms每次不超过25ms可在redis.conf调整FAST模式频率不固定但两次间隔不低于2ms每次耗时不超过1ms
Redis的过期策略是惰性删除 定期删除配合。
3、数据淘汰策略
如果缓存过多内存沾满了如何处理 ⇒ 根据配置的策略删除一定的数据 ⇒ 数据淘汰策略
noeviction不淘汰内存满了就不允许写抛错是默认的策略volatile-ttlTTL越小越先被淘汰allkeys-randon全体key随机淘汰volatile-random设置了TTL的key随机淘汰allkeys-lru全体key按LRU算法淘汰volatile-lru设置了TTL的key按LRU淘汰allkeys-lfu全体key按LFU算法淘汰volatile-lfu设置了TTL的key按LFU淘汰 数据库有 1000 万数据 ,Redis 只能缓存 20w 数据如何保证 Redis 中的数据都是热点数据
⇒ allkeys-lru策略挑选最近没怎么使用的数据淘汰留下热点数据。且如果有指定的需求可以用volatile-lru 置顶数据不设置过期时间以保证这些数据永不被删除
4、主从复制
Redis的三种模式
单机模式集群模式哨兵模式
单节点的Redis并发能力有上限切为Redis主从集群实现读写分离提高并发能力如下一台服务器又查又写并为一台写两台查查的并发上限翻倍 读写分离后数据的同步方案
4.1 主从全量同步 Replication Id即replid数据集的标记该ID相同则说明对应的数据集是同一个每个master有唯一的replidslave会继承master的replid。 offset偏移量repl_baklog文件记录的数据越多offset越大
全量同步时如果master和slave的replid不相等则master执行basave生成快照给slave去同步。根据前面的写时复制机制basave期间master接收到的写请求不会同步到快照文件中因此slave加载完快照文件后还要执行从master收到的repl_baklog文件该文件记录了basave期间master额外收到的写指令。
如果replid相等但master的offset为80slave的offset为50则slave把repl_baklog文件50-80的这一段命令再执行一下
4.2 增量同步
常用于slave节点重启后。slave发送自己的replid和offset到master如果replid不一致则是第一次同步后续同全量。
如果replid一致则不是第一次同步。根据offset发送对应片段的repl_baklog的命令到slave 5、哨兵模式
上面的主从集群并不能实现高可用master一挂丧失写的能力 ⇒ 引入哨兵机制实现主从集群自动故障恢复。哨兵做为Redis集群的一个节点其作用
节点状态监控不断检查master、各个slave的健康状况自动故障恢复如果master故障则从slave中提升一个出来当master即使后面master再恢复也以新的master为主节点通知集群故障转移后将新的master、slave信息推到Redis客户端
5.1 服务状态监控
哨兵Sentinel基于心跳机制监测节点状态每1秒向集群每个节点发送ping命令
主观下线某一个Sentienl发现某节点在规定时间未响应回pong到Sentinel认为该节点主观下线客观下线指定数量常设为Sentienl数量的一半的Sentintl都认为这个节点主观下线则该节点客观下线 5.2 哨兵选主规则
排除不在线的、响应慢的排除与主节点断开时间长的断开时间长读写分离下数据不全根据优先级、offset。若slave-prority一样offset越大优先级越高看运行ID越小优先级越高
5.3 哨兵模式下Redis集群的脑裂
下面是一个正常的哨兵模式架构 如下假如Sentinel、master、slave处于不同的网络环境当Sentinel因网络原因连不上master时其会去重新选举出一个master。但原来的master客户端是可以连接通的此时就出现了两个master即发生了脑裂。 再到后来网络恢复原来的master会被降为slave前面提到的恢复后以新master为主节点并从新的master去同步数据。即清空自己的数据导入新master的快照文件如此脑裂期间客户端写到master的数据就会丢失。
关于集群脑裂问题的解决可配置这两个参数
//最少的slave节点为1个
min-replicas-to-write 1
//数据复制和同步的延迟不能超过5秒
min-replicas-max-lag 5如此脑裂时往旧的master写数据因其slave数量为0就会写入失败。且网络恢复后数据同步也会因延迟过大而报错。
6、分片集群
主从主写从读集群和哨兵解决了高可用、高并发读的问题但存在两个问题
海量数据的存储问题高并发写的问题
由此 ⇒ Redis分片集群特点
集群中有多个master每个master保存不同的数据由此每加一个master并发写的能力就加一段如从2n到3n⇒ 解决高并发写每个master有多个slave ⇒ 解决高并发读master之间互相ping以检测健康状态起到了哨兵的作用。如果多个master都认为某个master挂了那这个master客观下线 ⇒ 类似哨兵客户端可请求访问集群的任意节点最终都会被转发到正确的节点上去查写 至于客户端的请求会被转发到正确的节点上去是通过哈希槽实现。Redis集群引入哈希槽的概念整个集群有16384个哈希槽。
set或者get某个key ⇒ 这个key通过CRC16校验后对16384取模来决定放哪个槽 ⇒ 集群每个master负责一定范围的槽 除了key去决定放哪个槽也可以在key前加个{有效部分}如上面{aaa}如此这些key就都可以被分到同一个master节点
7、Redis快的原因IO多路复用 Redis网络模型
Redis是单线程的但为什么还那么快
纯内存操作执行速度快单线程下避免了上下文切换以及线程安全问题的考虑和实现使用了I/O多路复用模型是非阻塞IO
7.1 用户空间和内核空间
Linux系统中一个进程使用的内存有两部分
用户空间权限低不能直接调用系统资源只能通过内核提供的接口来调用内核空间可调用一切系统资源 关于以上空间的理解用户A打开微信给其好友B发生了一条消息message1。启动微信即开了一个进程编辑信息message1相当于在服务器的用户空间想发送message1就要过网卡然后发给用户B。
而用户空间不能直接调用系统资源硬件网卡因此整个流程为把用户缓冲区数据拷贝到内核缓冲区 ⇒ 写入硬件设备。用户B给A回复后读数据则是从网卡设备读到内核缓冲区再拷贝到用户缓冲区。
以上影响性能的有两个点
用户空间读数据时要等待内核空间给它内核空间数据未就绪就一直空等数据来回拷贝
7.2 阻塞IO模型
用户进程在以下两个阶段都被阻塞
阶段1等待内核从系统硬件资源中去准备数据阶段2数据从内核空间拷贝到用户空间 7.3 非阻塞IO模型
用户进程在阶段一不会被阻塞如果内核空间没数据会返回一个异常给用户进程用户进程可以过会儿再去读。但阶段二从内核空间拷贝到用户空间的时候依然阻塞 7.4 IO多路复用
单个线程去监听多个Socket监听的过程用户线程是阻塞的但只要出现一个Socket可读或可写用户线程就会收到通知去干活儿
IO多路复用监听Socket有多种实现
selectpollepoll 以点餐为例select和poll就像吧台有一盏灯底下一群顾客人手一个按钮想好吃什么时按下按钮吧台灯亮。但此时吧台显示不出具体是哪个顾客要点餐只是知道有人要点餐了。服务员就得挨个去问是不是你要点餐
epoll则是顾客的按钮不再控制吧台的灯而是控制吧台的计算机屏幕顾客按一下屏幕显示顾客桌号 select 和 poll 只会通知用户进程有 Socket 就绪但不确定具体是哪个Socket 需要用户进程逐个遍历 Socket 来确认 epoll 则会在通知用户进程 Socket 就绪的同时把已就绪的 Socket 写入用户空间 最后Redis的网络模型有IO多路复用用来监听客户端的连接Socket但每个Socket下做的事可能不一样有读请求、写请求因此Redis再用事件派发机制转发到对应的处理器 8、面试
