redis集群架构

redis架构分为4种

1. 单机模式
2. 主从模式
3. 哨兵模式
4. 集群模式(cluster sharding两种)

redis客户端常用连接
Jedis(java io socket),redisson(netty异步),lettuce(Netty 异步)
建议客户端使用 jedis+redisson

准备工作，到redis.io下载redis安装包：
下载地址：https://redis.io/download 使用的是redis高版本 redis6
然后进行解压:tar -xzvf redis-6.0.8.tar
启动命令,根据指定文件启动： ./redis-server …/redis.conf
1.使用jedis连接服务端，提供应用系统访问服务端的功能.

单机模式

配置文件基本上不需要做修改，线上使用的话需要做一些修改。
1.bind改为0.0.0.0
2.logfile以及level
3.requirepass 密码加密
4.持久化开启 两种都开启
save命令，appendonly yes,appendfsync everysec
5.持久化文件保存地址设置dir path

缺点：单机故障，不能保证可用性，单机瓶颈

主从模式

步骤基本上都是一样的，下载jar 进行解压
复制多份，设计一主二从
1.主机配置文件基本不用修改
2.从机需要修改几个参数
bind:机器实际ip
port: 端口根据实际情况决定是否修复
masterauth 主机密码
replica-serve-stale-data yes
replicaof 主机id 端口号

redis主从架构还是比较简单的，一主多从，从节点还是可以有从节点一直延续下去.

主要参考文档：https://www.jianshu.com/p/f0e042b95249
主从同步数据
全量同步
增量同步
高版本的部分同步

故障转移 ：主要有两种方式 一人工切换 二哨兵自动切换
人工切换有一些问题，一些主从选择是在客户端实现的，但是一旦主从地址变了，就需要修改本地配置，当然也可以通过配置中心来解决这个问题

模拟场景，一台机器进行的一主二从配置
主节点shutdown之后，客户端请求连接出现如下错误:
redis.clients.jedis.exceptions.JedisConnectionException: Failed connecting to ip:port
从节点依然可以正常访问。接下来手动启动主节点,之后正常运行。

另一种情况 将从节点设置为主节点，然后设置主从关系
步骤一：设置一个从节点为主节点 redis-cli -h <从节点ip> -p <从节点端口号> slaveof no one
步骤二：其他从节点修改主节点配置，使用如下命令
slaveof newmasterip:newmasterport
步骤三 ：如果原master不需要再成为master，则先重新启动或者先修改配置文件 slaveof newmasterip:newmasterport,如果想重新成为master
master 启动之后 执行如下命令：
config set masterauth ‘admin’
slaveof newmasterip:newmasterport
执行之后结果提示：Already connected to specified master
set test101 105
(error) READONLY You can’t write against a read only replica.
可见已经完成了主从切换
跳过步骤三，执行步骤四
步骤四：拷贝newmaster的aof和rdb文件替换原master，然后重新启动原master和slaver

哨兵模式

接下来进行哨兵模式的切换
人工选举master的工作交给sentinel哨兵进行处理
复制三份文件，每一份里面包含三个方面的文件
操作文件 redis-sentinel,redis-cli
日志文件 Redis-sentinel.log
启动配置文件 sentinel.conf
conf文件 主要修改以下参数：
port 26383
daemonize yes
logfile “/***/”
sentinel monitor mymaster ip port 决策数量
sentinel auth-pass mymaster admin 需要监控的master密码
其他配置基本上都是默认值

启动也很简单 redis-sentinel sentinel.conf 启动之后观察日志

之后手动将master shutdown 之后观察sentinel日志
发现sentinel做了一些事情
首先选举master,修改被选中做master的slave， slave no one
原master 执行命令 slave of newmasterip newmasterport
修改sentinel自身文件 sentinel monitor mymaster ip port

使用jedis连接哨兵模式下的集群

手动将master给关闭，之后发现一段时间不可用，没法进行操作，等选举成功之后，故障转移完成，就可以继续支持使用，无法保证高可用.

从时间上面看还是挺长的20秒钟写操作不可用.
从底层原理来分析一下 sentinel如何完成故障转移的

加入sentinel分为4个部分
1.自动发现其他sentinel和master，slave

2.定时任务通信，保持心跳，发现故障

3.选中头sentinel和选中master

4.进行故障转移

集群模式

此种模式下需要关注以下问题
1.集群之间如何数据分配
2.集群之间如何通信
3.单节点如何保证高可用
4.如何实现自动加人或者删除节点

3.0之前使用客户端分片实现，3.0之后引入集群自动实现
这是一个去除中心化的设计，无中心，每个节点都是p2p的模式。
主要是解决机器的物理内存限制，其次保证高可用

集群节点之间通信是通过gossip协议进行的
主要有4种消息
meet 新节点加入消息
ping 最普通的信息交互消息
pong 针对消息进行响应
fail 发生故障进行通知
集群的创建
主要分为两种方式 一种是ruby方式 一种是非ruby方式，ruby方式很多博客地方都有介绍，在这里就不单独介绍了。
首先创建文件夹7001，7002，7003，7004，7005，7006
分别修改conf文件，conf文件名需要不同
配置文件修改之后，分别启动各个redis节点
在节点启动之后，进行集群配置操作（非ruby形式）
1.集群之间通信 执行cluster meet操作
redis-cli -h 10.250.xx.x x -p 7001 -a admin cluster meet 10.250.xx.x x 7002
redis-cli -h 10.250.xx.x x -p 7001 -a admin cluster meet 10.250.xx.x x 7003
redis-cli -h 10.250.xx.x x -p 7001 -a admin cluster meet 10.250.xx.x x 7004
redis-cli -h 10.250.xx.x x -p 7001 -a admin cluster meet 10.250.xx.x x 7005
redis-cli -h 10.250.xx.x x -p 7001 -a admin cluster meet 10.250.xx.x x 7006
2.主节点分配槽
redis-cli -h ip -p 7001 -a admin cluster addslots {0…5461}
redis-cli -h ip -p 7002 -a admin cluster addslots {5462…10922}
redis-cli -h ip -p 7003 -a admin cluster addslots {10923…16383}
3.查看各个节点的id，之后进行主从分配
执行 cluster nodes命令
2a014ff4dfdc0e07a16df5c81adf3db62a61ca88 ip:7001@17001 myself,master - 0 1602146627000 1 connected 0-5461

40e0dba639de1f400b12a757ecbb1d0ef6f3bf9a ip:7003@17003 master - 0 1602146628000 2 connected 10923-16383

8c50a20fe996efaec747f9494b8bd97b29e796a3 ip@17004 master - 0 1602146626000 3 connected

3759c318814499bb1414791b5aca5a815bfd7453 ip:7006@17006 master - 0 1602146625860 5 connected

b5f5fcf8437808da92b6d5c58bc968f02f9e98c0 ip:7002@17002 master - 0 1602146627888 0 connected 5462-10922

694426e07f388896525547e9d57e847413cf1658 ip:7005@17005 master - 0 1602146628900 4 connected
4.根据节点id进行主从分配
redis-cli -h ip -p 7004 -a admin cluster replicate 2a014ff4dfdc0e07a16df5c81adf3db62a61ca88
此命令就是将7004节点分配给节点id为2a014ff4dfdc0e07a16df5c81adf3db62a61ca88的节点7001的从节点
执行命令，如果槽点不在则会进行redirect
Redirected to slot [700] located at ip:7001

接下来看一下集群如何保证高可用的，即某个节点宕机了，是怎么处理的
节点故障可能是主节点，也可能是从节点
我们先看一下从节点情况
我的集群基本信息如下:

7001 主 7004 从 分配槽位为 0-5461
7002主 7006从 分配槽位为 5462-10922
7003主 7005从 分配槽位为 10923-16383
key 查找槽位的是通过 crc16(key)%16384=slot
在这里推荐一个网址 在线计算crc16的
https://crccalc.com
比如key cc 经过crc之后变成了700

故障发现
首先shutdown 7002，看一下整个发现故障发现过程中 各个节点的表现

7006（7003的从节点）待cluster_node_timeout时间外还是ping不通7002.打印日志
NODE 3d308e57ae086731f24ff8cb7c187aab67ced11b possibly failing
GOSSIP 3d308e57ae086731f24ff8cb7c187aab67ced11b ip:7002@17002 master,fail?
Node 5693c6a4e329c412fb043359dc07b26dd1f30482（7003） reported node 3d308e57ae086731f24ff8cb7c187aab67ced11b as not reachable
FAIL message received from 5693c6a4e329c412fb043359dc07b26dd1f30482 about 3d308e57ae086731f24ff8cb7c187aab67ced11b
Cluster state changed: fail

7001(主节点)
NODE 3d308e57ae086731f24ff8cb7c187aab67ced11b possibly failing

GOSSIP 3d308e57ae086731f24ff8cb7c187aab67ced11b ip:7002@17002 master,fail?

Marking node 3d308e57ae086731f24ff8cb7c187aab67ced11b as failing (quorum reached).

Failover auth granted to 797f222cced36a2338e77a5438a51b70eb8d7ad7 for epoch 6

Node 797f222cced36a2338e77a5438a51b70eb8d7ad7(7005) reported node 3d308e57ae086731f24ff8cb7c187aab67ced11b as not reachable.

7003(主节点)
NODE 3d308e57ae086731f24ff8cb7c187aab67ced11b possibly failing

Node 1d9ea1bfa6f9621cc9a33ce90d618322523db616(7001) reported node 3d308e57ae086731f24ff8cb7c187aab67ced11b as not reachable

Marking node 3d308e57ae086731f24ff8cb7c187aab67ced11b as failing (quorum reached)

Failover auth granted to 797f222cced36a2338e77a5438a51b70eb8d7ad7 for epoch 6

7005(7002从节点)

NODE 3d308e57ae086731f24ff8cb7c187aab67ced11b possibly failing

Node 1d9ea1bfa6f9621cc9a33ce90d618322523db616(7001) reported node 3d308e57ae086731f24ff8cb7c187aab67ced11b as not reachable.

FAIL message received from 5693c6a4e329c412fb043359dc07b26dd1f30482(7003) about 3d308e57ae086731f24ff8cb7c187aab67ced11b

Start of election delayed for 500 milliseconds (rank #0, offset 1970).
Starting a failover election for epoch 6.
Failover election won: I’m the new master.
configEpoch set to 6 after successful failover

7004(7001的从节点)
NODE 3d308e57ae086731f24ff8cb7c187aab67ced11b possibly failing

FAIL message received from 5693c6a4e329c412fb043359dc07b26dd1f30482(7003) about 3d308e57ae086731f24ff8cb7c187aab67ced11b

Node 797f222cced36a2338e77a5438a51b70eb8d7ad7(7005) reported node 3d308e57ae086731f24ff8cb7c187aab67ced11b as not reachable.
Node 5693c6a4e329c412fb043359dc07b26dd1f30482(7001) reported node 3d308e57ae086731f24ff8cb7c187aab67ced11b as not reachable.

7002(故障节点)
User requested shutdown…
Calling fsync() on the AOF file.
Saving the final RDB snapshot before exiting.
DB saved on disk
Removing the pid file.
Redis is now ready to exit, bye bye…

大致过程是集群节点中的任意一个节点在cluster_node_timeout时间外没有ping通故障节点，则进行广播fail消息，该节点主观下线.
主节点收到消息后，发现该节点故障，则report消息该节点fail，待过半主节点认为该节点下线，则通知所有节点该故障节点下线。然后通知故障节点的从节点进行故障转移
故障转移
检查资格：故障节点的从节点,如果和主节点断线时间超过cluster-node-timeout*cluster-slave-validity-factor，则取消资格
选举顺序：偏移量最大，或者与主节点断线时间最短的优先发起选举
投票选举：获取选举资格的从节点向其他主节点发起选举，当票数达到一定的数目就会成为主节点
替换主节点：首先将从节点执行slave no one命令自己成为主节点，其次删除故障主节点负责的槽位信息，该为新节点负责槽位，之后将其他从节点变为从新节点。最后群广播节点进行信息变更

重新启动宕机的7002
Connecting to MASTER ip:7005
MASTER <-> REPLICA sync started
Non blocking connect for SYNC fired the event.
Flushing old data,Loading DB in memory

添加新节点 7007和7008
操作步骤
1.启动7007和7008
2.添加节点
使用cluster meet 或者–cluster addnode
3.分配槽位
redis-cli -h ip -p 7001 --cluster reshard ip 7007
这样节点添加成功

删除节点:
删除从节点 执行del-node
首先向主节点7001添加key ee用于验证删除节点时候有数据的情况
redis-cli -h 10.250.11.131 -p 7003 --cluster forget 10.250.11.131 7004
删除主节点7001需要reshard
redis-cli -h ip -p 7001 --cluster reshard ip 7007