关于Redis(操作备份\主从\哨兵模式的理解)

一、Redis的5种数据类型

redis的数据都是以key/value值存储的,五大数据类型主要是指的value值。

(1)、STRING

类似于java中的String,是最基本的数据类型,可以包含任何数据,比如一个序列化对象或者一个jpg图片,字符串大小上限是512M。

数据结构:

set k1 v1

(2)、LIST

 类似于java中的LIST<String>,是一个简单的字符串列表,按照插入顺序排序,
 可以从LIST头部(LEFT)或者尾部(RIGHT)插入一个元素或者移除一个元素。

数据结构:

LPUSH k1   v1 v2 v3

(3)、HASH

类似于java中的Map,我感觉就是个小redis,也是键值对

数据结构:

HSET k1 h1 v1

(4)、SET

类似于java中的set集合,元素不能重复,无序。

数据结构:

SADD k1 v1 v2 v3 v4

(5)、ZSET

和SET类型一样,只不过每个元素多关联了一个double类型的分数。

数据结构:

ZADD k1 60 v1

二、Redis的发布订阅

这个就和rabbitmq的生产者消费者一回事,无非就是一个频道发消息,一个频道收消息。

(1)、发布消息的方式:

PUBLISH c1 "hello redis"

(2)、订阅的方式:

PSUBSCRIBE c1 c2 c3

也可以使用模糊匹配的方式订阅:

PSUBSCRIBE c*

三、Redis的事务管理

(1)、使用MULTI命令开启一个事务,然后输入以系统的指令,然后再输入EXEC执行这一系列的指令,这些指令就会在一个事务里面。

(2)、事务的异常情况分为两类:

<1>、进入队列前就报错,比如命令输错;这种情况下,所以命令都不会执行

<2>、在EXEC执行后才报错,这种情况下,会忽略掉报错的一行命令,其它命令还是会执行,并不会回滚。

(3)、Watch 命令

Redis Watch 命令用于监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，
那么事务将被打断

四、Redis的持久化管理

1、快照持久化(RDB)

我理解为,就是隔一段时间,把整个redis数据库做和备份,其实就是定时备份。快照的默认开启的。

主要配置:

<1>、设置备份频率

第一个参数代表规定时间,第二个参数代表在规定时间多少个键被修改就进行备份。
save 900 1     
save 300 10
save 60 10000

<2>、stop-writes-on-bgsave-error yes

快照创建出错后,是否继续执行写命令。

<3>、rdbcompression yes

是否对快照进行压缩

<4>、dbfilename dump.rdb

表示生成的快照的名字

<5>、dir ./

生成快照的位置

快照持久化的运行原理:

<1>、save命令:

redis在运行的过程中,发送save命令创建一个快照.save是阻塞命令,
也就是redis在接收到save命令之后,在备份完成之前,不会执行其它的命令。

<2>、bgsave命令:

bgsave会fork一个子进程,主进程继续执行其它命令,子进程负责备份快照,这条就解决了阻塞的问题。

<3>、快照的时机:

1、我们在redis.cinf文件中配置了rdb快照频率,
	save 900 1     
	save 300 10
	save 60 10000

当条件满足后,就会自动触发,bgsave命令

2、当执行shutdown命令关闭redis的时候,会自动触发save命令

3、主从备份的时候,当从机连接上主机,会发送一条sync命令来开始一次复制操作,
此时主机会自动触发bgsave命令。bgsave操作结束后,向从机发送快照数据实现数据同步。

快照持久化的缺点:

save命令会发送阻塞,bgsave命令虽然不会发送阻塞,但是fork一个子进程也会耗费资源,
定时的持久化也会存在数据丢失的风险,最坏的情况就是丢失最近一次备份的数据。
快照频率设置太高了,耗费资源,设置太低了,丢失数据的风险越大。

2、AOF持久化

我理解为其实就是把每次操作写入到aof文件。等到要恢复的时候,把aof文件里面的命令从头到尾执行一遍，
这样就不需要像rdb快照的方式一样,进行实时备份数据了。

<1>、aof的开启和配置:

<2>、关键点:

appendfsync的取值有三种,一般会选择everysec(每秒写一次),最坏的情况,可能会丢失1秒的数据。

<3>、AOF文件的重新和压缩

AOF备份有确定,那就是AOF文件会越来越大,占硬盘空间。
重写和压缩机制可以缓解这个问题,
当AOF文件过大的时候,像redis发送一条bgrewriteaof命令进行文件重写,自动执行这条命令就需要配置:

auto-aof-rewite-min-size  64mb
auto-aof-rewite-percentage 100

当前文件大小超过上一次重写时aof文件大小的百分之100的时候,进行重写,如果没有重写过,
就以启动时的aof文件大小为依据,提示要求aof文件大于64M

3、最佳实践:

1、如果redis只是做缓存服务器,那么可以不用持久化

2、提示开启两个持久化方式,会优先用AOF的方式恢复原始数据。
   RDB适合用于备用数据库(AOF不断变化,不会备份)来快速重启。建议只在slave上持久化rdb文件,15分钟备份一次就够了。

3、用AOF的方式,可以保证数据完整性,最多丢失不到2秒的数据。
   可以尽量减少aof文件rewrite的频率,只要硬盘许可,重新基础大小默认值可以设置到5g以上。

五、主从复制

数据备份还有第三种解决方案,就是做主从复制。
主从复制可以扩展redis性能.一方面实现读写分离,一方面实现数据备份。

(1)、配置方式:

比如说有三个redis实例:

192.168.248.128:6379
192.168.248.128:6380
192.168.248.128:6381

修改redis6379.conf文件,6380,6381的配置文件也做相应的配置

然后启动3个实例:

然后设置主从关系:

6379是主机,6380和81是从机,那么就在这2个从机上配置

或者在配置文件里面写:

配置好了之后,在主机6379上存储一条数据,从机也可以get到这条数据。

(2)、注意点:

如果主机运行了一段时间,这个时候连接从机,从机会将主机所有的数据进行备份.

配置主从复制后,主机可读可写,从机只读。

主机挂掉后重新上线,仍然是主机。

(3)、主从复制原理:

就是从机连接主机的后,从机会执行一个sync命令,主机接收到命令之后,
将整个数据全部同步到从机(全量复制),然后主机继续接收新的修改命令,并且依次传给从机(增量复制)。

(4)、一主多仆和接力模式:

上面配置的主从模式是一主多仆的方式:

接力模式是这种:

搭建成接力模式实际上,只需要修改6381的master即可,然6381从前一个节点6380上复制数据

六、哨兵模式

如果仅仅只用主从复制,那么就会出现一个问题,当主机宕机后,就没有主机了。这个时候必须手动重启主机,
才能重新实现备份数据,写入数据等功能。
能不能主机宕机后,自动从从机里面选出一个当主机呢,这就需要用到哨兵模式了。

(1)、哨兵模式配置:

假设主机是6379,从机6380和6381,先配置好一主二仆的主从复制模式,然后在reids目录下打开sentinel.conf文件,

mymaster是随意取的监控主机的名字,监控的是6379服务,最后面的1表示有多少个哨兵认为6379宕机了,就切换为主机。

(2)、注意问题:

所有的读写操作都是在master上操作,然后再同步到slave上,所以master同步到slave机器上有一定的延迟,当系统繁忙或者slave机增加时,延迟问题会更加严重,所以我的下一片博客会说到redis cluster集群,可以进一步提升redis性能。