使用jedis连接客户端redis，以及存在问题分析（三）：redis的分布式和高可用

根据我的上一篇文章，我们使用hash的一致性来确定key在节点上的分布情况，但是这只是支持了分布式不支持高可用，所以我们需要把高可用的基础核心：主从复制，应用到每个节点。

1.redis的主从复制

支持一主多从，多级主从，根据企业经验最多2级，一主最多6个从，否则结构不稳定（经常出现无法同步数据）。

2.redus的主从结构以及搭建过程

我们使用一主二从的结构：6382master；6383slave；6384slave；

搭建步骤

1.准备3个配置文件对应修改默认中的端口号

6382,6383,6384

2.挨个启动,确定启动没有问题

查看日志文件redis根目录6379redis.log

3.调用redis的命令查看一下主从复制的结构参数

6379>info replication

当前启动的3个redis都是主节点,都是独立的

4 在6383,6384中执行命令挂接主节点

6382>slaveof masterIp masterPort;

5.问题总结

至此redis已经支持分布式和高可用但是从节点只负责数据的备份，无法写入数据，而且主从的redis关系只负责数据的备份，无法实现主节点宕机从节点中任意节点进行替换的功能。如果想实现主从的替换就要引入redis的哨兵技术。

3.redis的哨兵进程

1.redis的哨兵逻辑

单独启动哨兵的进程,监听某一个主从的结构,单独连接主节点,利用info命令查看主从的状态,rpc心跳(heartbeat)机制检测主节点的存活;哨兵集群会对当前监听的主从结构中出现的事件进行过半选举的投票;例如主节点的宕机如果当做一个事件;选举从节点;

2.哨兵的安装和测试

1.修改启动哨兵的配置文件

在redis根目录的一个sentinel.conf redis-sentinel sentinel.conf(在这个配置文件中,配置主从的关系,主节点信息)
行信息可能根据版本号有差异，请以实际为准
15行 bind 需要注释掉ip信息不要绑定
17行 protected-mode no放开,配置no
默认端口26379 26380 26381
69行 sentinel monitor mymaster 127.0.0.1 6379 2 修改监听主从的挂接配置

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel monitor :开始监听主从结构中的主节点
mymaster:监听当前主从结构的代号（自定义）
ip:主节点所在的ip(使用对外能往返的主节点ip)如果哨兵和主从节点在同一个机器.不要使用127.0.0.1,会造成代码访问失效;
port:主节点端口号;

2.主观下线票数(最少最少启动的监听主从结构的哨兵个数)（三个哨兵集群）

哨兵集群某个节点也有宕机可能，一旦宕机会造成集群投票情况的变化，为了防止宕机过多最终导致整个哨兵的投票不可信（1个节点的投票不可信）
选举新主节点失败时的时间延迟(第二轮选举和第一轮选举的时间间隔)
131行 失败重新选举
sentinel failover-timeout mymaster 10000
当前哨兵集群对某一个事件的选举如果不成立,将会根据这里配置的时间毫秒数进行第二第三第四轮选举,知道最终结果出现;

3.复制2个配置文件并更改端口号

修改第二和第三个的端口
26379-26380

4.启动哨兵进程,开启监听主从结构

5.测试总结

杀掉主节点，测试哨兵能否启动从节点

发现宕机,new-epoch:逻辑时间数;与当前的日志步数
将宕机的主节点重启
启动后发现哨兵将重启的主节点转化成从节点提供主从服务
宕机掉一个哨兵
当两个哨兵管理主从时,一个宕机,导致另一个的选举没有过半无法生效
quorum
最好启动奇数个哨兵,每次至少有过半的哨兵选举成功才行

4.redis集群概括

缺点: key值的存储非常被动,数据的微调很难完成
slave节点相对master集群中的资源占用和master一样,
服务提供非常微小
sentinel分布式高可用集群,整合到springboot必须实现异常获取转向
主从替换的逻辑(代码引入框架非常复杂);代码端实现功能太多;