Redis持久化方式RDB和AOF以及Redis集群介绍

设置单个
        hset key subkey subvalue :设置一个键值对
获取单个
        hget key subkey:获取一个子键的值
设置多个
        hmset key subkey1 subvalue1 subkey2 subvalue2 ...:设置多个键值对
获取多个
        hmget key subkey1 subkey2...:获取多个子键的值
获取所有属性以属性值
        hgetall key:获取指定key值的所有信息
删除-子键
        hdel key subkey1 subkey2 ...
删除
        del key

3 列表类型(了解) Stirng=list 例如：s3=a,a,b,b,c,d

两端的设置:
lpush key member1 member2.. : 往左边开始插入
   例如：lpush l1 a b c d        d,c,b,a
rpush key member1 member2.. :往右边开始插入
    例如：rpush l1 a b c d        a,b,c,d
lrange key startindex endindex：查看例如：lrange key 0 -1 :全查

两端的删除:
        lpop key :左边弹出一个
        rpop key :右边弹出一个

4 集合类型(了解) String=set 例如：s4=a,c,d,b

        sadd key member1 member2 :设置
        srem key member1 member2 :删除
        smembers key :查看

5 有序集合类型(了解) String=zset 例如： s5=a,b,c,d

        zadd key score1 value1 score2 value2...: 设置添加
        zrem key value1 value2... :删除指定成员
        zcard key :展示元素的长度
        zscore key value :获取成员的数字

redis通用操作

        1 keys *:查询所有的key
        2 exists key:判断是否有指定的key 若有返回1,否则返回0
        3 rename key 新key:重命名
        4 type key:判断一个key的类型
        5 del key :删除

一、单点Redis的问题

1.1 数据丢失问题

Redis是内存存储，服务重启可能会丢失数据。

1.2 并发能力问题

单点Redis并发能力虽然不错，但是也无法满足如6.18，11.11这样的高并发场景。

1.3 故障回复问题

如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段。

1.4 存储能力问题

Redis基于内存，单节点能存储的数据量难以满足海量数据需求。

二、问题解决

2.1 数据丢失问题解决方案

Redis有两种持久化方案：

2.1.1 RDB持久化

RDB（Redis Database Backup file）Redis数据备份文件，也被叫做Redis数据快照。简单的来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，回复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

1. RDB持久化执行时机，在以下四种情况下执行

执行save命令
执行bgsave命令
Redis停机时（shutdown命令关机）

Redis停机时汇之星一次save命令，实现RDB持久化。

触发RDB条件时

Redis内部有触发RDB的机制，可以在redis.conf文件中找到。

格式：
# 900s内，如果至少有1个key被修改，则执行bgsave，如果是save ""，则表示禁用RDB
    save 900 1
# 900s内，如果至少有10000个key被修改，则执行bgsave，如果是save ""，则表示禁用RDB
    save 900 10000
    
弊端：898s有10000个key被修改了，但是此时突然断电了，是无法保存的。

#在redis.conf文件中也可以配置如下配置
    #1.是否压缩，建议不开启，压缩会消耗cpu
        rbdcompression no
    #2.RDB文件名称
        dbfilename dunp.rdb
    #3.文件保存的路径目录
        dir ./

2. 思考 save和bgsave有什么区别

save命令是被主进程执行RDB，在此过程中其他命令都会被阻塞。只有在数据迁移时可能用到。

bgsave命令是被独立进程完成RDB，主进程可以持续处理用户请求，不受影响。

3. RDB原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork之后读取内存数据并写入RDB文件

fork采用的是copy-on-write技术：

当主进程执行读操作时，访问共享内存。
当主进程执行写操作时，则会拷贝一份数据，执行写操作。

3. RDB缺点

RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
fork子进程、压缩、写出RDB文件都比较耗时

2.1.2 AOF持久化

AOF(Append Only File )追加文件。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

1. AOF配置

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

#表示每执行一次写命令，立即记录到AOF文件 1281行
appendonly yes
#AOF文件的名称 1256行
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配置

#表示每执行一次写命令，立即记录到AOF文件 1281行
appendfsync always

#写命令执行完先放入AOF缓冲区，然后表示每隔1S将缓冲区数据写到AOF文件，也是默认的方案
appendfsync everysec

#写命令执行完先放入AOF缓冲区，由操作系统决定如何将缓冲区内容写回磁盘。
appendfsync no

AOF三种记录策略的对比
配置项	刷新时机	优点	缺点
Always	同步刷新	可靠性高，几乎不丢失数据	性能影响大
everysec	每秒刷新	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量的数据

2. AOF文件重写

因为AOF记录的是命令，AOF文件会比RDB文件大得多。而且AOF会记录同一个key的多次写操作，但是只有最后一个操作才有意义。通过执行bgrewrite命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可在redis.conf中配置。

bgrewriteaof

bgrewriteaof

#AOF文件比上次文件增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
#Aof文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb

2.1.3 RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性较高，在实际开发中两者往往结合使用

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低、因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源，但是AOF重写时会占用大量的CPU和内存资源
使用场景	对数据安全性要求低，可以接受数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高

2.2 并发能力问题的解决

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力就需要单间主从集群，实现读写分离。

Redis集群分为三种方式

主从集群
哨兵集群
分片集群

2.2.1 Redis主从集群

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

1. 主从数据同步原理

全量同步：

主从第一次建立连接时，会执行去全量同步，将master节点的所有数据都拷贝给slave节点。

流程如下图所示

完整流程描述：

slave节点请求增量同步
master节点判断replid，发现不一致，拒绝增量同步
master将完整内存数据生成RDB，发送RDB到slave
slave清空本地数据，加载master的RDB
master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
slave执行接收到的命令，保持与master之间的同步

2. 思考：master如何得知salve是第一次来连接的？

首先需要了解几个概念:

Replication Id

简称replid，是数据集的标记，replid一致说明是同一数据集。

每一个master都有唯一的replid，slave则会继承master节点的replid

offset

偏移量，随着记录在repl_baklog中的数据增多而主键增大，

slave完成同步时也会记录当前同步的offset。

如果slave的offset小于master的offset，说明slave的数据落后于master，需要更新。

因此slave做同步数据，必须向master声明自己的replication id和offset，master才可以判断到底需要那些同步数据。

因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接的时候，发送的offset和replid是自己的offset和replid。master如果判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。master会将自己的replid和offset都发送给这个slave，slave保存这些信息，以后slave的replid与master就一致了

因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。

2.1增量同步

全量同步需要先做RDB，然后将RDB文件通过网络传输个slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与master都是做增量同步。

什么是增量同步？就是只更新slave与master存在差异的部分数据。如图：

思考： master怎么知道slave与自己的数据差异在哪里呢?

这就要说到全量同步时的repl_baklog文件了。

这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset：

slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：

直到数组被填满：

此时，如果有新的数据写入，就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset：

如果master继续写入新数据，其offset就会覆盖旧的数据，直到将slave现在的offset也覆盖：

棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。

注意：repl_baklog大小有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，只能再次全量同步。

总结：

简述全量同步和增量同步区别？

全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

slave节点第一次连接master节点时
slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

slave节点断开又恢复，并且在repl_baklog中能找到offset时

2.2.2 Redis哨兵集群

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。

哨兵的作用如下：

监控：Sentinel 会不断检查您的master和slave是否按预期工作
自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

集群监控原理

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

•主观（ subjective ）下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。

•客观（objective）下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

集群故障恢复原理

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
最后是判断slave节点的运行id（run_id）大小，越小优先级越高。

当选出一个新的master后，该如何实现切换呢？

流程如下：

sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
sentinel给所有其它slave发送slaveof 192.168.85.143 7003 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

小结

Sentinel的三个作用是什么？

监控
故障转移
通知

Sentinel如何判断一个redis实例是否健康？

每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线
如果大多数sentinel都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

首先选定一个slave作为新的master，执行slaveof no one
然后让所有节点都执行slaveof 新master
修改故障节点配置，添加slaveof 新master

2.2.3 Redis分片集群

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

海量数据存储问题
高并发写的问题

使用分片集群可以解决上述问题，如图:

分片集群特征：

集群中有多个master，每个master保存不同数据
每个master都可以有多个slave节点
master之间通过ping监测彼此健康状态
客户端请求可以访问集群任意节点，最终都会被转发到正确节点

三、雪崩、击穿以及穿透问题

雪崩：Redis中的数据同时失效向Redis中存放数据的时候，都要设置失效时间，两个小时，刚好过期，大量的请求过来，直接访问到数据库中

解决方案：失效的时间做成随机数据

击穿：高频访问同一条数据，这条数据Redis没有，MySQL有

解决方案：在Redis中设置Null

穿透：大量数据Redis没有，MySQL也没有

解决方案：在Redis中设置为Null，布隆过滤器

布隆过滤器（BloomFilter）：

Bloom filter是由Howard Bloom在1970年提出的二进制向量数据结构，它具有空间和时间效率，被用来检测一个元素是不是集合中的一个成员。如果检测结果为是，该元素不一定在集合中；但如果检测结果为否，该元素一定不在集合中。因此Bloom filter具有100%的召回率。这样每个检测请求返回有“在集合内（可能错误）”和“不在集合内（绝对不在集合内）”两种情况，可见 Bloom filter 是牺牲了正确率和时间以节省空间。

计算方法

如需要判断一个元素是不是在一个集合中，我们通常做法是把所有元素保存下来，然后通过比较知道它是不是在集合内，链表、树都是基于这种思路，当集合内元素个数的变大，我们需要的空间和时间都线性变大，检索速度也越来越慢。 Bloom filter 采用的是哈希函数的方法，将一个元素映射到一个 m 长度的阵列上的一个点，当这个点是 1 时，那么这个元素在集合内，反之则不在集合内。这个方法的缺点就是当检测的元素很多的时候可能有冲突，解决方法就是使用 k 个哈希函数对应 k 个点，如果所有点都是 1 的话，那么元素在集合内，如果有 0 的话，元素则不在集合内。