• redis的持久化存储


    一. redis的高可用

      在Redis中,实现高可用的技术主要包括持久化、复制、哨兵和集群

      1. 持久化:持久化是最简单的高可用方法(有时甚至不被归为高可用的手段),主要作用是数据备份,即将数据存储在硬盘,保证数据不会因进程退出而丢失。

      2. 复制:复制是高可用Redis的基础,哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单的故障恢复。缺陷:故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机的限制。

      3. 哨兵:在复制的基础上,哨兵实现了自动化的故障恢复。缺陷:写操作无法负载均衡;存储能力受到单机的限制。

      4. 集群:通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。

    二. redis的两种持久化存储方式

      持久化的功能:Redis是内存数据库,数据都是存储在内存中,为了避免进程退出导致数据的永久丢失,需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘;当下次Redis重启时,利用持久化文件实现数据恢复。

      RDB持久化: 是将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化); 保存的文件后缀是rdb;当Redis重新启动时,可以读取快照文件恢复数据。

      AOF持久化: AOF持久化(即Append Only File持久化),是将Redis执行的每次写命令记录到单独的日志文件中(有点像MySQL的binlog);当Redis重启时再次执行AOF文件中的命令来恢复数据。

    三. RDB持久化存储

      1. 手动执行指令触发, 进行存储

        save      这个指令会阻塞redis, 执行完之前不再接收其他处理

        bgsave     这个指令会创建一个子进程去处理持久化存储, 线上使用

      2. 配置conf文件触发自动存储

    daemonize yes                    #后台运行
    bind 127.0.0.1                   #redis绑定地址
    port 6379                        #端口
    requirepass redhat                #redis登录密码
    logfile /data/6379/redis.log    #日志文件
    dir /data/6379                  #定义持久化文件存储位置
    
    dbfilename  dbmp.rdb            #rdb持久化文件
    save 900 1                    
    save 300 10                        
    save 60  10000                   


    save m n 当m秒后, 达到n个存储, 就执行bgsave指令, 进行持久化存储

    其他可选配置

    stop-writes-on-bgsave-error yes  # 当bgsave出现错误时,Redis是否停止执行写命令;设置为yes,则当硬盘出现问题时,可以及时发现,避免数据的大量丢失;设置为no,则Redis无视bgsave的错误继续执行写命令,当对Redis服务器的系统(尤其是硬盘)使用了监控时,该选项考虑设置为no

    rdbcompression yes  # 是否开启RDB文件压缩

    rdbchecksum yes    # 是否开启RDB文件的校验,在写入文件和读取文件时都起作用;关闭checksum在写入文件和启动文件时大约能带来10%的性能提升,但是数据损坏时无法发现

    四. AOF持久化存储

      1. 触发配置

        Redis服务默认开启RDB, 关闭AOF; 开启AOF只在配置文件中加入 appendonly yes

        启动Redis服务时会优先加载AOF

      2. AOF的常见配置

    appendonly no        # 是否开启AOF
    
    appendfilename "appendonly.aof"    # AOF文件名
    
    dir /data/6379                  # 定义持久化文件存储位置
    
    appendfsync everysec    # 持久化策略,每秒都存, always总是
    
    no-appendfsync-on-rewrite no     # AOF重写期间是否禁止fsync;如果开启该选项,可以减轻文件重写时CPU和硬盘的负载(尤其是硬盘),但是可能会丢失AOF重写期间的数据;需要在负载和安全性之间进行平衡
    
    auto-aof-rewrite-percentage 100    # 执行AOF重写时,当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。
    
    auto-aof-rewrite-min-size 64mb     # 执行AOF重写时,文件的最小体积,默认值为64MB。
    
    aof-load-truncated yes    # 如果AOF文件结尾损坏,Redis启动时是否仍载入AOF文件

    五. RDB和AOF持久化存储的优缺点

    RDB持久化

      优点:RDB文件紧凑,体积小,网络传输快,适合全量复制;恢复速度比AOF快很多。当然,与AOF相比,RDB最重要的优点之一是对性能的影响相对较小。

      缺点:RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化,而在数据越来越重要的今天,数据的大量丢失很多时候是无法接受的,因此AOF持久化成为主流。此外,RDB文件需要满足特定格式,兼容性差(如老版本的Redis不兼容新版本的RDB文件)。

    AOF持久化

      优点:AOF的优点在于支持秒级持久化、兼容性好,

      缺点:文件大、恢复速度慢、对性能影响大。

    六. RDB切换到AOF

      1. 临时生效

        config set appendonly yes    开启AOF

        config set save ""        关闭RDB

      2. 永久生效

        修改配置文件

        appendonly yes   

        appendsync everysec

  • 相关阅读:
    Ubuntu 虚拟机安装几点细节整理
    jQuery与IE兼容性问题处理
    Excel已损坏,无法打开
    应对刷新闪烁问题
    ArcGIS鼠标滚轮方向之代码篇
    ChartControl控件0和null的效果
    多个组件联合打印输出——PrintableComponentLink
    Skyline中加载WMTS地图
    访问天地图WMTS服务的正确姿势
    超图不支持JPEG格式的WMTS服务
  • 原文地址:https://www.cnblogs.com/q767498226/p/11109301.html
Copyright © 2020-2023  润新知