（本文首发于“数据库架构师”公号，订阅“数据库架构师”公号，一起学习数据库技术，助力职业发展）
本篇为Redis性能问题诊断系列的第三篇，主要从Redis服务层面上进行讲解，重点对相关机制的工作原理进行剖析，及如何最优的使用来提高处理性能。
一.数据持久化的影响
为了保证 Redis 数据的安全性，我们可能会开启Redis的持久化将数据落盘，避免Redis服务崩溃或者服务器宕机导致的数据丢失。
Redis当前支持两种典型的持久化模式：RDB、AOF。
- RDB持久化，称为内存快照。这种模式是把当前Redis服务的内存数据在某一点dump生成快照保存到磁盘上的过程，由于是某一时刻的快照，开启快照后发起后所有操作命令都不会再被记录。
- AOF 持久化。AOF持久化以日志的形式记录Redis所执行的每个写操作，注意查询操作不会记录，可以打开磁盘文件看到每条详细的操作记录。
关于Redis持久化这里不做过多详细介绍，大家需要记住开启持久化后会对Redis的访问性能带来影响就行，后面会专文讲解两种持久化模式的细节。本文主要对持久化影响Redis访问响应进行分析说明。
1.RDB镜像落盘及AOF重写时的影响
Redis开始执行RDB或者AOF Rewrite后，主进程都会创建出一个子进程进行数据的持久化落盘操作。在这个过程中，则会调用操作系统的 fork 操作。
通过 fork 对内存数据的 copy-On-Write 机制最廉价的实现内存镜像。虽然内存是 copy on write 的，但是虚拟内存表是在 fork 的瞬间就需要分配，所以这个操作会造成主线程短时间的卡顿（停止所有读写操作），这个卡顿时间和当前 Redis 的内存使用量有关。
根据经验 GB 量级的 Redis 进行 fork 操作的时间在毫秒级。
如果这个Redis实例很大，CPU负载再高些，那么 fork 的耗时就会更长，甚至达到秒级，也就会严重影响 Redis 的访问响应时间。这时反映到业务层面表现就是仿佛Redis服务有一瞬间卡主了，所有的请求不再快速返回，大量的超时出现，然后一会突然又好了。
# latest_fork_usec 相关监控指标上一次fork操作耗时，单位微秒
redis> info stats
# Stats
total_connections_received:434441735
total_commands_processed:127367251467
instantaneous_ops_per_sec:6048
total_net_input_bytes:6089035011002
total_net_output_bytes:37379100018132
instantaneous_input_kbps:274.54
instantaneous_output_kbps:1738.93
rejected_connections:0
sync_full:43
sync_partial_ok:0
sync_partial_err:0
expired_keys:162619318
evicted_keys:0
keyspace_hits:122311115418
keyspace_misses:1269177349
pubsub_channels:1
pubsub_patterns:0
latest_fork_usec:254154可以添加一个监控，如果发现这个耗时过长且频繁出现，就需要警惕了。
为了避免这种情况，可以采取以下优化方式：
- 关闭RDB和AOF的自动触发机器，避免业务高峰自动触发执行；
- 控制 Redis 使用内存大小，建议控制在20G 以下，因为执行 fork 的耗时与数据内存大小有关，数据越多，耗时会越久；
- 对于主从集群架构，建议关闭主库AOF，从库开启；对于有备份需求的集群，也可以在从库发起RDB备份操作；
- 合理配置 repl-backlog-size大小，降低主从全量重传【2.8版本之前的节点强烈建议升级】；
- 尽量不要使用虚拟机，fork 的耗时也与系统也有关，虚拟机比物理机耗时更长。
2.AOF持久化磁盘IO带来的影响
前文主要介绍了两种持久化过程中Fork操作对性能的影响，现在主要说下AOF持久化开启后对性能的影响。关于AOF持久化刷盘的三种策略【no/everysec/always】，这里不过多讲解，大家可以自行查阅资料。
当 Redis 开启 AOF持久化 后，两个主要动作：
- Redis 接收写命令后，把命令写入 AOF 文件缓冲区中（AOF write）
- 根据AOF 刷盘策略【everysec/always】，把 AOF 缓冲数据刷到磁盘上（AOF fsync）
AOF 持久化最耗时的刷盘操作，都是在后台线程执行的，但为什么也会影响到 Redis 主线程处理请求呢？这里需要分析下AOF执行文件持久化刷新时的流程：
?
具体处理流程：
- 数据写入请求来后，主线程写入AOF缓冲区；
- AOF fsync后台线程每秒一次执行磁盘文件刷入操作,并记录最近一次同步时间；
- 主线程对比AOF同步时间
- 如果距离上次fsync同步时间在两秒内,主线程继续进行写入
- 如果距离上次fsync同步时间超过两秒(比如磁盘的 IO 负载很高导致同步写磁盘很慢，还在持续写入没有结束),主线程将会被阻塞, 直到同步完成。
如果fsync过慢，这时系统日志中会有如下提示信息：
Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.Redis自身也提供了相关的性能指标:aof_delayed_fsync
redis>info Persistence
# Persistence
loading:0
rdb_changes_since_last_save:4368195
rdb_bgsave_in_progress:0
rdb_last_save_time:1662581898
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:76
rdb_current_bgsave_time_sec:-1
aof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:56
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_current_size:64666745475
aof_base_size:7570210201
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:2如果aof_delayed_fsync一直在增加，说明主线程频繁出现被阻塞情况，那么就需要关注是否持久化过慢造成Redis访问变慢了。
针对AOF持久化对Redis性能可能带来的影响可以参考如下几种解决方案：
- SSD 磁盘存储，确保AOF刷盘时有充足的IO能力
- 对于主从集群架构，建议关闭主库AOF，从库开启
- 将no-appendfsync-on-rewrite参数设置为yes, 确保aof文件rewrite期间不做fsync操作，减少IO争用
- 单台服务器不要部署过多持久化实例节点，避免磁盘IO争抢带来持久化压力
二、内存碎片过大及整理带来的性能损耗
Redis 的所有数据都在内存中，当应用频繁修改时，就会导致产生内存碎片。过高的内存碎片率，不仅会浪费内存资源还会影响请求处理的效率。
那么，是什么原因导致Redis 产生碎片的呢？原理是什么，能避免吗？
当前Redis 都默认使用jemalloc内存分配器来分配内存，它一般是按固定大小来分配内存空间，而不会按照应用程序申请的内存大小给实际分配。当程序申请的内存大小最接近某个固定值时，如8 byte、16 byte，…,2KB、4KB 等，jemalloc 会给它分配相应大小的空间。这样的方式好处是为了减少分配次数。
假设Redis申请一个 10 byte的内存空间存储数据，jemalloc 会分配 16 byte，此时，如果应用还要再写入 4 byte的数据，Redis 就不用再向操作系统申请空间了，因为刚才分配的 16 byte已经够用了，也就避免了一次额外分配操作开销。
所以Redis每次分配的内存空间一般都会比申请的实际需求空间大一些，这种分配方式就自然会导致形成碎片。
从目前Redis内存的分配机制来看，目前碎片无法完全避免。
Redis 的内存利用率的高低除了成本外，也会直接影响到 Redis 运行效率的高低。可以使用如下命令查看Redis内存使用、碎片率、分配器版本等详细信息：
redis> info Memory
used_memory:6617819416
used_memory_human:6.16G
used_memory_rss:9788588032
used_memory_rss_human:9.12G
...
rss_overhead_ratio:1.00
rss_overhead_bytes:-21159936
mem_fragmentation_ratio:1.48
mem_fragmentation_bytes: 3250855264
...
mem_allocator:jemalloc-5.1.0
...mem_fragmentation_ratio 就是Redis 当前的内存碎片率大小，碎片率计算方法：
mem_fragmentation_ratio=used_memory_rss/used_memoryused_memory 表示存储的数据实际占用内存的大小，而used_memory_rss 指操作系统分配给 Redis进程服务的实际大小，也就是使用top命令查看Redis进程占用的内存。一般当?mem_fragmentation_ratio>1.5 时，就说明内存碎片率已经超过了50%，此时建议采取措施来降低内存碎片大小。
如何清理内存碎片呢？根据版本的不同有两种方式：
- Redis 4.0 以前的低版本，只能通过重启实例来解决，不能自动配置回收
- 从 4.0版本以后，提供了一种内存碎片自动回收的方法，可以通过配置动态开启碎片整理
但要注意：开启内存碎片整理，会导致 Redis 服务性能下降。
Redis 的碎片整理工作是在主线程中执行的，当其进行碎片整理时，操作系统会把多份数据拷贝到新位置以把原有空间释放出来，这会带来时间开销，而这个过程就会阻塞Redis处理请求。
为了降低碎片整理带来的性能影响，Redis 为自动内存碎片整理功机制提供了多个参数，具体有：
activedefrag yes #是否开启碎片整理
active-defrag-ignore-bytes 500mb #碎片大小超过 500MB 时才会触发整理
active-defrag-threshold-lower 20 #碎片大小占操作系统分配总空间比超过 20% 时触发整理
active-defrag-cycle-min 15 #碎片整理过程占用的CPU比例不低于 15%，保证整理可以正常执行
active-defrag-cycle-max 70 #碎片整理过程占用的CPU比例不高于70%，一旦超过就暂停整理，避免大量的内存拷贝等整理过程占用过多的CPU进而影响正常请求
active-defrag-max-scan-fields 500 #碎片整理过程中，对于 Hash、List、Set、ZSet 等成员集合类型一次扫描的元素数量在开启碎片自动整理时，一定要优先评估当前 Redis 服务的负载状态，以及应用程序可接受的响应延迟，合理设置碎片整理的参数值和回收时间段【比如放到凌晨程序定时触发】，来尽可能降低碎片整理期间对Redis服务的影响。
如果这篇文章对你有收获，还请帮忙点赞、转发?一下，您的支持会激励我们输出更多高质量的文章，非常感谢！如果你还想看更多优质文章，欢迎关注公号「数据库架构师」，技术交流，一起学习和成长
推荐阅读?