Java高性能开发实战(1)——Redis 7 持久化机制

Ne0inhk

— 9 min read
Java高性能开发实战(1)——Redis 7 持久化机制
Redis版本：7.0.15

1.概述

Redis是一个基于内存的数据库，这意味着其主要数据存储和操作均在内存中进行。这种设计使得Redis能够提供极快的读写速度(通常达到微秒级别)，适用于高性能场景，如缓存
  • 然而，由于内存的易失性(断电后数据会丢失)，Redis提供了持久化机制：将内存中的数据保存到磁盘中，确保数据在Redis服务重启或崩溃后能够恢复。通过持久化，可以避免数据丢失，提高数据的可靠性
  • Redis提供两种持久化方式
    • RDB(Redis Database)：生成数据集的快照实现持久化
    • AOF(Append Only File)：记录所有写操作命令，以追加方式写入文件

2.RDB

RDB指的是Redis的一种持久化机制，其核心是生成Redis数据在某个时间点的快照

2.1 快照原理

由于Redis是单线程应用程序，在线上环境时，不仅要处理来自客户端的请求，还要执行内存快照操作(进行文件IO)。单线程同时处理客户端请求和文件IO时会严重降低服务器性能，甚至阻塞客户端请求。因此，Redis使用 fork 和 写实拷贝(Copy On Write) 机制来实现快照持久化

在这里插入图片描述
fork

        Redis在进行RDB持久化时会调用fork函数来创建一个子进程负责完成，父进程则继续处理客户端请求。子进程在创建之初和父进程共享同一数据段

        Linux操作系统的内存空间被分为很多种片段，每个片段又被分为很多个页面，每个页面4KB

在这里插入图片描述
写实拷贝

        当父进程对数据段中的某一数据页面进行修改操作时，Linux操作系统会将该数据页面复制一份分离出来，然后对该页面进行修改，最后父进程指向指向修改后的页面。随着被修改的页面越来越多，内存空间不断膨胀，最多达到原来的两倍

在这里插入图片描述


        从子进程被创建出来的那一刻起，直至拷贝结束，子进程始终指向原始的数据段且所有原数据段不会被修改。所以，在整个拷贝过程中 RDB快照 = 子进程看到的所有数据页面的瞬间状态集合

        拷贝完成后，子进程会被销毁，同时没有指针指向的数据页面也会被销毁

在这里插入图片描述

2.2 触发机制

Redis RDB的触发机制分为自动触发和手动触发两种方式

  • 自动触发
  • 手动触发
    • save命令：同步阻塞式触发，执行期间Redis服务器不处理任何请求，直到RDB文件创建完成(不推荐)
    • bgsave命令：异步非阻塞式触发，Redis会fork一个子进程执行持久化操作，主进程继续处理请求

正常关闭Redis

# 默认执行save(阻塞式)>shutdown# 或>shutdown save # 触发流程：1. 停止接受新连接 2. 执行save(不是bgsave)3. 保存完成后退出

在redis.conf中通过save指令配置阈值。当在指定时间内发生足够数量的键修改时自动触发bgsave

在这里插入图片描述

2.3 文件处理

        RDB文件保存在dir配置指定的目录下(默认/var/lib/redis)，文件名通过dbfilename配置指定(默认dump.sql)

在这里插入图片描述


        在RDB备份过程中，fork出的子进程会将内存数据写入临时文件，临时文件默认命名规则为temp-< pid >.rdb，其中< pid >是子进程的进程ID。当子进程完成RDB文件写入后，Redis会用原子性的rename操作将临时文件重命名为正式RDB文件并删除原文件

在这里插入图片描述

2.4 优缺点

优点

  • 恢复速度快：RDB是数据的二进制快照，恢复时直接加载到内存
  • 备份时对服务影响小：使用bgsave命令时，Redis通过fork子进程在后台保存数据，主进程可以继续处理客户端请求，几乎无阻塞
  • 存储高效：RDB 文件使用二进制格式并支持LZF压缩

缺点

  • 非实时一致性：RDB保存的是某个瞬间的快照，如果保存过程中有大量写入，快照可能不反映完全一致的业务状态
  • 可能丢失更多数据：如果Redis意外宕机，从上一次RDB保存到宕机之间的所有数据修改都会丢失

3.AOF

AOF持久化通过将Redis服务器接收到的每个写命令追加到文件末尾来实现

在这里插入图片描述
# 开启AOF appendonly yes

3.1 工作流程

在这里插入图片描述
  • 命令追加：当Redis执行写命令时，该命令会以Redis协议格式追加到内存中的AOF缓冲区(aof_buf)。缓冲区会根据配置策略决定何时将内容同步到磁盘
    • always：每次写命令后同步，数据安全性最高但性能影响较大
    • everysec：每秒同步一次，平衡性能与安全性(默认配置)
    • no：由操作系统决定同步时机，性能最好但可能丢失较多数据

文件写入与同步：AOF缓冲区内容会被写入到AOF文件，具体同步到磁盘的时机由appendfsync参数控制：

在这里插入图片描述

3.2 重写机制

作用：解决AOF文件不断增长导致的存储空间占用和恢复效率问题。通过重写，可以生成一个更紧凑的AOF文件，仅包含重建当前数据集所需的最小命令集合(例如，对同一个键多次修改会记录多条命令，而重写机制会合并这些操作，仅保留最终状态的命令)

        父进程通过fork创建一个子进程来完成AOF文件的重写，确保主进程继续处理客户端请求。子进程会读取当前数据库的快照数据，并将其转换为一系列Redis命令写入新的临时AOF文件

在这里插入图片描述


        在重写过程中，主进程会将新接收到的写命令同时写入现有的AOF 缓冲区aof_buf(保证原有 AOF 文件正常更新)和AOF重写缓冲区aof_rewrite_buf(保证新命令不会丢失)

        当子进程完成重写后，会通知主进程。主进程会将 AOF 重写缓冲区中的命令追加到新生成的临时 AOF 文件中，最后原子性地替换旧文件

        在Redis7.0.15版本，AOF文件保存在dir + appenddirname配置指定的目录下(默认/var/lib/redis/appendonlydir)。文件前缀名通过appendfilename配置指定(默认appendonly)

在这里插入图片描述
  • appendonly.aof.1.base.rdb：作为Redis AOF(Append-Only File)持久化机制的基准文件，存储某一时刻数据库的完整快照。格式为RDB，体积较小且加载速度快，用于重建数据的基础状态
  • appendonly.aof.1.incr.aof和appendonly.aof.2.incr.aof：记录基准文件生成后的增量写操作命令，以文本形式追加存储。多个增量文件按操作顺序编号(如.1.incr.aof、.2.incr.aof)，Redis 重启时会按顺序重放这些命令以恢复最新数据
  • appendonly.aof.manifest：描述AOF文件的组成和顺序的清单文件

4.混合持久化

        Redis 混合持久化结合了 RDB(快照)和 AOF(日志)两种持久化方式的优势，在保证数据安全性的同时兼顾性能

# 开启混合持久化 aof-use-rdb-preamble yes
  • 基础RDB文件优先加载：appendonly.aof.1.base.rdb作为全量快照数据文件，会优先被加载。该文件包含某一时间点的完整数据快照，恢复时作为基准数据集
  • 增量AOF文件后续应用：appendonly.aof.1.incr.aof作为增量操作日志，在基础RDB加载完成后被重放。该文件记录自 RDB 快照生成后的所有写操作，用于恢复最新数据状态

Read more

sdl3-sample-简明教程，指导如何在包括移动和 Web 在内的各种平台上构建和使用 SDL3

sdl3-sample-简明教程，指导如何在包括移动和 Web 在内的各种平台上构建和使用 SDL3 sdl3-sample源代码地址为：https://github.com/Ravbug/sdl3-sample sdl3-example是SDL3的简明教程，指导如何在包括移动和 Web 在内的各种平台上构建和使用 SDL3。还包含 SDL_mixer、SDL_Image 和 SDL_ttf！ 在线网站运行示例为：https://www.ravbug.com/sdl3-sample/ https://www.ravbug.com/sdl3-sample/官网在线运行结果： SDL3 App From Source Minimal Example This is a minimal example for building and

By Ne0inhk
一文彻底搞清楚数据结构之排序算法大揭秘

一文彻底搞清楚数据结构之排序算法大揭秘

🔥承渊政道：个人主页 ❄️个人专栏: 《C语言基础语法知识》《数据结构与算法初阶》 ✨逆境不吐心中苦,顺境不忘来时路!🎬 博主简介: 前言:前面小编已经介绍完了关于遍历二叉树以及讲解了一些二叉树相关OJ算法题的解题思路,自此关于二叉树的内容已经介绍完了!接下来小编将要介绍一个新的内容–>排序算法,它又有什么作用呢?废话不多说,下面跟着小编的节奏🎵一起学习吧！ 目录 * 1.排序的概念 * 1.1常见的排序算法 * 2.插入排序 * 2.1直接插入排序(附动图) * 2.2希尔排序 * 2.3希尔排序的时间复杂度计算 * 3.选择排序 * 3.1直接选择排序(附动图) * 3.2堆排序 * 4.交换排序 * 4.1冒泡排序(附动图) * 4.2快速排序 * 4.2.1hoare版本 * 4.

By Ne0inhk
力扣hot100滑动窗口（C++）

力扣hot100滑动窗口（C++）

一、无重复字符的最长子串 （s由英文字母、数字、符号和空格组成） 1.1题目解析 这道题要求找到一个字符串中不包含重复字符的最长子串的长度。子串必须是连续的字符序列，不是子序列，不能跳着选字符。 1.2初试 我最开始的想法很简单：把每个可能的子串都检查一遍。从字符串的第一个字符开始，看看能往右延伸多远不出现重复字符，记录这个长度，然后从第二个字符开始同样检查，一直试完所有起始位置。 class Solution { public: int lengthOfLongestSubstring(string s) { int n = s.size(); if(n == 0) return 0; int maxlength = 1; for(int i = 0; i < n; i++) { int a[256]

By Ne0inhk
链表的应用举例：从内存管理到缓存淘汰的艺术

链表的应用举例：从内存管理到缓存淘汰的艺术

链表的应用举例：从内存管理到缓存淘汰的艺术 * 引言：链表之美 * 一、链表在操作系统内存管理中的应用 * 1.1 内存碎片问题：美丽的"伤痕" * 1.2 链表：内存碎片的"穿线者" * 二、缓存：速度与容量的优雅平衡 * 2.1 缓存的概念：计算机世界的"速记本" * 2.2 缓存的工作原理：多级存储的和谐共舞 * 2.3 缓存内部的数据结构：从链表到哈希链表 * 三、LRU缓存淘汰算法：时间价值的体现 * 3.1 LRU算法原理：最近最少使用的智慧 * 3.2 LRU实现示例：四步看懂淘汰过程 * 3.

By Ne0inhk