Redis进阶

前言

上篇文章已经讲了redis的经常使用功能，今天来说讲redis如下知识点，若有不当请多指教！

• Redis持久化
• 主从复制
• Sentinel机制
• Redis Cluster

Redis持久化

redis是基于内存的，若是不想办法将数据保存在硬盘上，一旦redis重启(退出/故障)，内存的数据将会所有丢失。

Redis提供了两种持久化方法：

RDB(基于快照)，将某一时刻的全部数据保存到一个RDB文件中。
AOF(append-only-file)，当Redis服务器执行写命令的时候，将执行的写命令保存到AOF文件中。

RDB

保存某个时间点的全量数据快照

• 手动触发

  SAVE：阻塞Redis的服务器进程，知道RDB文件被建立完毕
  BGSAVE：Fork出一个子进程来建立RDB文件，不阻塞服务器进程，使用lastsave指令能够查看最近的备份时间

• 自动触发

  根据redis.conf配置里的save m n定时触发（用的是BGSAVE）
  主从复制时，主节点自动触发
  执行Debug Relaod
  执行Shutdown且没有开启AOF持久化

注意：Redis服务器在启动的时候，若是发现有RDB文件，就会自动载入RDB文件(不须要人工干预)

RDB的优缺点

优势：
RDB是一个紧凑压缩的二进制文件，表明Redis在某个时间点上的数据快照，适合备份，全量复制等场景。
且加载RDB恢复数据远远快于AOF的方式。

缺点：
没办法作到实时持久化/秒级持久化，由于bgsave每次运行都要执行fork操做建立子进程，属于重量级操做，频繁执行成本太高。

RDB的相关配置

//在n秒内修改m条数据时建立RDB文件
save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes  //bgsave出错时中止写入
rdbcompression yes  //压缩RDB文件
rdbchecksum yes   //校验文件是否损坏

AOF

与RDB不同的是，AOF记录的是命令，而不是数据。

如何开启AOF?
只需在配置文件中将appendonly设置为yes便可。

AOF的工做流程：

一、全部的写入命令追加到aof_buf缓冲区中。
二、AOF会根据对应的策略向磁盘作同步操做。刷盘策略由appendfsync参数决定。
三、按期对AOF文件进行重写。重写策略由auto-aof-rewrite-percentage，auto-aof-rewrite-min-size两个参数决定。

appendfsync参数有以下取值：

appendfsync always     # 每次有数据修改发生时都会写入AOF文件。
appendfsync everysec   # 每秒钟同步一次，该策略为AOF的默认策略。
appendfsync no         # 从不一样步。高效可是数据不会被持久化。

AOF重写

为何要重写？
重写后能够加快节点启动时的加载时间

重写后的文件为何能够变小？
进程内超时的数据不用再写入到AOF文件中
多条写命令能够合并为一个

重写条件

一、手动触发
     直接调用bgrewriteaof命令

二、自动触发

先来看看有关参数：
auto-aof-rewrite-min-size：执行AOF重写时，文件的最小体积，默认值为64MB。
auto-aof-rewrite-percentage：执行AOF重写时，当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时知足时，才会自动触发AOF重写。

后台重写

Redis将AOF重写程序放到子进程里执行(BGREWRITEAOF命令)，像BGSAVE命令同样fork出一个子进程来完成重写AOF的操做，从而不会影响到主进程。

AOF后台重写是不会阻塞主进程接收请求的，新的写命令请求可能会致使当前数据库和重写后的AOF文件的数据不一致！
为了解决数据不一致的问题，Redis服务器设置了一个AOF重写缓冲区，当子进程完成重写后会发送信号让父进程将AOF重写缓冲区的数据写到新的AOF文件。

RDB和AOF比较

RDB和AOF并不互斥，它俩能够同时使用。

RDB的优势：载入时恢复数据快、文件体积小。
RDB的缺点：会必定程度上丢失数据(由于系统一旦在定时持久化以前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。)

AOF的优势：丢失数据少(默认配置只丢失1秒的数据)。
AOF的缺点：恢复数据相对较慢，文件体积大

若是Redis服务器同时开启了RDB和AOF持久化，服务器会优先使用AOF文件来还原数据(由于AOF更新频率比RDB更新频率要高，还原的数据更完善)

主从复制

单机有什么问题？

单机即在一台机器上部署一个redis节点，主要会存在如下问题：
一、若是发生机器故障，例如磁盘损坏，主板损坏等，未能在短期内修复好，客户端将没法链接redis
二、Redis的内存是有限的，可能放不下那么多的数据
三、单台Redis支持的并发量也是有限的

如图上面是master节点，下面是slave节点，即主节点和从节点。从节点也是能够对外提供服务的，主节点是有数据的，从节点能够经过复制操做将主节点的数据同步过来，而且随着主节点数据不断写入，从节点数据也会作同步的更新。
总体起到的就是数据备份的效果

除了一主一从模型以外，redis还提供了一主多从的模型，也就是一个master能够有多个slave，也就至关于有了多份的数据副本。

读写分离

除了做为数据备份，主从模型还能作另一个功能，就是读写分离。
让master节点负责提供写服务，slave节点提供读服务，而将数据读取的压力进行分流和负载，分摊给所
有的从节点。

主从复制的配置

1. slaveof命令

slaveof 198.162.88.66 6379

执行该命令使当前redis节点成为指定redis节点的从节点，此复制命令是异步进行的，redis会自动进行后续数据复制的操做

若是想取消从节点能够执行 slave of on one 命令

二、修改配置

# 配置主节点的IP和端口号
slaveof ip port
# 从节点只作读的操做，保证主从数据的一致性
slave-read-only yes

runid和复制偏移量

redis每次启动的时候都会有一个随机的ID，做为一个标识，这个ID就是runid，固然重启以后值就改变了。
假如端口为6380的redis去复制6379，知道runid后，在6380上作一个标识，若是runid改变了，说明主可能重启了或者发生了其它变化，这时候就能够作一个全量复制把数据同步过来。或者第一次启动时根本不知道6379的runid，也会进行全量复制

偏移量：数据写入量的字节
好比主执行set hello world，就会有一个偏移量，而后从同步数据，也会记录一个偏移量
当两个偏移量达到一致时候，实际上数据就是彻底同步的状态。

全量复制

全量复制主节点会将RDB文件也就是当前状态去同步给slave，在此期间主节点新写入的命令会单独记录起来，而后当RDB文件加载完毕以后，会经过偏移量对比将这个期间产生的写入值同步给slave，这样就能达到数据彻底同步的效果

全量复制过程

1. 在其内部有一条命令psync，是作同步的命令，它能够完成全量复制和部分复制的功能，当启动slave节点时，它会发送psync命令给主节点，须要传递两个参数，runid和offset(偏移量)，也就是从节点向主节点传递主节点的runid以及本身的偏移量，对于第一次复制而言，就直接传递？和 -1，固然这个参数是由slave内部传的。
2. master接收到命令后知道从但愿作全量复制，主就会将本身的runid和offset传递给从节点
3. slave节点保存master的基本信息
4. master执行bgsave生成RDB文件，而且在此期间新产生的写入命令会被记录到repl_back_buffer(复制缓冲区)
5. 主节点向从节点传输RDB文件
6. 主节点向从节点发送复制缓冲区内容
7. 清空从节点旧的数据
8. 从节点加载RDB文件到内存中，同时加载缓冲区数据

执行全量复制除了开销大以外，还会有个问题：
假如master和slave网络发生了抖动，那一段时间内这些数据就会丢失，对于slave来讲这段时间master更新的数据是不知道的。最简单的方式就是再作一次全量复制，从而获取到最新的数据，在redis2.8以前是这么作的。

部分复制

redis2.8以后提供部分复制，若是发生相似网络抖动，能够有这样一种机制将这种损失下降到最低，如何实现的？

部分复制过程

1. 若是发生了抖动，至关于链接断开了
2. 主节点会将写命令记录到缓冲区(repl_back_buffer)
3. 当slave再次去链接master时候，就是说网络抖动结束以后，会触发部分复制
4. 从节点会执行pysnc命令，将当前本身的offset和主的runid传递给master
5. 若是发现传输的offset偏移量是在buffer内的，若是不在内就说明你已经错过了不少数据，buffer也是有限的，默认是1M(建议调为10M)，会将offset开始到队列结束的数据同步给从节点。这样master和slave就达到了一致。

经过部分复制有效的下降了全量复制的开销。

Redis Sentinel

简介

Sentinel(哨兵)是用于监控redis集群中master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4以后的版本中。
Sentinel系统能够监视一个或者多个redis master服务，以及这些master服务的全部从服务；当某个master服务下线时，自动将该master下的某个从服务升级为新的master服务，替代已下线的master服务继续处理请求，等挂掉的主服务器重连上来，会将它变成从服务器。

三个定时任务

Sentinel在内部有3个定时任务
1）每隔10秒——每一个sentinel会对master和slave执行info命令，这个任务主要用来发现slave节点和确认主从关系。
2）每隔2秒——每一个sentinel经过master节点的channel交换信息（pub/sub）。master节点上有一个名为__sentinel__:hello的发布订阅的频道。sentinel节点经过__sentinel__:hello频道进行信息交换(对节点的"见解"和自身的信息)，达成共识。
3）每隔1秒——每一个sentinel对其余sentinel和redis节点执行ping操做（相互监控），这个实际上是一个心跳检测，是失败断定的依据。

主观/客观下线

判断主服务器是否下线有两种状况：

主观下线

Sentinel会以每秒一次的频率向与它建立命令链接的实例(包括主从服务器和其余的Sentinel)发送PING命令，经过PING命令返回的信息判断实例是否在线
若是一个主服务器在down-after-milliseconds毫秒内连续向Sentinel发送无效回复，那么当前Sentinel就会主观认为该主服务器已经下线了。

客观下线

当Sentinel将一个主服务器判断为主观下线之后，为了确认该主服务器是否真的下线，它会向一样监视该主服务器的Sentinel询问，看它们是否也认为该主服务器是否下线。
若是足够多的Sentinel认为该主服务器是下线的，那么就断定该主服务为客观下线，并对主服务器执行故障转移操做。

conf文件配置

在redis-sentinel的conf文件里有这么两个配置：

1）sentinel monitor <masterName> <ip> <port> <quorum>

四个参数含义：
masterName这个是对某个master+slave组合的一个区分标识。
ip 和 port 就是master节点的 ip 和 端口号。
quorum这个参数是进行客观下线的一个依据，意思是至少有 quorum 个sentinel主观的认为这个master有故障，才会对这个master进行下线以及故障转移。由于有的时候，某个sentinel节点可能由于自身网络缘由，致使没法链接master，而此时master并无出现故障，因此这就须要多个sentinel都一致认为该master有问题，才能够进行下一步操做，这就保证了公平性和高可用。

2）sentinel down-after-milliseconds <masterName> <timeout>

这个配置其实就是进行主观下线的一个依据，表示：若是这台sentinel超过timeout这个时间都没法连通master包括slave的话，就会主观认为该master已经下线。

领导者选举

当一个主服务器被认为客观下线之后，此时须要一个Sentinel服务器对该服务器进行处理，所以监视这个下线的主服务器的各个Sentinel会进行协商，选举出一个领头的Sentinel，领头的Sentinel会对下线的主服务器执行故障转移操做。

选举领头Sentinel的规则也比较多，总的来讲就是 先到先得(哪一个快，就选哪一个)

故障转移处理

1. 多个sentinel发现并确认master有问题
2. 选举出一个sentinel做为领导
3. 选出一个slave做为master
4. 通知其他slave成为新的master的slave
5. 通知客户端主从变化
6. 等待老的master复活成为新master的slave

注意：挑选某一个从服务器做为主服务器也是有策略的，大概以下：

（1）跟master断开链接的时长
（2）slave优先级
（3）复制offset大小
（4）run id

Redis Cluster

Redis3.0版本以前，能够经过Redis Sentinel（哨兵）来实现高可用，从3.0版本以后，官方推出了Redis Cluster，它的主要用途是实现数据分片，而且实现高可用。

在Redis Sentinel模式中，每一个节点须要保存全量数据，冗余比较多，而在Redis Cluster模式中，每一个分片只须要保存一部分的数据，

Redis Cluster每一个节点都保存各自的数据和整个集群的状态。每一个节点都和其余全部节点链接，并且这些链接保持活跃，这样就保证了咱们只须要链接集群中的任意一个节点，就能够获取到其余节点的数据。

Redis Cluster的具体实现细节是采用了Hash槽的概念，集群会预先分配16384个槽，并将这些槽分配给具体的服务节点，经过对Key进行CRC16(key)%16384运算获得对应的槽是哪个，从而将读写操做转发到该槽所对应的服务节点。当有新的节点加入或者移除的时候，再来迁移这些槽以及其对应的数据。在这种设计之下，咱们就能够很方便的进行动态扩容或缩容。

Redis Cluster为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。

有关redis集群的安装配置在这里就很少说了，在这里对先对redis cluster有个了解，往后再来补充。

参考

从零单排学Redis
Redis Cluster