对于过期键值的删除有三种常见的做法
Redis采用了惰性删除和定期删除,可以在合理使用CPU时间和避免浪费内存空间上取得平衡。另外在定期删除策略上也做了优化,每次执行定期删除会有最大执行时间限制,如果达到时间上限还没执行完会记录当前位置并停止处理,下次从纪录点继续执行
Redis是内存数据库,当Redis进程退出后,保存在内存中的数据就会丢失。为了解决这个问题,Redis提供了RDB跟AOF两种方式,将数据库状态进行持久化到磁盘中
RDB文件保存了Redis在某个时间点上的数据库状态,类似于快照,可以使用RDB文件将Redis数据恢复。Redis提供了两个命令生成RDB文件,分别是SAVE跟BGSAVE,区别是SAVE是由服务器进程直接执行,会阻塞服务器,BGSAVE是由子线程执行保存,不会阻塞服务器。
Redis默认设置了多个保存条件,900秒内对数据库修改1次、300秒内对数据库修改10次、60秒内对数据库修改10000次,服务器中有一个周期性执行的serverCron默认每隔100毫秒执行一次,在serverCron执行时检查只要其中任何一个条件得到满足就会执行BGSAVE命令自动保存。
除了RDB外,Redis还提供了AOF持久化功能,区别于RDB是通过直接保存数据库键值,AOF是通过保存服务器执行的写命令来记录数据库状态。当服务器的AOF功能打开的时候,每当服务器进行写操作,都会有对应的写命令记录在AOF的缓冲区中,缓冲区中的数据会根据配置持久化到文件中,目前AOF提供三种持久化的选项,分别是always(将缓冲区所有内容写入并同步到文件)、erverysec(每秒将缓冲区内容写入到文件)、no(由操作系统控制何时同步)
使用AOF还原数据库状态流程
前面讲到,AOF文件是具体执行的写命令记录,随着执行命令的次数越来越多,AOF文件内容会越来越大,为了解决这个问题,Redis提供了AOF文件重写的功能。通过这个功能,Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件,新旧两个AOF文件所保存的数据库状态相同,但新AOF文件不会包含冗余命令。实现原理是从数据库中读取键当前的值,然后用生成一条命令去代替之前记录这个键值的多条命令。
例如:
实际执行命令
sadd animals "cat"
sadd animals "dog" "panda" "tiger"
srem animal "cat"
sadd animals "lion" "cat"
重写后保存命令
sadd animals "dog" "panda" "tiger" "lion" "cat"
另外AOF重写一般是使用子线程在后台执行,在重写期间服务器仍然继续处理客户端的请求。在重写期间,如果服务端处理的请求导致现有的数据库内容被修改,就会导致服务器当前的数据库状态与重写后的AOF文件保存的数据库状态不一致
为了解决这个问题,Redis服务器中设置了AOF重写缓冲区,会将AOF重写期间执行的写命令追加到AOF重写缓冲区中,等子线程重写完成后,再将缓冲区内容追加到AOF文件末尾,保持数据库状态一致
Redis的复制功能分为同步和命令传播两个操作:
这个复制功能对于初次复制来讲能够很好地完成任务,但是对于断线后重复制来说,有可能从服务器跟主服务器数据只发生了几次变化甚至完全一致,但这个复制却要重新全量的覆盖一遍从服务器,效率非常低。为此Redis在2.8版本后开始,改进了复制功能,适用PSYNC命令代替SYNC命令。
PSYNC命令分为完整重同步和部分重同步两种操作
主观下线:Sentinel对redis服务节点默认每秒发送心跳检测节点是否在线,但Redis实例连续向Sentinel返回无效回复,该Sentinel节点会将实例标记为主观下线状态。
客观下线:当Sentinel将一个主服务器判断为主观下线之后,为了确认这个主服务器是否真的下线了,它会向同样监视这一主服务器的其它Sentinel进行询问,看它们是否也认为主服务器已经进入了下线状态(可以是主观下线或者客观下线)。当Sentinel从其他Sentinel那里接收到足够数量的已下线判断后,Sentinel就会将主服务判定为客观下线,并对主服务执行故障转移。
Sentinel确认主服务已经客观下线后,会要求其他Sentinel节点将自己设为执行故障转移的节点,其他节点采用抢占的方式,只接受第一个到达的抢占请求,并返回当前节点认可的执行节点ID,通过统计,可以得到最终过半数胜出的领头Sentinel执行故障转移
在选举产生出领头Sentinel之后,领头Sentinel将对已下线的主服务器执行故障转移操作,该操作包含以下三个步骤:
本文来自博客园,作者:IAyue,转载请注明原文链接:https://www.cnblogs.com/zmj-pr/p/17513877.html
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://www.cnblogs.com/zmj-pr/p/17513877.html
内容来源于网络,如有侵权,请联系作者删除!