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策略
  
  

  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)

• 采用日志的形式来记录每个写操作，并追加到文件中。
  

• 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的持久化运维问题

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阻塞
   

   定位方法：

   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） 如果数据量比较大， 采用集群部署模式， 分散节点压力。