Redis高级运用之持久化配置策略与运维优化

一、 Redis的特性

  1. 性能高

    Redis能读的速度是10W+次/s,写的速度是8W+次/s 。

  2. 丰富的数据类型

    Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。

  3. 操作原子性

    Redis的所有操作都是原子性的,Redis还支持对几个操作全并后的原子性执行。

  4. 功能丰富

    支持 publish/subscribe, lua脚本、事务、pipeline、 通知、 key 过期等等特性。

  5. 支持多种编程语言

    java,python、PHP、C、C++等等。

  6. 持久化

    Redis支持两种方式的持久化,即将数据写入磁盘的方法,RDB(Redis DataBase)和AOF(Append Only File)。

  7. 主从复制

    Redis支持主从复制功能,主节点中断,可以进行主从切换, 不影响客户端的使用。

  8. 高可用与分布式

    Redis从2.8版本后,支持Redis Sentinel,即“哨兵模式”,保障Redis节点的故障发现与自动转移; 还可以支持集群模式(3.0版本),实现分布式存储与水平扩展。

二、 Redis的数据结构

Redis包含5种基本数据结构,4种高级数据结构。

  1. 5种基本数据结构

    • string
    • list
    • hash
    • set
    • sorted set
  2. 4种高级数据结构

    • hyperloglog
    • geo
    • bitmap/bloomfilter
    • stream

三、 Redis的启动与管理工具

  • Redis三种启动方式

    1. 直接启动
    2. 配置文件启动
    3. 动态参数启动
    验证方式:
    1. ps -ef | grep redis
    2. netstat -apn | grep 端口
    3. redis-cli -h ip -p port -a password ping
    
  • Redis的管理工具介绍

    1. redis-server : 启动管理Redis服务。
    2. redis-cli: redis的命令行工具。
    3. redis-benchmark: redis性能基准测试工具。
    4. redis-check-aof: aof数据文件检查修复工具。
    5. redis-check-dump: rdb数据文件检查修复工具。
    6. redis-sentinel: 启动管理redis哨兵服务。
  • Redis 常用配置

    1. port : 端口

    2. dir : 数据文件存放路径

    3. logfile: 日志文件存放路径

    4. daemonize: 守护进程方式启动

四、 Redis的持久化配置策略

Ⅰ. RDB(Redis Database)

  • 覆盖式更新, 新文件替换就的RDB文件

  • 效率: 内容越大, 效率越低, o(n)

  • 操作方式对比:

    命令 save bgsave
    IO类型 同步 异步
    是否阻塞
    复杂度 O(n) O(n)
    优势 不会消耗额外内存 不阻塞客户端命令
    缺陷 阻塞式 需要fork子进程,消耗内存
  • 自动生成RDB策略
    Redis高级运用之持久化配置策略与运维优化_第1张图片
    Redis高级运用之持久化配置策略与运维优化_第2张图片

    save 900 1            900秒内执行一次set操作 则持久化1次  
    save 300 10           300秒内执行10次set操作,则持久化1次
    save 60 10000         60秒内执行10000次set操作,则持久化1次
    

    注意事项:

    1) save 自动配置满足任一项就会执行,数据量大情况下会阻塞Redis。

    2) bgsave不会阻塞Redis, 但是会fork产生新进程。

    3) rdb方式存储, 会有数据丢失的可能。

Ⅱ. AOF (Append Only File)

  • 采用日志的形式来记录每个写操作,并追加到文件中。
    Redis高级运用之持久化配置策略与运维优化_第3张图片

  • aof的三种策略

    1) always

    每条命令都回fsync到磁盘。

    2)everysec(默认)

    每秒把缓冲区fsync到磁盘。

    3)no

    由os操作系统决定fsync到磁盘。

    命令 always everysec no
    优势 不丢失数据 每秒一次fsync 无需配置
    缺陷 io开销过大,一般磁盘只有几百iops 丢失1秒数据 不可控
    appendonly yes   # 开启AOF模式
    appendfilename "appendonly-6379.aof"  # AOF文件名称
    appendfsync everysec # aof策略模式
    dir /data  # 数据文件保存目录
    no-appendfsync-on-rewrite yes  # 在子进程重写的时候,主进程的写操作记录是否追加 (yes为不追加,保存在缓冲区,有可能会造成数据丢失,最多30秒数据; no为追加, 但可能会产生阻塞)
    

Ⅲ. RDB vs AOF

  • 综合对比

    模式 RDB AOF
    启动效率
    体积
    恢复速度
    数据安全性 易丢失数据 安全性高(由策略决定)
    备份模式 全量备份 增量备份
    运行缺陷 可能存在
  • 混合持久化

    混合持久化可以弥补AOF方式的不足,采用混合持久化,重写后的新 AOF 文件前半段是 RDB 格式的全量数据,后半段是 AOF的增量数据,达到更快的重写和恢复效果,混合持久化的开关为aof-use-rdb-preamble。
    Redis高级运用之持久化配置策略与运维优化_第4张图片

五、 Redis的持久化运维问题

  1. fork问题

    fork执行过程中,父进程需要拷贝内存页表给子进程,如果内存占用很大,那么拷贝的内存页表会比较耗时, 整个实例会被阻塞。

    解决:

    1)优先使用物理机或采用高效支持fork操作的虚拟化技术。

    2) 控制Redis的示例最大可用内存: maxmemory。

    3)合理配置Linux内存分配策略: vm.overcommit_memory = 1。

    4)降低fork频率: 例如放宽AOF重写自动触发时机, 不必要的全量复制。

  2. 子进程的开销与优化

    1)CPU开销

    RDB与AOF文件的操作, 属于CPU密集型,会产生较大的开销。

    优化:

    不做CPU核数绑定,不和CPU密集型应用部署。

    2) 内存开销

    fork会产生内存开销,在写入时会产生副本(COPY-ON-WRITE)。

    优化:

    关闭THP(RHEL6的特性, 系统会产生一个khugepaged进程, 把使用较小的页面换到hugepage中,会占用较多的内存)

    echo never > /sys/kernel/mm/transparent_hugepage/enabled

    3) 硬盘开销

    AOF更新和RDB文件的写入都会带来较多的磁盘开销

    优化:

    • 采用企业级SSD提升磁盘吞吐能力, 可以通过iostat,iotop或dstat工具监控磁盘是否产生瓶颈。

    • 如果单机部署多实例, 可以考虑分盘存储。

    4) AOF阻塞
    Redis高级运用之持久化配置策略与运维优化_第5张图片

    定位方法:

    1)通过Redis日志定位:

    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
    

    2)通过终端指令定位:

    >info persistence
    ...
    aof_delayed_fsync:200
    ...
    

    该指令为累积耗时, 出现问题时, 需要记录上一次的耗时做对比。

    优化:

    1) 将appendfsync策略改为everysec每秒进行一次刷新。

    2) 如果数据量比较大, 采用集群部署模式, 分散节点压力。

你可能感兴趣的:(生产级实践,Redis,redis,数据库,运维)