深入！！Redis持久化、性能管理及群集部署

一、Redis持久化概述

1、前言

• Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。
• 有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。
• Redis可以被看成是一个数据结构服务器。

2.Redis持久化的两种方式（RDB/AOF）

Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；
也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。

由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁 盘上，当redis重启后，可以从磁盘中恢复数据。

3.RDB持久化

RDB持久化原理

RDB持久化（原理是将Reids在内存中的数据库记录定时 dump到磁盘上的RDB持久化）

1. Redis的默认持久化方式默认，文件名dump.rdb
2. 触发条件
   ●在指定的时间间隔内，执行指定次数的写操作（配置文件控制)
   ●执行save或者是bgsave(异步）命令
   ●执行flushall命令，清空数据库所有数据
   ●执行shutdown命令，保证服务器正常关闭且不丢失任何数据
   RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
   

RDB存在的优势

1. 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2. 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3. 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4. 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB的缺点

1. 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2. 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
   

RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，可以看到下面的配置信息：

相关配置	描述
save 900 1	在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10	在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000	在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

通过RDB文件恢复

• 将dump.rdb文件拷贝到redis的安装目录的bin目录下，重启redis服务即可

RDB模式配置示例（定时同步）

注意：在修改redis配置文件时，配置语句前不能留有空格，否则配置不生效

[root@localhost ~]# vim /etc/redis/6379.conf 
 219行// save 900 1          ## 在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
 220行// save 300 10         ## 在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
 221行// save 60 10000       ## 在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
 254行// dbfilename dump.rdb     ## 快照数据存放文件，临时文件
 264行// dir /var/lib/redis/6379     ## 快照文件存放目录
 242行// rdbcompression yes          ## 是否执行压缩
[root@localhost ~]# cd /var/lib/redis/6379/     ##到/var/lib/redis/6379/ 目录下
[root@localhost 6379]# ls    ##可以看到快照文件
dump.rdb

4.AOF持久化

AOF持久化原理

AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件，来记录数据）

• Redis默认不开启
• 弥补RDB的不足(数据的不一致性)
• 采用日志的形式来记录每个写操作，并追加到文件中Redis重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

AOF的优势

1. 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了三种同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其 效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变 化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2. 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操 作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据 一致性的问题。
3. 如果日志过大，Redis可以自动启用rewrite（重写）机制。即Redis以append模式不断的将修改数据写入到旧的磁盘文件中并进行压缩存放，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行（新的文件是以日志形式存在，占用缓存空间）。因此在进行rewrite切换时可以更好的保证数据安全性。当要读取旧数据时，会再次将旧的文件拉取到缓存中供读取。
4. AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势

1. 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2. 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

相关配置	描述
appendfsync always	每次有数据修改发生时都会写入AOF文件。
appendfsync everysec	每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no	从不同步。高效但是数据不会被持久化。

通过AOF文件恢复

• 将appendonly.aof文件拷贝到Redis的安装目录的bin目录下，重启Redis服务即可

AOF的重写机制

• AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多
• ·当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩

AOF重写的原理

• Redis会fork出一条新进程，读取内存中的数据（并没有读取旧文件)，并重新写到一个临时文件中，最后替换旧的aof文件

AOF持久化模式相关配置示例

注意：在修改redis配置文件时，配置语句前不能留有空格，否则配置不生效

[root@localhost ~]# vim /etc/redis/6379.conf 
 700行// appendonly yes     ##默认情况下是no，开启需要改成yes
 704行// appendfilename "appendonly.aof"      ## AOF记录文件
 
###################### 下面三条是AOF的三种模式，开启其中一条就要注释另外两条####################
 729行// appendfsync always      ##每次有数据修改发生时都会写入AOF文件。
 730行// # appendfsync everysec  ##每秒钟同步一次，该策略为AOF的缺省策略。
 731行// # appendfsync no     ## 不进行同步
#---------------------------------------------------------------------
 796行// aof-load-truncated yes   ##忽略最后一条可能出现错误的指令；在aof写入时，可能存在指令写错的问题(突然断电，写了一半)，这种情况下，会log记录并继续，而no会直接恢复失败. 默认值yes。

########################### AOF重写功能配置，去除冗余，优化AOF#################################
 752行// no-appendfsync-on-rewrite yes    ##当AOF文件过多冗余时，（默认当达到上一次重写日志的两倍大小时），执行的一个去重操作
 771行// auto-aof-rewrite-percentage 100    ##AOF文件达到上次重写文件两倍（多出100%即两倍的意思）时，执行重写。
 772行// auto-aof-rewrite-min-size 64mb     ## AOF文件大小超过64M时。执行重写

5.RDB和AOF的选择

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

二者一般都是结合使用的，大规模数据备份还原使用RDB快照方式，增量小规模备份还原可以使用AOF快速实现

三、Redis性能管理

1.查看内存使用率（info memory）

[root@localhost ~]# redis-cli -h 192.168.10.11 -p 6379
192.168.10.11:6379> info memory
# Memory
used_memory:2628328        ## 内存使用总量
used_memory_human:2.51M
used_memory_rss:11042816
used_memory_rss_human:10.53M
used_memory_peak:2669216
used_memory_peak_human:2.55M
used_memory_peak_perc:98.47%
used_memory_overhead:2587282
used_memory_startup:1455056
used_memory_dataset:41046
used_memory_dataset_perc:3.50%
……省略部分
rss_overhead_bytes:684032
mem_fragmentation_ratio:4.27      ##内存碎片率
mem_fragmentation_bytes:8455504
mem_not_counted_for_evict:0

2.内存碎片率解释

• 操系统分配的内存值used_memory_rss除以Redis使用的内存值used_memory计算得出
• 内存碎片是由操作系统低效的分配/回收物理内存导致的
  ◆ 不连续的物理内存分配
• 跟踪内存碎片率对理解Redis实例的资源性能是非常重要的
  ◆ 内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低
  ◆ 内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率
  ◆ 内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统i正在进行内存交换，会占用内存空间
  ◆ 综上所述，内存碎片率在1左右最为合理，过高或过低都不合适。

数据库都会存在内存碎片问题，当进行删除数据时，数据对应的索引位是不会被清除的，一旦该索引被清除，其后的数据索引依次前移，会导致数据错位。因此适当的碎片率是合理的

3.避免内存交换

redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换,因此想要保障性能，尽量避免内存交换

• 针对缓存数据大小选择
• 尽可能的使用Hash数据结构
• 设置key的过期时间

4.回收key

• 保证合理分配redis有限的内存资源
• 当达到设置的最大阀值时，需选择一种key的回收策略
  ◆ 默认情况下回收策略是禁止删除
  ◆redis.conf配置文件中修改maxmemory-policy属性值
  (1) volatile-Iru:使用LRU算法从已设置过期时间的数据集合中淘汰数据
  (2) volatile-ttl:从已设置过期时间的数据集合中挑选即将过期的数据淘汰,推荐使用这种
  (3) volatile-random:从已设置过期时间的数据集合中随机挑选数据淘汰
  (4) allkeys-Iru:使用LRU算法从所有数据集合中淘汰数据
  (5) allkeys-random:从数据集合中任意选择数据淘汰
  (6) no-enviction:禁止淘汰数据

四、Redis群集部署

应用场景

• 单节点Redis服务器带来的问题单点故障，服务不可用
• 无法处理大量的并发数据请求
• 数据丢失—大灾难
  解决方法
• 搭建Redis集群

Redis集群介绍

• Redis集群是一个提供在多个Redis间节点间共享数据的程序集
• Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误
• Redis集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下可继续处理命令

Redis集群的优势

• 自动分割数据到不同的节点上
• 整个集群的部分节点失败或者不可达的情况下能够继续处理命令

Redis集群的实现方法

• 客户端分片
• 代理分片
• 服务器端分片

Redis-Cluster数据分片

• Redis 集群没有使用一致性hash,而是引入了哈希槽概念
• Redis集群有16384个哈希槽
• 每个key通过CRC16校验后对16384取模来决定放置槽
• 集群的每个节点负责一部分哈希槽

Redis-Cluster数据分片(续)

1.以3个节点组成的集群为例（如下图）
◆ 节点A包含0到5500号哈希槽
◆ 节点B包含5501到11000号哈希槽
◆ 节点C包含11001到16384号哈希槽

2.支持添加或者删除节点
添加删除节点无需停止服务例如：
◆ 如果想新添加个节点D,需要移动节点A,B,C中的部分槽到D上
◆ 如果想移除节点A，需要将A中的槽移到B和C节点上，再将没有任何槽的A节点从集群中移除

Redis-Cluster的主从复制模型

• 集群中具有A，B，C三个节点,如果节点B失败了，整个集群就会因缺少5501-11000这个范围的槽而不可用
• 为每个节点添加一个从节点A1，B1，C1,整个集群便有三个master节点和三个slave节点组成，在节点B失败后，集群便会选举B1为新的主节点继续服务
• 当B和B1都失败后，集群将不可用

Redis群集搭建实例（暂未搭建主从配置）

实验设计

详细步骤

1.修改配置文件

[root@localhost ~]# vim /etc/redis/6379.conf
70行/ #bind 127.0.0.1   ##注释掉bind项后，redis中bind 选项默认监听所有网卡
89行/ protected-mode no      //关闭保护模式，yes要改为no
93行/  port 6379
137行/ daemonize yes    //以独立进程启动
833行/ cluster-enabled yes   //开启群集功能
841行/ cluster-config-file nodes-6379.conf    //群集名称文件设置
847行/ cluster-node-timeout 15000    //群集超时时间设置
700行/ appendonly yes    //开启aof持久化
[root@localhost ~]# /etc/init.d/redis_6379 restart   ##重启redis
#正常启动后，/var/1ib/redis/6379/目录下会多出两个文件，
一个是持久化appendonly.aof文件，另外一个是节点首次启动生成的 nodes-6379.conf配置文件。
[root@localhost ~]# cd /var/lib/redis/6379/
[root@localhost 6379]# ls
appendonly.aof  dump.rdb  nodes-6379.conf     产生AOF和节点文件

2.安装ruby群集管理工具，管理redis群集

[root@localhost ~]# wget https://github.com/rvm/rvm/archive/master.tar.gz  ##直接下载master的源码包
[root@localhost ~]# tar zxvf master.tar.gz -C /opt
[root@localhost ~]# cd /opt/rvm-master/
[root@localhost ~]# ./install
[root@localhost ~]# source /etc/profile.d/rvm.sh   //执行环境变量
[root@localhost ~]# rvm list known   //列出 Ruby 可安装的版本
[root@localhost ~]# rvm install 2.4.1   //安装 Ruby2.4.1版本
[root@localhost ~]# rvm use 2.4.1    //使用Ruby2.4.1版本
[root@localhost ~]# ruby -v     //查看当前 Ruby版本
[root@localhost ~]# gem install redis    //再次安装redis

3.创建群集。

创建群集，六个实例分成三组，每组一主一从，–replicas 1 表示每组一个从，在下面交互的时候输入yes才能创建
使用的是源码解压目录中的redis-trib.rb工具创建群集

[root@localhost network-scripts]# redis-cli --cluster create \
192.168.10.10:6379 \
192.168.10.11:6379 \
192.168.10.12:6379 \
192.168.10.20:6379 \
192.168.10.21:6379 \
192.168.10.22:6379 \
--cluster-replicas 1          ##创建群集
>>> Performing hash slots allocation on 6 nodes...    ##提示一共6个节点，并在下面说明了主节点和从节点
Master[0] -> Slots 0 - 5460     ##自动划分槽位，每组所对应的槽位号也显示出来了
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.10.21:6379 to 192.168.10.10:6379
Adding replica 192.168.10.22:6379 to 192.168.10.11:6379
Adding replica 192.168.10.20:6379 to 192.168.10.12:6379
M: 8978261432729009bb06f203f5c46fea20abce37 192.168.10.10:6379
   slots:[0-5460] (5461 slots) master           ### 三台master
M: 8978261432729009bb06f203f5c46fea20abce37 192.168.10.11:6379
   slots:[5461-10922] (5462 slots) master
M: 8978261432729009bb06f203f5c46fea20abce37 192.168.10.12:6379
   slots:[10923-16383] (5461 slots) master
S: c852a5d902aeb23fcaeb0ef432b8b61a5a743bed 192.168.10.20:6379
   replicates 8978261432729009bb06f203f5c46fea20abce37          ##三台复制
S: c852a5d902aeb23fcaeb0ef432b8b61a5a743bed 192.168.10.21:6379
   replicates 8978261432729009bb06f203f5c46fea20abce37
S: c852a5d902aeb23fcaeb0ef432b8b61a5a743bed 192.168.10.22:6379
   replicates 8978261432729009bb06f203f5c46fea20abce37
Can I set the above configuration? (type 'yes' to accept): yes   ##这里输入yes
……省略部分
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

4.群集验证（在其中一台master中写入数据，其他的master都可以查看）

[root@localhost ~]# redis-cli -h 192.168.10.10 -p 6379   ##登入192.168.10.10节点服务器
192.168.10.10:6379> keys *
(empty list or set)
192.168.10.10:6379> set number 10     ##创建一个number键
OK
192.168.10.10:6379> keys *
1) "number"
192.168.10.10:6379> 
------------------------------------------------------------------------------------------------------
[root@localhost ~]# redis-cli -h 192.168.10.11 -p 6379   ##登入192.168.10.11节点服务器
192.168.10.11:6379> keys *
1) "number"
192.168.10.11:6379> get number   ## master服务器之间构成的群集无异常，数据分片共享
10
-----------------------------------------------------------------------------------------------------------
[root@localhost ~]# redis-cli -h 192.168.10.21 -p 6379    ##登入192.168.10.21从服务器
192.168.10.21:6379> keys *   ##可以查看到在主服务器创建的键
1) "number"
192.168.10.20:6379> get number    ##查看键值
(error) MOVED 5798 192.168.10.10:6379    ##提示在10.10那台服务器上，暂时未搭建主从复制，因此数据为完全同步
192.168.10.20:6379> 
--------------------------------------------------------------------------------------------------------
在未主从同步的前提下，从服务器想要查看数据，需要跳转到master上查看，因此redis-cli登入时需要加-c （声明群集），才能查看
[root@localhost ~]# redis-cli -c -h 192.168.10.21 -p 6379    ##登入群集中192.168.10.21从服务器
192.168.10.20:6379> get number    ##查看数据
-> Redirected to slot [5798] located at 192.168.10.10        ##提示重定向到192.168.10.10，查看值
10

此时主从数据时不同步的，还需要做主从复制，因此在从服务器上无法查看主服务器写入的值