用ssh做的网站,前端开发面试会被问到的一些问题,南京百度网站排名,企业所得税减免政策2023Redis的数据全部在内存里#xff0c;如果突然宕机#xff0c;数据就会全部丢失#xff0c;因此必须有一种机制来保证Redis的数据不会因为故障而丢失#xff0c;这种机制就是Redis的持久化机制。Redis的持久化有两种#xff0c;第一种是快照#xff0c;第二种是AOF日志。快…Redis的数据全部在内存里如果突然宕机数据就会全部丢失因此必须有一种机制来保证Redis的数据不会因为故障而丢失这种机制就是Redis的持久化机制。Redis的持久化有两种第一种是快照第二种是AOF日志。快照是一次性全量备份AOF日志是连续的增量备份。第一种快照是内存数据的二进制序列化形式在存储上非常紧凑而第二种AOF日志记录的是内存数据修改的指令记录文本。AOF日志在长期的运行过程中会变得无比庞大数据库重启时需要加载AOF日志进行指令重放这个时间就会很漫长所以需要定期进行AOF重写给AOF日志瘦身。快照RDB的原理Redis是单线程程序这个线程要同时负责1、多个客户端socket的并发读写操作
2、内存数据结构的逻辑重写在服务线上请求的同时Redis还需要进行内存快照内存快照要求Redis必须进行文件io操作可是文件io操作不能使用多路复用的API。这就意味着单线程在服务器上请求的同时还要进行文件io操作而文件io操作会严重拖累服务器的性能。另外为了不阻塞线上的业务Redis需要一边持久化一边相应客户端的请求。持久化的同时内存数据结构还在变化比如一个大型的hash字典正在持久化的时候这时一个请求过来把它给删掉了或者修改了可是还没持久化完毕这怎么办Redis使用操作系统的多进程COWCopy on Write机制来实现快照持久化Fork多进程Redis在持久化的时候会调用glicb的函数fork产生一个子进程快照持久化完全交给子进程来处理父进程继续处理客户端业务请求。子进程刚刚产生的时候和父进程共享内存里的代码段和数据段。子进程做数据持久化的时候不会修改现有内存数据结构它只是对数据结构进行遍历读取然后序列化写到磁盘上。但是父进程不一样必须持续服务客户端的请求然后对内存数据结构进行不断的修改。这个时候就会使用OS的COW机制来进行数据段页面的分离。如上图所示数据段是由很多操作系统的页面组合而成当父进程对其中一个页面的数据进行修改时会将被共享的页面复制一份分离出来然后对复制的这个页面进行修改。这时子进程相应的页面是没有变化的还是进程产生时那一瞬间的数据。随着父进程修改操作的持续进行越来越多的共享页面被分离出来内存就会持续增长但是也不会超过原有数据的2倍大小。另外Redis实例里的冷数据占的比例往往是比较高的所以很少会出现所有的页面都被分离的情况被分离的往往只有其中一部分页面。每个页面的大小只有4KB一个Redis实例里面一般都会有成千上万个页面。子进程因为数据没有变化它能看到的内存里的数据在进程产生的那一瞬间就凝固了再也不会发生改变。这也是为何Redis的持久化叫做“快照”的原因了。接下来子进程就可以安心的遍历数据进行序列化写到磁盘中了。那现在就有一个问题了父进程如果占了10G那么子进程也占10Gredis的空间够不够呢持久化的时候速度快不快呢其实父进程和子进程只保存了物理机的内存的地址两份地址而已指向的都是内存。所就不存在两个都占10G了。而父进程和子进程是通过fork出来的还有就是子进程也不是一下就创建出来其中的COW是copy on write意思是写的时候才复制地址。创建子进程并不发生复制玩的是指针。例如看一下fork 输入 man 2 fork 命令然后输入/copyNOTES Under Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs is the time and memory required to duplicate the parent’s page tables, and to create a unique task structure for the child. Since version 2.3.3, rather than invoking the kernel’s fork() system call, the glibc fork() wrapper that is provided as part of the NPTL threading implementa- tion invokes clone(2) with flags that provide the same effect as the traditional system call. The glibc wrapper invokes any fork handlers that have been estab- lished using pthread_atfork(3).在Linux下fork()是使用写时复制的页面实现的因此它带来的唯一损失是复制父页面表和为子页面创建唯一的任务结构所需的时间和内存。自从2.3.3版本以来作为NPTL线程实现一部分提供的glibc fork()包装器没有调用内核的fork()系统调用而是使用提供与传统系统调用相同效果的标志调用clone(2)。glibc包装器调用使用pthread_atfork(3)建立的任何fork处理程序。就是父进程进行修改的时候会新创建一个然后指向而子进程还是指向原来的。fork是系统调用copy on write是内核机制。
redis调用fork优点是速度快占用空间小。关机维护的时候用save命令其余的一般都是bgsave达到60秒了 操作数达到10000满足其中一个就会写rdb。依次类推如果到900秒了操作数达到1笔的时候满足其中一个就会写RDB。Redis默认是开启RDB的如果想关闭那么就把下图中这个删除或者 save 那么持久化的RDB文件存储在哪呢继续往下翻RDB的优缺点优点1压缩后的二进制文件适用于备份、全量复制用于灾难恢复 2加载RDB恢复数据远快于AOF方式缺点1无法做到实时持久化每次都要创建子进程频繁操作成本过高 2保存后的二进制文件存在老版本不兼容新版本rdb文件的问题 3不支持拉链只有一个dump.rdb 4丢失数据相对较多窗口数据容易丢失8点做了一个rdb假设9点又要做一个rdb此时断电了那么就丢了一个小时的数据。这是全量备份技术的通用的缺点。以上是RDB。针对RDB不适合实时持久化redis提供了AOF持久化方式来解决AOFappend only file 只会向文件追加AOF日志存储的是Redis服务器的顺序指令序列AOF日志只记录对内存进行修改的指令记录假设AOF日志记录了自Redis实例创建以来所有的修改性指令序列那么就可以通过对一个空的Redis实例顺序执行所有的指令--也就是“重放”来恢复Redis当前实例的内存数据结构的状态。Redis会在收到客户端修改指令后进行参数校验、逻辑处理如果没问题就立即将该指令文本存储到AOF日志中也就是说先执行指令才将日志存盘。这点不同于hbase等存储引擎他们都是先存储日志再做逻辑处理的。Redis在长期运行的过程中AOF日志会越来越长如果实例宕机重启重放整个AOF日志会非常耗时导致Redis长时间无法对外提供服务所以需要对AOF日志瘦身。AOF重写Redis 提供了 bgrewriteaof 指令用于对AOF日志进行瘦身原理是开辟一个子进程对内存进行遍历转换成一系列Redis的操作指令序列化到一个新的AOF日志文件中。序列化完毕后再将操作期间发生增量AOF日志追加到这个新的AOF日志文件中追加完毕后就立即替代旧的AOF日志文件了瘦身工作就完成了。而重写的意义是以后加载速度变快减小AOF体积比如set k1 a set k1 b set k1 c,就会在aof文件中出现这些记录而此时k1对应的value是Ca和b是没用的经过bgrewriteaof命令后aof文件中将不再有a和b的影子就只保留了k1 c。fsyncAOF日志是以文件的形式存在的当程序对AOF日志文件进行写操作时实际上是将内容写到了内核为文件描述符File Descriptors 简称fd 很多fd就是 fds分配到一个内存缓冲中然后内核会异步将脏数据刷回到磁盘。这就意味着如果突然宕机AOF日志内容可能还没来得及完全刷到磁盘中这个时候就会出现日志丢失这怎么办不急Linux的glibc提供了 fsyncint fd函数可以将指定文件的内容强制从内核缓存刷到磁盘。只要Redis进程实时调用fsync函数就可以保证AOF日志不丢失。但是fsync是磁盘io操作很慢如果Redis执行一条指令就要 fsync 一次那么Redis高性能的地位就不保了。所以在生产环境的服务器中Redis通常是每隔1s左右执行一次 fsync 操作这个1s周期是可以配置的。这是在数据安全性和性能之间做的一个折中在保持高性能的同时尽可能是数据少丢失。在Redis的主节点不会进行持久化操作因为无论是AOF还是RDB都比较耗资源持久化操作主要在从节点进行。从节点是备份节点没有来自客户端请求的压力它的操作系统资源往往比较充沛。但是如果出现网络分区从节点长期连不上主节点就会出现数据不一致的问题特别是在网络分区出现的情况下主节点一旦不小心宕机了那么数据就会丢失所以在生产环境下要做好实时监控工作保证网络畅通或者能快速修复。另外还应该再增加一个从节点以降低网络分区的概率只要有一个从节点数据同步正常数据也就不会轻易丢失。假设AOF文件是10T那么恢复的时候不会内存溢出因为只要写写写直到AOF文件成了10T,但凡能写到10个T那肯定没有内存溢出。所以恢复的时候也不会内存溢出。如果要溢出的话那么早就溢出了还能把AOF文件写到10个T么下来说AOF的配置vi 6379.conf 不是vim 用 vi 打开 上面写错了。总是每秒从不。红框中的fsync上面说过了Redis4.0混合持久化重启Redis时很少使用rdb的方式恢复内存状态因为rdb会丢失大量数据。通常使用AOF日志重放但是重放AOF日志相对于使用rdb来说慢很多这样在Redis实例很大的情况下启动需要花很长的时间。Redis4.0带来了一个新的持久化选项--混合持久化。将rdb的内容和增量的AOF日志文件存在一起。这里的AOF不再是全量的日志而是自持久化开始到持久化结束的这段时间发生的增量AOF日志通常这部分AOF日志很小。一定是重写之后才开始混合比如开启了混合持久化后set k1 v1 set k1 v2 等等 一定是输入 bgrewriteaof 命令后前面的一系列操作就变成了 RDB形式保存在aof文件中后续继续set k3 v3 的时候是以明文的形式追加到aof文件中于是在Redis重启的时候可以先加载rdb的内容然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放重启效率得到大幅提升。下来演示一下redis持久化下来改配置文件来验证rdb和aof是什么概念vi /etc/redis/6379.conf把daemonize yes改成daemonize no 表示不让redis变成后台服务进程运行成为前台阻塞的运行。打开AOF持久化因为RDB是默认开启的不用管原来是no改成yes然后把混合持久化关闭现在准备工作已经做好了打开了aof打开了rdb默认开启关闭了混合持久化。我现在是在root根目录然后把1号shell窗口切换到etc下的redis目录然后切换到2号shell窗口然后切回到1号shell窗口启动redis然后切回到2号shell窗口LL看一下然后 vi appendonly.aof发现什么都没有记录然后在3号shell打开 redis 6379 客户端然后设置一个kv。set k1 hello然后切回到2号shell。LL看一下因为不满足rdb的那三个条件 所以可以看到还是只落了一个aof文件打开这个aof文件看一下 *2代表两个元素组成 一个是 select 另一个是 0号库然后在3号shell 继续输入 set k2 xxoo然后切换到2号shell 查看 aof文件然后想一下 把这两笔数据 弄到rdb里面去。在3号shell 输入 bgsave然后在2号shell查看然后1号shell窗口 会发生 然后切换到2号shell打开这个dump.rdb下来看一下 aof 的重写功能那么aof文件会相应的增长很多对k1的操作那现在k1的最终value是c所以以上k1之前的value值都是垃圾。所以给aof文件瘦身一下瘦身前是170字节然后在3号shell 窗口 输入bgrewriteaof然后在2号shell 看一下 目前 aof的大小 然后打开aof文件然后在1号shell 中 ctrl c 结束把3号shell的客户端 也退出去 exit把2号的aof和rdb文件也全部删除 rm -fr ./*然后切到1号shell改配置开启混合持久化保存后启动redis然后2号shell 里还是一个空的 aof没毛病然后3号shell开启redis客户端 set 两次然后在2号shell 看一下然并卵不是混合持久化。然后继续3号shell 写写完后bgrewriteaof现在是混合持久化所以查看2号shell没有增量前是103字节打开可以看到变成了二进制的rdb了。和以前的aof文件不一样然后继续set两条记录 3号shell然后转到2号shell查看aof文件变成104字节了。我不知道为什么我打开看不到增量的内容可能是io的延迟吧不知道出什么bug了。这下能看了dump.rdbappendonly.aofappendonly yes (默认不开启为no)
