Redis的所有数据都是保存在内存中,然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”);
也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
由于Redis的数据都存放在内存中,如果没有配置持久化,redis重启后数据就全丢失了,于是需要开启redis的持久化功能,将数据保存到磁 盘上,当redis重启后,可以从磁盘中恢复数据。
RDB持久化(原理是将Reids在内存中的数据库记录定时 dump到磁盘上的RDB持久化)
如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。
由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。
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内存快照。 |
[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
AOF(append only file)持久化(原理是将Reids的操作日志以追加的方式写入文件,来记录数据)
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。
对于相同数量的数据集而言,AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。
在Redis的配置文件中存在三种同步方式,它们分别是:
相关配置 | 描述 |
---|---|
appendfsync always | 每次有数据修改发生时都会写入AOF文件。 |
appendfsync everysec | 每秒钟同步一次,该策略为AOF的缺省策略。 |
appendfsync no | 从不同步。高效但是数据不会被持久化。 |
[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时。执行重写
二者选择的标准,就是看系统是愿意牺牲一些性能,换取更高的缓存一致性(aof),还是愿意写操作频繁的时候,不启用备份来换取更高的性能,待手动运行save的时候,再做备份(rdb)。rdb这个就更有些 eventually consistent的意思了。
二者一般都是结合使用的,大规模数据备份还原使用RDB快照方式,增量小规模备份还原可以使用AOF快速实现
[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
数据库都会存在内存碎片问题,当进行删除数据时,数据对应的索引位是不会被清除的,一旦该索引被清除,其后的数据索引依次前移,会导致数据错位。因此适当的碎片率是合理的
redis实例的内存使用率超过可用最大内存,操作系统将开始进行内存与swap空间交换,因此想要保障性能,尽量避免内存交换
应用场景
1.以3个节点组成的集群为例(如下图)
◆ 节点A包含0到5500号哈希槽
◆ 节点B包含5501到11000号哈希槽
◆ 节点C包含11001到16384号哈希槽
2.支持添加或者删除节点
添加删除节点无需停止服务例如:
◆ 如果想新添加个节点D,需要移动节点A,B,C中的部分槽到D上
◆ 如果想移除节点A,需要将A中的槽移到B和C节点上,再将没有任何槽的A节点从集群中移除
[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和节点文件
[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
创建群集,六个实例分成三组,每组一主一从,–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.
[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
此时主从数据时不同步的,还需要做主从复制,因此在从服务器上无法查看主服务器写入的值