redis 主从复制，哨兵，和集群架构实践

Redis 单线程和提高性能：

一、redis单点（主从）

基本上就是一主一从，我们应用层主要使用的是主节点，从节点的主要工作是从主节点做主从复制。关键时刻，如果主服务器挂掉，可以手动启动从服务器，然后更改应用层的redis的ip即可。 

 

二。scan命令

这个游标的方法，match 方法，

scan 0 match count 1000

 

常见的应用场景下我觉得redis没必要进行读写分离。

先来讨论一下为什么要读写分离：

读写分离使用于大量读请求的情况，通过多个slave分摊了读的压力，从而增加了读的性能。

过多的select会阻塞住数据库，使你增删改不能执行，而且到并发量过大时，数据库会拒绝服务。

因而通过读写分离，从而增加性能，避免拒绝服务的发生。

我认为需要读写分离的应用场景是：写请求在可接受范围内，但读请求要远大于写请求的场景。

 

再来讨论一下redis常见的应用场景：

1. 1.缓存

2. 2. 排名型的应用，访问计数型应用

3. 3. 实时消息系统

 

读写分离：
 

对于读占比较高的场景，可以通过把一部分流量分摊导出从节点(salve) 来减轻主节点（master）压力，同时需要主要只对主节点执行写操作，如下图：

当使用从节点响应读请求时，业务端可能会遇到以下问题：

复制数据：

 

1.数据延迟

Redis 复制数的延迟由于异步复制特性是无法避免的，延迟取决于网络带宽和命令阻塞情况，对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点，实现逻辑如下图：

说明如下：

1） 监控程序(monitor) 定期检查主从节点的偏移量，主节点偏移量在info replication 的master_repl_offset 指标记录，从节点 偏移量可以查询主节点的slave0 字段的offset指标，它们的差值就是主从节点延迟的字节 量。

2）当延迟字节量过高时，比如超过10M。监控程序触发报警并通知客户端从节点延迟过高。可以采用Zookeeper的监听回调机制实现客户端通知。

3） 客户端接到具体的从节点高延迟通知后，修改读命令路由到其他从节点或主节点上。当延迟回复后，再次通知客户端，回复从节点的读命令请求。

这种方案成本较高，需要单独修改适配Redis的客户端类库。

 

1.数据延迟

Redis 复制数的延迟由于异步复制特性是无法避免的，延迟取决于网络带宽和命令阻塞情况，对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点，实现逻辑如下图：

说明如下：

1） 监控程序(monitor) 定期检查主从节点的偏移量，主节点偏移量在info replication 的master_repl_offset 指标记录，从节点 偏移量可以查询主节点的slave0 字段的offset指标，它们的差值就是主从节点延迟的字节 量。

2）当延迟字节量过高时，比如超过10M。监控程序触发报警并通知客户端从节点延迟过高。可以采用Zookeeper的监听回调机制实现客户端通知。

3） 客户端接到具体的从节点高延迟通知后，修改读命令路由到其他从节点或主节点上。当延迟回复后，再次通知客户端，回复从节点的读命令请求。

这种方案成本较高，需要单独修改适配Redis的客户端类库。

2.读到过期数据

当主节点存储大量设置超时的数据时，如缓存数据，Redis内部需要维护过期数据删除策略，删除策略主要有两种：惰性删除和定时删除。

惰性删除：主节点每次处理读取命令时，都会检查键是否超时，如果超时则执行del命令删除键对象那个，之后del命令也会异步 发送给 从节点

需要注意的是为了保证复制的一致性，从节点自身永远不会主动删除超时数据，如上图。

定时删除：

Redis主节点在内部定时任务会循环采样一定数量的键，当发现采样的键过期就执行del命令，之后再同步给从节点，如下图

如果此时 数据的大量超时，主节点采样速度跟不上过期速度且主节点没有读取过期键的操作，那么从节点将无法收到del命令，这时在从节点 上可以读取到已经超时的数据。Redis在3.2 版本解决了这个问题，从节点 读取数据之前会检查键的过期时间来决定是否返回数据，可以升级到3.2版本来规避这个问题。

3.从节点故障问题

对于从节点故障问题，需要在客户端维护可用从节点列表，当从节点故障时立刻切换到其他从节点或主节点上。
但是建议如果仅仅是为性能考虑的话最好使用集群。

 

 

运维操作：

准备三个redis服务，依次命名文件夹子master,slave1,slave2.这里为在测试机上，不干扰原来的redis服务，我们master使用6000端口。

配置文件（redis.conf）

master配置修改端口：

1. port 6000

2.  

3. requirepass 123456

三。一主多从的哨兵模式

三、一主多从的哨兵模式

 

工作原理:

1.用户链接时先通过哨兵获取主机Master的信息

2.获取Master的链接后实现redis的操作(set/get)

3.当master出现宕机时,哨兵的心跳检测发现主机长时间没有响应.这时哨兵会进行推选.推选出新的主机完成任务.

4.当新的主机出现时,其余的全部机器都充当该主机的从机

这就有一个问题，就是添加哨兵以后，所有的请求都会经过哨兵询问当前的主服务器是谁，所以如果哨兵部在主服务器上面的话可能会增加服务器的压力，所以最好是将哨兵单独放在一个服务器上面。以分解压力。然后可能还有人担心哨兵服务器宕机了怎么办啊，首先哨兵服务器宕机的可能性很小，然后是如果哨兵服务器宕机了，使用人工干预重启即可，就会导致主从服务器监控的暂时不可用，不影响主从服务器的正常运行。

 

四、集群模式
一、概述

  Redis3.0版本之后支持Cluster.

1.1、redis cluster的现状

1):节点自动发现

　　2):slave->master 选举,集群容错

　　3):Hot resharding:在线分片

　　4):进群管理:cluster xxx

　　5):基于配置(nodes-port.conf)的集群管理

　　6):ASK 转向/MOVED 转向机制.

1.2、redis cluster 架构

(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

　　(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.

　　(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

　　(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value

 

 2) redis-cluster选举:容错

 

参考博文：

(1)领着选举过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉.

(2):什么时候整个集群不可用(cluster_state:fail),当集群不可用时,所有对集群的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)错误。

缓存同步：

参考博文：https://blog.csdn.net/u012045045/article/details/86623691