在之前的分享中我们提到在Redis中支持了两种数据持久化的方式，分别是AOF和RDB。下面我们就结合这两种数据持久化的方式来分析在Redis中大Key值会对数据持久化有什么影响。

大Key值对AOF持久化的影响

在分析影响之前，先来了解一下AOF的刷盘策略。AOF的方式提供了三种刷盘策略。

• Always：总是，什么意思呢？就是说在每次执行写入之后，就同步将AOF日志的数据写入到磁盘中进行持久化。
• Everysec：每秒，什么意思呢？就是在每次的写操作执行完成之后，先将命令数据写入到AOF的内核缓冲区里面，然后再每隔一秒中向磁盘中写入一次数据。
• No：不，表示Redis不会控制AOF写入磁盘的时间，而是会将这个操作交给操作系统来进行控制，也就是说每次的写入操作执行完成之后，会先将数据写入到AOF的缓冲区中，然后由操作系统来决定在什么时候将内容回写到硬盘中。

以上的三种策略就是Redis使用AOF持久化提供的三种刷盘方式。而整个的控制机制是通过一个fsync()函数进行控制，如下图所示。

根据上面的描述，可以得出如下的结论。

• Always策略就是当每次写入到AOF文件之后，就会执行fsync函数
• Everysec策略就是在Redis底层创建一个异步的任务来执行fsync函数
• No策略则表示永远都不会执行fsync函数

那么如果在Redis出现了大Key之后，会对三种策略分别产生什么影响呢？

Always策略

在Always策略下，当主线程执行完写操作之后，会将数据写入到AOF日志文件中，然后通过调用fsync函数将缓存中的数据刷盘到硬盘中进行持久化存储，等到刷盘结束之后fsync函数才会对线程有所反馈。

也就是说使用了Always策略，如果写入的是一个比较大的Key值，那么当主线程在执行fsync函数的时候，写入磁盘的时间就会比较长，当数据量太大的时候，fsync函数阻塞的时间也会很久，对于Redis性能来讲是非常耗时的一个操作。

Everysec策略

按照上面的结论，当使用了Everysec策略的时候，会创建一个异步的线程进行刷盘操作，那么由于是异步线程所以fsync对于大Key的阻塞并不会影响主线程的执行，所以不会对Redis性能产生太大影响。

No策略

使用No策略表示并不会调用fsync函数，而是由操作系统来控制，对于大Key来讲，并不会影响Redis主线程，但是由于要使用到操作系统的控制，所以对系统性能可能会有所影响。

大Key值对于RDB的影响

上面笔者介绍了大Key对于AOF操作的影响，其实在AOF中还有另外的一个影响，就是如果大Key太多，就会触发AOF的重写机制。而AOF的重写了RDB快照操作，都会触发一个fork的函数调用，如下所示。

在这个调用过程中，操作系统会将主线程的页表信息复制一份到子线程中，这样一来，主线程和子线程就会共享物理内存数据，通过这种方式减少了访问拷贝，提升了性能。

但是随之带来的问题就是如果Key太大的话，就会导致页表越来越大。

然后再通过fork创建一个子线程的时候，对于页表的复制就成了最消耗时间的操作了。这个时候如果数据处理太多的话，就会导致fork阻塞。

而我们知道fork函数是由主线程进行调用，如果fork发生了阻塞，那么就意味着Redis主线程也会发生阻塞，会影响Redis的性能。在使用过程中如果Redis Fock操作时间太长的话就需要进行优化。例如对于单个实例内存占用的控制，对于AOF重写机制的控制，以及在一些主从架构中对于页面缓存的控制等操作都可以避免fork函数发生阻塞的情况。

如何避免出现大Key？

第一、在系统设计之初，对于缓存设计的时候就要考虑到使用缓存的场景，并且将key进行拆分，尽量以小Key代替大Key来进行缓存。

第二、定期的检查缓存中是否由于逻辑判断不足而产生了大Key，如果存在的Key可以被删除，那么就对其进行及时的清理，如果不能，则要对对应的业务逻辑进行优化。

第三、优化Redis配置，以及集群的配置，避免出现主线程阻塞的情况发生。

其实最主要的就是在系统设计之初，根据具体的业务场景对Key进行拆分，避免系统中出现大Key导致出现一些意想不到的问题出现。