网站里做个子网页怎么做,什么是网站设计种类,建设银行官网网站首页,免费wap自助建站火星建站一、为什么需要持久化 redis里有10gb数据#xff0c;突然停电或者意外宕机了#xff0c;再启动的时候10gb都没了#xff1f;#xff01;所以需要持久化#xff0c;宕机后再通过持久化文件将数据恢复。
二、优缺点
1、rdb文件 rdb文件都是二进制#xff0c;很小。比如内…一、为什么需要持久化 redis里有10gb数据突然停电或者意外宕机了再启动的时候10gb都没了所以需要持久化宕机后再通过持久化文件将数据恢复。
二、优缺点
1、rdb文件 rdb文件都是二进制很小。比如内存数据有10gbrdb文件可能就1gb只是举例。
2、优点 由于rdb文件都是二进制文件所以很小在灾难恢复的时候会快些。 他的效率主进程处理命令的效率而不是持久化的效率相对于aof要高bgsave而不是save因为每来个请求他都不会处理任何事只是bgsave的时候他会fork()子进程且可能copyonwrite但copyonwrite只是一个寻址的过程纳秒级别的。而aof每次都是写盘操作毫秒级别。没法比。
3、缺点 数据可靠性比aof低也就是会丢失的多。因为aof可以配置每秒都持久化或者每个命令处理完就持久化一次这种高频率的操作而rdb的话虽然也是靠配置进行bgsave但是没有aof配置那么灵活也没aof持久化快因为rdb每次全量aof每次只追加。
三、RDB持久化的两种方法 配置文件也可以配置触发rdb的规则。配置文件配置的规则采取的是bgsave的原理。
1、save 1.1、描述 同步、阻塞 1.2、缺点 致命的问题持久化的时候redis服务阻塞准确的说会阻塞当前执行save命令的线程但是redis是单线程的所以整个服务会阻塞不能继对外提供请求GG数据量小的话肯定影响不大数据量大呢每次复制需要1小时那就相当于停机一小时。
2、bgsave 2.1、描述 异步、非阻塞 2.2、原理 fork() copyonwrite 2.3、优点 他可以一边进行持久化一边对外提供读写服务互不影响新写的数据对我持久化不会造成数据影响你持久化的过程中报错或者耗时太久都对我当前对外提供请求的服务不会产生任何影响。持久化完会将新的rdb文件覆盖之前的。
四、fork() bgsave原理是fork() copyonwrite那么现在来聊一下fork()
1、fork()是什么 fork()是unix和linux这种操作系统的一个api而不是Redis的api。
2、fork()有什么用 fork()用于创建一个子进程注意是子进程不是子线程。fork()出来的进程共享其父类的内存数据。仅仅是共享fork()出子进程的那一刻的内存数据后期主进程修改数据对子进程不可见同理子进程修改的数据对主进程也不可见。比如A进程fork()了一个子进程B那么A进程就称之为主进程这时候主进程子进程所指向的内存空间是同一个所以他们的数据一致。但是A修改了内存上的一条数据这时候B是看不到的A新增一条数据删除一条数据B都是看不到的。而且子进程B出问题了对我主进程A完全没影响我依然可以对外提供服务但是主进程挂了子进程也必须跟随一起挂。这一点有点像守护线程的概念。Redis正是巧妙的运用了fork()这个牛逼的api来完成RDB的持久化操作。
五、Redis中的fork() Redis巧妙的运用了fork()。当bgsave执行时Redis主进程会判断当前是否有fork()出来的子进程若有则忽略若没有则会fork()出一个子进程来执行rdb文件持久化的工作子进程与Redis主进程共享同一份内存空间所以子进程可以搞他的rdb文件持久化工作主进程又能继续他的对外提供服务二者互不影响。我们说了他们之后的修改内存数据对彼此不可见但是明明指向的都是同一块内存空间这是咋搞得肯定不可能是fork()出来子进程后顺带复制了一份数据出来如果是这样的话比如我有4g内存那么其实最大有限空间是2g我要给rdb留出一半空间来扯淡一样那他咋做的采取了copyonwrite技术。
六、copyonwrite
很简单现在不就是主进程和子进程共享了一块内存空间怎么做到的彼此更改互不影响吗(执行快照时数据能被修改吗写时复制技术Copy-On-Write, COW)
1、原理 主进程fork()子进程之后内核把主进程中所有的内存页的权限都设为read-only然后子进程的地址空间指向主进程。这也就是共享了主进程的内存当其中某个进程写内存时(这里肯定是主进程写因为子进程只负责rdb文件持久化工作不参与客户端的请求)CPU硬件检测到内存页是read-only的于是触发页异常中断page-fault陷入内核的一个中断例程。中断例程中内核就会把触发的异常的页复制一份这里仅仅复制异常页也就是所修改的那个数据页而不是内存中的全部数据于是主子进程各自持有独立的一份。 copyonwrite的意思就是写时复制创建子进程的时候不复制这样创建进程就变快了说白了玩的就是指针。 父子进程的数据是隔离的。父进程调用了一个fock(),创建了一个子进程写的速度更快而且不会栈出内存父进程如果有10个G并不是把10个G拷贝过来而是一些地址的映射关系等 数据修改之前的样子 数据修改之后的样子 每个小格子代表数据页假设k1数据页是主进程里面的第三个格子 黑色格子表示k1发生cowcopyonwrite后新的内存地址其他格子内存地址不变子进程中的数据页的内存地址依然是旧的内存地址 如果主线程要修改一块数据(例如图中的键值对 C) 那么这块数据就会被复制一份生成该数据的副本。然后bgsave 子进程会把这个副本数据写入 RDB 文件而在这个过程中主线程仍然可以直接修改原来的数据。
细心的同学肯定发现了bgsave 快照过程中如果主线程修改了共享数据发生了写时复制后RDB 快照保存的是原本的内存数据而主线程刚修改的数据是没办法在这一时间写入 RDB 文件的只能交由下一次的 bgsave 快照。
所以 Redis 在使用 bgsave 快照过程中如果主线程修改了内存数据不管是否是共享的内存数据RDB 快照都无法写入主线程刚修改的数据因为此时主线程父进程的内存数据和子进程的内存数据已经分离了子进程写入到 RDB 文件的内存数据只能是原本的内存数据。
如果系统恰好在 RDB 快照文件创建完毕后崩溃了那么 Redis 将会丢失主线程在快照期间修改的数据。
另外写时复制的时候会出现这么个极端的情况。
在 Redis 执行 RDB 持久化期间刚 fork 时主进程和子进程共享同一物理内存但是途中主进程处理了写操作修改了共享内存于是当前被修改的数据的物理内存就会被复制一份。
那么极端情况下如果所有的共享内存都被修改则此时的内存占用是原先的 2 倍。
所以针对写操作多的场景我们要留意下快照过程中内存的变化防止内存被占满了。
2、回到原问题 其实就是更改数据的之前进行copy一份更改数据的数据页出来比如主进程收到了set k 1请求(之前k的值是2)然后这同时又有子进程在rdb持久化那么主进程就会把k这个key的数据页拷贝一份并且主进程中k这个指针指向新拷贝出来的数据页地址上然后进行更改值为1的操作这个主进程k元素地址引用的新拷贝出来的地址而子进程引用的内存数据k还是修改之前的。
3、一段话总结 copyonwritefork()出来的子进程共享主进程的物理空间当主子进程有内存写入操作时read-only内存页发生中断将触发的异常的内存页复制一份(其余的页还是共享主进程的)。
4、额外补充 在 Redis 服务中子进程只会读取共享内存中的数据它并不会执行任何写操作只有主进程会在写入时才会触发这一机制而对于大多数的 Redis 服务或者数据库写请求往往都是远小于读请求的所以使用fork()加上写时拷贝这一机制能够带来非常好的性能也让BGSAVE这一操作的实现变得很简单。
快照的频率 如果频繁地执行全量快照也会带来两方面的开销。
频繁将全量数据写入磁盘会给磁盘带来很大压力多个快照竞争有限的磁盘带宽前后交叉容易造成恶性循环。bgsave 子进程通过 fork 操作从主线程创建出来fork 这个创建过程本身会阻塞主线程之后不会。 fork主线程的内存越大阻塞时间越长 如果频繁 fork 出 bgsave 子进程这就会频繁阻塞主线程了。
增量快照 做了一次全量快照后后续的快照只对修改的数据进行快照记录这样可以避免每次全量快照的开销。
和AOF 相比快照的恢复速度快但快照的频率不好把握
如果频率太低两次快照间一旦宕机就可能有比较多的数据丢失。如果频率太高 又会产生额外开销
在第一次做完全量快照后T1 和 T2 时刻如果再做快照我们只需要将被修改的数据写入 快照文件就行。但是这么做的前提是我们需要记住哪些数据被修改了。 混合日志和快照
Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。 内存快照以一 定的频率执行在两次快照之间使用 AOF 日志记录这期间的所有命令操作。 七、疑问
0、调用fork()也会阻塞啊 我只能说没毛病但是这个阻塞真的可以忽略不计。尤其是相对于阻塞主线程的save。
1、会同时存在多个子进程吗 不会主进程每次收到bgsave命令需要fork()子进程之前都会判断是否存在子进程了若存在也会忽略掉这次bgsave请求。若不存在我会fork()出子进程进行工作。
为什么这么搞
我猜测原因如下: 1.如果支持并行存在多个子进程那么不仅会拉低服务器性能还会造成数据问题比如八点的bgsave在工作九点又来个bgsave命令。这时候九点的先执行完了八点的后执行完了那九点的不白执行了吗这是我所谓的数据问题。再比如都没执行完十点又开一个bgsave越积越多服务器性能被拉低。 2.那为什么不阻塞判断有子进程在工作就等待等他执行完我在上场那一样越积越多文件过大只会造成堆积。
2、如果没有copyonwrite这种技术是什么效果 1.假设是全量复制那么内存空间直接减半浪费资源不说数据量10g全量复制这10g的时间也够长的。这谁顶得住2.如果不全量复制会是怎样相当于我一边复制你一边写数据看着貌似问题不大其实不然。比如现在Redis里有k1的值是1k2的值是 2比如bgsave了这时候rdb写入了k1的值在写k2的值之前时有个客户端请求 set k1 11 set k2 22 那么持久化进去的是k2 22但是k1的值还是1而不是最新的11所以会造成数据问题所以采取了copyonwrite技术来保证触发bgsave请求的时候无论你怎么更改都对我rdb文件的数据持久化不会造成任何影响。 ———————————————— 版权声明本文为CSDN博主「会飞的IT蜗牛」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。 原文链接https://blog.csdn.net/ymb615ymb/article/details/123392106 ———————————————— 版权声明本文为CSDN博主「程序员面试那点事儿」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。 原文链接https://blog.csdn.net/qq_23864697/article/details/110395710
