在现今的数据驱动世界中，数据持久化成为了一项至关重要的任务。它不仅需要保证数据的安全，还要提供快速读写的功能。
对于许多现代化应用程序和服务来说，Redis被广泛使用作为一个高性能的键值存储系统。Redis以其卓越的性能和灵活性赢得了开发者们的青睐。然而，这些优点都离不开它强大的持久化机制。
通过本文，我们将深入探讨Redis的持久化策略，包括RDB（Redis>
一、Redis持久化介绍
你也许会问，为什么需要持久化呢？因为Redis作为一款内存数据库，在进程异常退出或 服务器 断电之后，所有的数据都将消失。如果没有持久化功能，无法保证数据的持久性，那么这样的数据库还有什么用呢？
Redis持久化分为两种：「RDB（Redis>二、RDB原理
RDB是Redis默认的持久化方式，它将Redis在内存中的数据定期写入到硬盘中，生成一个快照文件。快照文件是一个二进制文件，包含了Redis在某个时间点的所有数据。
RDB的优点是快速、简单，适用于大规模数据备份和恢复。但是，RDB也有缺点，例如数据可能会丢失，因为Redis只会在指定的时间点生成快照文件。如果在快照文件生成之后，但在下一次快照文件生成之前服务器宕机，那么这期间的数据就会丢失。
由于RDB文件是以二进制格式保存的，因此它非常紧凑，并且在Redis重启时可以迅速地加载数据。相比于AOF，RDB文件一般会更小。
RDB持久化有两种方式：手动和自动。
手动方式通过SAVE命令或BGSAVE命令进行：
自动方式则是在配置文件中设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。
比如说，以下设置会让 Redis 在满足 “10秒内有至少100 个键被改动” 这一条件时， 自动保存一次数据集。
1.Fork函数与写时复制
在 Redis 中，Fork 函数被用于创建子进程。Redis 的使用场景中通常有大量的读操作和较少的写操作，而 Fork 函数可以利用 Linux 操作系统的写时复制（Copy On Write，即 COW）机制，让父子进程共享内存，从而减少内存占用，并且避免了没有必要的数据复制。
我们可以使用 Linux下的man fork命令来查看下Fork函数的说明文档。
翻译如下：
在Linux下，fork()是使用写时复制的页实现的，所以它唯一的代价是复制父进程的页表以及为子进程创建独特的任务结构所需的时间和内存。
简单来说就是fork()函数会复制父进程的地址空间到子进程中，复制的是指针，而不是数据，所以速度很快。
在 Redis 中，当执行 RDB 持久化操作时，Redis 会调用 fork 函数创建子进程，然后由子进程负责将数据写入到磁盘中。为了避免父子进程同时对内存中的数据进行修改导致数据不一致。Redis 会启用写时复制机制。
这样，当父进程修改内存中的数据时， Linux 内核会将该部分内存复制一份给子进程使用，从而保证父子进程间的数据互相独立。
示意图如下：
当没有发生写的时候，子进程和父进程指向地址是一样的，发生写的时候，就会拷贝出一块新的内存区域，实现父子进程隔离。
通过使用 fork 函数和写时复制机制，Redis 可以高效地执行 RDB 持久化操作，并且不会对 Redis 运行过程中的性能造成太大的影响。同时，这种方式也提供了一种简单有效的机制来保护 Redis 数据的一致性和可靠性。
不过，需要注意的是：
fork的这个过程主进程是阻塞的，fork完之后不阻塞。RDB 需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级内不能响应客户端的请求，数据集很大的时候，fork过程可能会持续数秒。
可能会因为数据量大而导致主进程长时间被挂起，造成Redis服务不可用。因此，在设计时应尽可能减少数据量或者优化fork的调用频率。
2.关于写时复制的思考
上述写时复制流程貌似有个问题：
比如，有个键值对k1 a。此时Redis正在bgsave。这时客户端发来一个请求，主进程发生写操作set k1 b，由于写时复制，此时子进程里k1的值还是a。最终持久化的也是a。
为什么不直接持久化新值而持久化旧值？写时复制的意义是什么？
基于上面的问题，可以给出的解释主要有两点：
3.RDB相关配置
以下是一些RDB的相关参数配置：
三、AOF原理
AOF持久化是按照Redis的写命令顺序将写命令追加到磁盘文件的末尾。AOF是一种基于日志的持久化方式，它保存了Redis服务器所有写入操作的日志记录，以保证数据的持久性、可靠性和完整性。
AOF持久化技术的核心思想是将Redis服务器执行的所有写命令追加到一个文件中。当Redis服务器重新启动时，可以通过重新执行AOF文件来恢复服务器的状态。
AOF有个比较好的优势是可以恢复误操作。
举个例子，如果你不小心执行了FLUSHALL命令，导致数据被误删了 ，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的FLUSHALL命令，并重启 Redis ，就可以将数据集恢复到FLUSHALL执行之前的状态。
1.AOF持久化配置
Redis的AOF持久化配置频率可通过appendfsync参数进行控制。该参数有以下三个选项：
默认情况下，Redis的appendfsync参数设置为everysec。如果需要提高持久化安全性，可以将其改为always，如果更关注性能，则可以将其改为no。但是需要注意的是，使用no可能会导致数据丢失的风险，建议在应用场景允许的情况下谨慎使用。
2.AOF文件解读
一个简单的AOF文件示例如下：
其中：
实际上AOF文件中保存的所有命令都遵循相同的格式，即以*开头表示参数个数，$开头表示参数长度，其后紧跟着参数的值。
3.AOF文件修复
服务器可能在程序正在对 AOF 文件进行写入时停机，造成AOF 文件损坏。
发生这种情况时，可以使用 Redis 自带的redis-check-aof程序，对 AOF 文件进行修复，命令如下：
$ redis-check-aof –fix4.AOF重写
Redis的AOF重写机制指的是将AOF文件中的冗余命令删除，以减小AOF文件的大小并提高读写性能的过程。
Redis的AOF重写机制采用了类似于复制的方式，首先将内存中的数据快照保存到一个临时文件中，然后遍历这个临时文件，只保留最终状态的命令，生成新的AOF文件。
具体来说，Redis执行AOF重写可以分为以下几个步骤：
通过AOF重写机制，Redis可以在不停止服务的情况下减小AOF文件的大小，提高读写性能，同时也可以保证数据的一致性。
Redis提供了手动触发AOF重写的命令BGREWRITEAOF。可以在Redis的客户端中执行该命令来启动AOF重写过程。Redis 2.2 需要自己手动执行BGREWRITEAOF命令，到了 Redis 2.4 则可以自动触发 AOF 重写。
具体操作步骤如下：
(1)打开redis-cli命令行工具，连接到Redis服务。
(2)执行BGREWRITEAOF命令，启动AOF重写过程。
$ redis-cli127.0.0.1:6379> BGREWRITEAOF(3) Redis会返回一个后台任务的ID，表示AOF重写任务已经开始。
127.0.0.1:6379> BGREWRITEAOFBackground append only file rewriting started by pid 1234(4)可以使用INFO PERSISTENCE命令查看当前AOF文件的大小和重写过程的状态，等待重写完成即可。
127.0.0.1:6379> INFO PERSISTENCE# Persistenceaof_enabled:1aof_rewrite_in_progress:1aof_rewrite_scheduled:0aof_last_rewrite_time_sec:0aof_current_rewrite_time_sec:14aof_last_bgrewrite_status:okaof_last_write_status:ok需要注意的是，执行BGREWRITEAOF命令可能会占用较多的CPU和内存资源，因此在生产环境中需要谨慎使用，并确保有足够的系统资源支持。
同时，即使手动触发AOF重写，Redis也会在满足一定条件时自动触发AOF重写，以保证AOF文件的大小和性能。
需要注意的是：
在版本号大于等于 2.4 的 Redis 中，BGSAVE 执行的过程中，不可以执行 BGREWRITEAOF 。反过来说，在 BGREWRITEAOF 执行的过程中，也不可以执行 BGSAVE。目的是防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。
5.AOF缓冲区与AOF重写缓存区
在Redis中，尽管「AOF缓冲区」和「AOF重写缓冲区」的名称相似，但它们实际上是两个不同的概念。
AOF缓冲区是一个用于暂存需要写入AOF文件的命令的缓冲区。在Redis处理客户端发来的写命令时，如果开启了AOF持久化功能，则该命令将被先写入到AOF缓冲区。AOF缓冲区中的内容通过配置的规则持久化到磁盘上。持久化规则可以通过配置项appendfsync来调整。
AOF重写缓冲区是一个用于执行AOF文件的重写操作的缓冲区。AOF重写操作是一种将现有AOF文件重写成最小化的新AOF文件的操作。AOF重写操作的目的是减少AOF文件的大小，同时加快恢复速度。AOF重写缓存区在AOF重写时开始启用，Redis服务器主进程在执行完写命令之后，会同时将这个写命令追加到AOF缓冲区和AOF重写缓冲区。
示意图如下：
6.AOF缓冲区可以替代AOF重写缓冲区吗
AOF缓冲区不可以替代AOF重写缓冲区。
原因是AOF重写缓冲区记录的是从重写开始后的所有需要重写的命令，而AOF缓冲区可能只记录了部分的命令（如果写回的话，AOF缓存区的数据就会失效被丢失，因而只会保存一部分的命令，而AOF重写缓存区不会）。
AOF缓冲区主要是Redis用来解决主进程执行命令速度与磁盘写入速度不同步所设置的，通过AOF缓冲区可以有效地避免频繁对硬盘进行读写，进而提升性能。Redis在AOF持久化的时候，会先把命令写入到AOF缓冲区，然后通过写回策略来写入硬盘AOF文件。
7.AOF相关配置
在 Redis 的配置文件 redis.conf 中，可以通过以下配置项来设置 AOF 相关参数：
(1)appendonly：该配置项用于开启或关闭 AOF，默认为关闭。若开启了 AOF，Redis 会在每次执行写命令时，将命令追加到 AOF 文件末尾。
(2)appendfilename：用于设置 AOF 文件名，默认为 appendonly.aof。
(3)appendfsync：该配置项用于设置 AOF 的同步机制。有三种可选值：
(4)auto-aof-rewrite-percentage和auto-aof-rewrite-min-size：这两个配置项用于设置 AOF 重写规则。当 AOF 文件大小超过auto-aof-rewrite-min-size设置的值，并且 AOF 文件增长率达到auto-aof-rewrite-percentage所定义的百分比时，Redis 会启动 AOF 重写操作。
auto-aof-rewrite-percentage默认值为100，以及`auto-aof-rewrite-min-size默认值为64mb，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
(5)aof-use-rdb-preamble：Redis 4版本新特性，混合持久化。AOF重写期间是否开启增量式同步，该配置项在AOF重写期间是否使用RDB文件内容。默认是no，如果设置为yes，在AOF文件头加入一个RDB文件的内容，可以尽可能的减小AOF文件大小，同时也方便恢复数据。
8.写后日志
我们比较熟悉的是数据库的写前日志（Write Ahead Log，WAL），也就是说，在实际写数据前，先把修改的数据记到日志文件中，以便故障时进行恢复。
不过，AOF 日志却正好相反，它是写后日志，“写后”的意思是 Redis 是先执行命令，把数据写入内存，然后才记录日志。
为什么要这样设计？
其实为了避免额外的检查开销，Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。
而写后日志这种方式，就是先让系统执行命令，只有命令能执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错。所以，Redis 使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。
除此之外，AOF 写后日志还有一个好处：它是在命令执行后才记录日志，所以并不会阻塞当前的写操作。
不过，写后日志也有两个潜在的风险：
四、混合持久化
在过去， Redis 用户通常会因为 RDB 持久化和 AOF 持久化之间不同的优缺点而陷入两难的选择当中：
为了让用户能够同时拥有上述两种持久化的优点， Redis 4.0 推出了一个“鱼和熊掌兼得”的持久化方案 ——RDB-AOF 混合持久化。
这种持久化能够通过 AOF 重写操作创建出一个同时包含 RDB 数据和 AOF 数据的 AOF 文件， 其中 RDB 数据位于 AOF 文件的开头， 它们储存了服务器开始执行重写操作时的数据库状态。至于那些在重写操作执行之后执行的 Redis 命令， 则会继续以 AOF 格式追加到 AOF 文件的末尾， 也即是 RDB 数据之后。
也就是说当开启混合持久化之后，AOF文件中的内容：前半部分是二进制的RDB内容，后面跟着AOF增加的数据，AOF位于两次RDB之间。
格式会类似下面这样：
（二进制）RDB AOF（二进制）RDB在目前版本中， RDB-AOF 混合持久化功能默认是处于关闭状态的， 为了启用该功能， 用户不仅需要开启 AOF 持久化功能， 还需要将aof-use-rdb-preamble选项的值设置为 true。
appendonly yesaof-use-rdb-preamble yes五、如何选择合适的持久化方式
当你想选择适合你的应用程序的持久化方式时，你需要考虑以下两个因素：
(1)数据的实时性和一致性：如果对数据的实时性和一致性有很高的要求，则AOF可能是更好的选择。
如果对数据的实时性和一致性要求不太高，并且希望能快速地加载数据并减少磁盘空间的使用，那么RDB可能更适合你的应用程序。因为RDB文件是二进制格式的，结构非常紧凑，所以在Redis重启时可以迅速地加载数据。
(2)Redis的性能需求：如果对Redis的性能有很高的要求，那么关闭持久化功能也是一个选择。因为持久化功能可能会影响Redis的性能，但是一般不建议这么做。
本篇文章到这就结束了，最后我们来做个小总结：
我们要意识到Redis的持久化机制扮演着至关重要的角色。RDB和AOF两种主要的持久化方式各有其优势和使用场景。
RDB通过提供特定时间点的数据快照，对于灾难恢复是非常有效的；而AOF则通过记录每个写入操作，提供了更好的数据持久性保证。然而，它们也有各自的局限性，这就需要根据实际需求来权衡选用哪种持久化方式。
最后，不可忽视的是，在选择合适的持久化策略时，我们还应考虑如何平衡内存使用、磁盘使用、性能与持久性等多个因素。只有对Redis持久化的深入理解，我们才能充分利用其强大的功能，以满足各种业务需求。
希望这篇文章能够给你带来收获和思考，谢谢。
大数据可视化和大数据开发哪个好
大数据开发的学习内容中包含可视化，掌握了大数据的开发技术，也可以从事可视化的相关工作。 基础阶段：Linux、Docker、KVM、MySQL基础、Oracle基础、MongoDB、redis。 hadoop mapreduce hdfs yarn：hadoop：Hadoop 概念、版本、历史，HDFS工作原理，YARN介绍及组件介绍。 大数据存储阶段：hbase、hive、sqoop。 大数据架构设计阶段：Flume分布式、Zookeeper、Kafka。 大数据实时计算阶段：Mahout、Spark、storm。 大数据数据采集阶段：Python、Scala。 大数据商业实战阶段：实操企业大数据处理业务场景，分析需求、解决方案实施，综合技术实战应用。 大数据技术人员的就业方向：大数据系统研发类人才、大数据应用开发类人才和大数据分析类人才。 工作岗位：ETL研发、Hadoop开发、可视化（前端展现）工具开发、信息架构开发、数据仓库研究、OLAP开发、数据预测（数据挖掘）分析、企业数据管理、数据安全研究、数据科学研究等。
1.hibernate工作原理及为什么要用
一、工作原理1. 通过Configuration()();读取并解析配置文件2. 由中的
一般redis 要设置过期时间吗
一般是根据需求来进行设置。 redis通过expire命令来设置key的过期时间。 语法(key, expiration)1. 在小于2.1.3的redis版本里，只能对key设置一次expire。 redis2.1.3和之后的版本里，可以多次对key使用expire命令，更新key的expire time。 2. redis术语里面，把设置了expire time的key 叫做：volatile keys。 意思就是不稳定的key。 3. 如果对key使用set或del命令，那么也会移除expire time。 尤其是set命令，这个在编写程序的时候需要注意一下。 4. redis2.1.3之前的老版本里，如果对volatile keys 做相关写入操作(LPUSH,LSET)，和其他一些触发修改value的操作时，redis会删除该key。 也就是说 (key,expiration);(key,field,value);(key) //return nullredis2.1.3之后的版本里面没有这个约束，可以任意修改。 (key,100);(key,expiration);(key)(key)//redis2.2.2 return 101; redis<2.1.3 return 1;5. redis对过期键采用了lazy expiration：在访问key的时候判定key是否过期，如果过期，则进行过期处理。 其次，每秒对volatile keys 进行抽样测试，如果有过期键，那么对所有过期key进行处理。
发表评论