zoukankan      html  css  js  c++  java
  • 4.redis-持久化

    1.持久化的作用
    2.什么是持久化:redis所有数据保持在内存中,对数据的更新将异步地保存到磁盘上
    3.持久化的实现方式
    方式一:快照
    实现方式一:mysql dump
    实现方式二:redis RDB
    方式二:写日志
    实现方式一:mysql binlog
    实现方式二:hbase hlog
    实现方式三:redis AOF
    4.RDB
    (1)什么是RDB

    (2)触发机制-主要三种方式
    第一种:save(同步)

     


    文件策略--->如存在老的RDB文件,新替换老
    复杂度--->O(N)
    IO类型同步,阻塞,复杂度O(n),优点不会消耗额外内存,缺点,阻塞客户端命令
    命令:

    127.0.0.1:6379> save
    OK

    第二种:bgsave(异步)

    文件策略--->如存在老的RDB文件,新替换老
    复杂度--->O(N)
    IO类型异步,阻塞发生在fork(子进程),复杂度O(n),优点不阻塞客户端命令,缺点,需要fork(子进程),消耗内存
    命令:

    127.0.0.1:6379> bgsave
    Background saving started

    第三种:自动生成RDB
    (3)配置:

    #如果在9000秒中改变了1条数据自动生成RDB
    save 900 1
    #如果在300秒中改变了10条数据自动生成RDB
    save 300 10
    #如果在60秒中改变了10000条数据自动生成RDB
    save 60 10000
    #rdb文件名字
    dbfilename dump.rdb
    #rdb文件的路径(默认当前目录)
    dir ./
    #是否停止写入默认是yes
    stop-writes-on-bgsave-error yes
    #是否采用压缩格式
    rdbcompression yes
    #是否对rdb文件检验
    rdbchecksum yes

    (4)触发机制-不容忽略方式
    1)全量复制
    2)debug reload:不将内存清空的重启,触发rdb文件生成
    3)shutdown:
    (5)RDB总结
    1)RDB是Redis内存到硬盘的快照,用于持久化
    2)save通常会阻塞Redis
    3)bgsave不会阻塞Redis,但是会fork新进程
    4)save自动配置满足任一就会被执行
    5)有些触发机制不容忽视
    5.AOF
    (1)RDB现存问题
    耗时,耗性能
    不可控,丢失数据
    (2)什么是AOF
    客户端每执行一条写命令,redis就在AOF文件里追加一条写命令,当redis宕机后,从AOF文件中把命令从新写入到redis
    (3)AOF三种策略
    策略一:always
    redis写命令刷新到缓冲区,缓冲区根据always策略每条命令刷新到AOF文件
    优点:不会丢失数据
    缺点:IO开销较大,一般的sata盘只有几百TPS
    策略二:everysec
    redis写命令刷新到缓冲区,缓冲区根据everysec策略每一秒都刷新到AOF文件
    优点:每秒一次fsync丢1秒数据
    缺点:丢1秒数据
    策略三:no
    redis写命令刷新到缓冲区,缓冲区根据操作系统来决定什么时候刷到AOF文件
    优点:不用管
    缺点:不可控
    (4)AOF重写:把过期的,没有用,重复,以及可以优化的命令化简,减少磁盘占用量,加速恢复速度
    AOF重写的两种方式
    方式一:bgrewriteaof
    命令:bgrewriteaof
    Background append only file rewriting started
    方式二:AOF重写配置
    (5)配置:

    #打开AOF功能默认为no
    appendonly yes
    #AOF文件名
    appendfilename "AOF文件名"
    #AOF目录
    dir /bigdiskpath
    #AOF重写的时候是否做AOF的append操作
    no-appendfsync-on-rewrite yes
    #AOF文件重写需要的尺寸
    auto-aof-rewrite-min-size
    #AOF文件增长率
    auto-aof-rewrite-percentage
    RDB和AOF的抉择

    (6)统计:

    #AOF当前尺寸(单位:字节)
    aof_current_size
    #AOF上次重启和重写的尺寸(单位:字节)
    aof_base_size

    (7)AOF重写流程图
    1.bgrewriteaof对父进程执行之后
    2.父进程会fork一个子进程
    4.子进程完成AOF重写的过程(将redis内存数据进行一次回溯成写到新的AOF文件中),
    3.1主进程正常进行客户端写命令写到aof_buf当中去写到AOF文件当中
    3.2过程redis会将这段时间的写命令写到aof_rewrite_buf文件
    5.2当新文件生成之后,会将新文件补充道新AOF文件
    5.3用新的AOF文件替换旧的AOF文件

    6.Redis持久化的取舍和选择
    (1)RDB和AOF的抉择

    启动优先级:RDB低     AOF高
    体积      :RDB小    AOF大
    恢复速度  :RDB快     AOF慢
    数据安全性:RDB丢数据  AOF根据策略决定
    轻重     :RDB重     AOF轻

    (2)RDB最佳策略
    集中管理
    主从,从开
    (3)AOF最佳策略
    开缓存和存储
    AOF重写集中管理
    everysec每秒去刷
    (4)最佳策略
    小分片
    缓存或者存储
    监控(硬盘,内存,负载,网络)
    7.开发运维常见问题
    (1)fork操作
    <1>同步操作
    <2>与内存量信息相关:内存越大,耗时越长(与机器类型有关)
    <3>info:latest_fork_usec 查看fork执行时间
    (2)改善fork
    <1>优化使用物理机或高效支持fork操作的虚拟化技术
    <2>控制Redis实例最大可用内存:maxmemory
    <3>合理配置liunx内存分配策略:vm.overcommit_memory=1
    <4>降低fork频率:列如放宽AOF重写自动触发时机,不必要的全量复制
    (3)进程外开销
    <1>CPU:
    开销:RDB和AOF文件生成,属于CPU密集型
    优化:不做CPU绑定,不和CPU密集型部署
    <2>内存:
    开销:fork内存开销,copy-on-write
    优化:echo never > /sys/kernel/mm/transparent_hugepage/enabled
    <3>硬盘
    开销:AOF和RDB文件写入,可以结合iostat,iotop分析
    硬盘优化:
    不要和高硬盘服务部署一起:存储服务,消息队列等
    no-appendfsync-on-rewrite = yes
    根据写入量决定磁盘类型:列如ssd
    单机多实例持久化文件目录可以考虑分盘
    (4)AOF追加阻塞
    主线程负责写入AOF缓冲区,同时它还有一个同步线程进行每秒刷盘动作,同时还记录最近一次同步时间,主线程负责对比上一次同步时间,如果距离上次同步时间大于两秒阻塞,小于两秒通过

    (5)AOF阻塞定位
    <1>redis日志
    <2>单机多实例部署

  • 相关阅读:
    html表单
    html基础
    MySQL数据库 数据的更新
    JAVA数据库编程
    集合框架
    线程和进程
    反射
    centos 7环境
    js中的this
    javascript的作用域以及闭包现象
  • 原文地址:https://www.cnblogs.com/xixi18/p/11137269.html
Copyright © 2011-2022 走看看