缓存-redis 三种模式搭建和运行原理

标签： redis 缓存 主从 哨兵 集群

本文简单的介绍redis三种模式在linux的安装部署和数据存储的总结，希望可以相互交流相互提升。

对于Centos7在安装redis之前需要进行一些常用工具的安装：

关闭防火墙

正式安装redis

在redis进行maketest时候会出现一系列的异常，有如下解决方案：

用redis-server启动一下redis，做一些实验没什么意义。

要把redis作为一个系统的daemon进程去运行的，每次系统启动，redis进程一起启动， *** 作不走如下：

RDB和AOF是redis的一种数据持久化的机制。 持久化 是为了避免系统在发生灾难性的系统故障时导致的系统数据丢失。我们一般会将数据存放在本地磁盘，还会定期的将数据上传到云服务器。

RDB 　是redis的snapshotting，通过redis.conf中的save配置进行设置，如 save 60 1000:

AOF 　是以appendonly方式进行数据的储存的，开启AOF模式后，所有存进redis内存的数据都会进入os cache中,然后默认1秒执行一次fsync写入追加到appendonly.aof文件中。一般我们配置redis.conf中的一下指令：

AOF和RDB模式我们一般在生产环境都会打开，一般而言，redis服务挂掉后进行重启会优先家在aof中的文件。

当启动一个slave node的时候，它会发送一个PSYNC命令给master node,如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据否则如果是slave node第一次连接master node，那么会触发一次full resynchronization

开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。

slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save *** 作，用一份数据服务所有slave node。

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。

master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制,但是如果没有找到对应的offset，那么就会执行一次resynchronization。

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了，可以有如下配置：

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

在redis.conf配置文件中，上面的参数代表至少需要3个slaves节点与master节点进行连接，并且master和每个slave的数据同步延迟不能超过10秒。一旦上面的设定没有匹配上，则master不在提供相应的服务。

sdown达成的条件很简单，如果一个哨兵ping一个master，超过了 is-master-down-after-milliseconds 指定的毫秒数之后，就主观认为master宕机

sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了 quorum 指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个slave来做切换，这个slave还得得到majority哨兵的授权，才能正式执行切换；

（2）SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态

（3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致

4.3.2 slave的永久下线

让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行.

redis的集群模式为了解决系统的横向扩展以及海量数据的存储问题，如果你的数据量很大，那么就可以用redis cluster。

redis cluster可以支撑N个redis master,一个master上面可以挂载多个slave，一般情况我门挂载一个到两个slave，master在挂掉以后会主动切换到slave上面，或者当一个master上面的slave都挂掉后，集群会从其他master上面找到冗余的slave挂载到这个master上面，达到了系统的高可用性。

2.1 redis cluster的重要配置

2.2 在三台机器上启动6个redis实例

将上面的配置文件，在/etc/redis下放6个，分别为: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf

每个启动脚本内，都修改对应的端口号

2.3 创建集群

解决办法是 先安装rvm，再把ruby版本提升至2.3.3

使用redis-trib.rb命令创建集群

--replicas: 表示每个master有几个slave

redis-trib.rb check 192.168.31.187:7001 查看状体

3.1 加入新master

以上相同配置完成后，设置启动脚本进行启动；然后用如下命令进行node节点添加：

3.2 reshard一些数据过去

3.3 添加node作为slave

3.4 删除node

当集群内某个节点出现问题时，需要通过一种健壮的方式保证识别出节点是否发生了故障。Redis集群内节点通过ping/pong消息实现节点通信，消息不但可以传播节点槽信息，还可以传播其他状态如：主从状态、节点故障等。因此故障发现也是通过消息传播机制实现的，主要环节包括： 主观下线(PFAIL-Possibly Fail) 和 客观下线(Fail)

一个节点认为某个节点失联了并不代表所有的节点都认为它失联了。所以集群还得经过一次协商的过程，只有当大多数节点都认定了某个节点失联了，集群才认为该节点需要进行主从切换来容错。Redis 集群节点采用 Gossip 协议来广播自己的状态以及自己对整个集群认知的改变。比如一个节点发现某个节点失联了(PFail)，它会将这条信息向整个集群广播，其它节点也就可以收到这点失联信息。如果一个节点收到了某个节点失联的数量 (PFail Count) 已经达到了集群的大多数，就可以标记该节点为确定下线状态 (Fail)，然后向整个集群广播，强迫其它节点也接收该节点已经下线的事实，并立即对该失联节点进行主从切换。

集群中每个节点都会定期向其他节点发送ping消息，接收节点回复pong消息作为响应。如果在 cluster-node-timeout 时间内通信一直失败，则发送节点会认为接收节点存在故障，把接收节点标记为主观下线(PFail)状态

主观下线简单来讲就是，当 cluster-note-timeout 时间内某节点无法与另一个节点顺利完成ping消息通信时，则将该节点标记为主观下线状态

Redis集群对于节点最终是否故障判断非常严谨，只有一个节点认为主观下线并不能准确判断是否故障。当某个节点判断另一个节点主观下线后，相应的节点状态会跟随消息在集群内传播，通过Gossip消息传播，集群内节点不断收集到故障节点的下线报告。当 半数以上持有槽的主节点 都标记某个节点是主观下线时。触发客观下线流

程。

为什么必须是负责槽的主节点参与故障发现决策？

因为集群模式下只有处理槽的主节点才负责读写请求和集群槽等关键信息维护，而从节点只进行主节点数据和状态信息的复制。

为什么半数以上处理槽的主节点？

必须半数以上是为了应对网络分区等原因造成的集群分割情况，被分割的小集群因为无法完成从主观下线到

客观下线这一关键过程，从而防止小集群完成故障转移之后继续对外提供服务。

客观下线流程：

注意：

如果在 cluster-node-time*2 时间内无法收集到一半以上槽节点的下线报告，那么之前的下线报告将会过期，也就是说主观下线上报的速度追赶不上下线报告过期的速度，那么故障节点将永远无法被标记为客观下线从而导致

故障转移失败。因此不建议将 cluster-node-time 设置得过小

广播fail消息是客观下线的最后一步，它承担着非常重要的职责：

需要理解的是，尽管存在广播fail消息机制，但是集群所有节点知道故障节点进入客观下线状态是不确定的。比如当出现网络分区时有可能集群被分割为一大一小两个独立集群中。大的集群持有半数槽节点可以完成客观下线并广播fail消息，但是小集群无法接收到fail消息，网络分区会导致分割后的小集群无法收到大集群的fail消息，因此如果故障节点所有的从节点都在小集群内将导致无法完成后续故障转移，因此部署主从结构时需要根据自身机房/机架拓扑结构，降低主从被分区的可能性。

故障节点变为客观下线后，如果下线节点是持有槽的主节点则需要在它的从节点中选出一个替换它，从而保证集群的高可用。下线主节点的所有从节点承担故障恢复的义务，当从节点通过内部定时任务发现自身复制的主节点进入客观下线时，将会触发故障恢复流程

---