前言

为什么要做集群？解决什么问题？

1、避免单点故障，实现高可用；就需要数据沉余，通过沉余副本也是slave。

三种集群区别？

1、主从复制

复制策略 --> 全量复制

第一次连接到master，master生成最新的rdb文件同步到子节点上

如果子节点上有数据，则清除子节点上的所有数据，同步rdb文件到子节点

--> 增量复制

已经连接过master，通过子节点的偏移量记录的下需要从那个位置开始同步

缺点： --> 如果节点down，需要手动重启，没有解决高可用

选举： --> 如果主节点down了； 1、各个节点看下谁的偏移量大，谁就成为master，如果偏移量都相同，则看redis进程mid谁最小，谁最小就是成为master

复制过程： 单从节点执行指令slaveof masterIp masterPort后，从节点就定时任务的发现主节点的信息，并建立socket连接, 从节点会发送ping执行给主节点，而主节点pong回应. 确认连接后，主节点开始同步数据到从节点，已rdb形式发送到从节点。（全量复制和增量复制了，如上）

存在的问题：

1、主节点是属于单机形式（写和存储）

2、注解点宕机后，需要人工重启

3、如果主节点发送数据到从节点同步失败，从节点发出psync指令。可能全出现全量同步，而从节点，可能出现卡顿现象

1-1、主从复制配置

在从节点redis.config 中配置

slaveof 主节点ip 主节点端口

masterauth 主节点如果配置了密码，需要增加密码配置

配置一主两从（一windows为列），我这里是使用5.0版本

1、如下:

2、配置主节点 （暂时不往优化上靠，随意部署起来）

3、配置6380节点 使用5.0版本，5.0一下应该使用slaveof配置

4、 在redis.config配置主节点，这里是一主两从，两个从节点配置主节点

5、./redis-service redis.config

2、哨兵集群

主要功能：存活检测，主从情况检测，自动故障转移,主从切换

Sentinel 哨兵机制： 本质上是运行在特殊模式下的redis，通过info指令也监控redis,哨兵也是特殊的Redis，有着订阅发布的功能，会通过_sentinel_：hello 发送消息进行监控

服务下线 -- > 主观下线 --> 默认以每秒一次的频率发送Ping命令，没有收到有效回复，sentinel会把该服务器标记为下

--> 客观下线 --> 发现master下线的Sentinel节点会继续询问其他Sentinel节点, 大多数Sentinel认为下线

，master才真正确认被下线

选举机制 --> 哨兵选举 --> 采用类似raft算法

redis选举 --> 查看主从复制

客户端连接 --> 一致性哈希，一个哈希环,但是节点可能存在分布不均，节点down后，数据需要重新

同步到其他节点中, 所以这里要引入虚拟节点.虚拟节点执行真是节点

2-1、哨兵配置

在主从复制基础上增加哨兵配置

在每个节点下配置哨兵配置

启动哨兵

./redis-service sentinal.config --sentinal

3、redis-cluster集群

由多个Redis 实例组成的数据集合。客户端不需要关注数据的子集到底存储在哪个节点，只需要关注这个集合整体

Redis创建了16384个槽(slot)，每个节点负责一定区间的slot

对 key 用CRC16算法计算再模以16384，得到一个slot的值，数据落到负责这个slot的Redis节点上

特点：无中心架构

可动态调整数据分布

可扩展性

高可用性

降低运维成本

3-1、集群配置

1、在哨兵的基础上，删除主从复制配置。

2、在每个节点上开启集群配置。如下配置：

3、启动所有节点配置

./redis.service redis.config

4、在任务节点上执行

./redis-cli.exe --cluster create 127.0.0.1:6379 127.0.0.1:6479 127.0.0.1:6380127.0.0.1:6480 127.0.0.1:6381 127.0.0.1:6481 --cluster-replicas 1

--cluster: 集群配置

create:创建集群节点

--cluster-replicas 1 , 1表示一主一从 127.0.0.1:6379 127.0.0.1:6479 为一组

这里配置就是三主三从

如果配置2，表示一主而从

5、注意：节点必须是单数，也就是必须是3个节点以上。

4、客户端

因为不同的配置，会有不同的客户端设置。copy + c

1、redisTemplate是基于某个具体实现的再封装，比如说springBoot1时，具体实现是jedis；

而到了springBoot2.x时，具体实现变成了lettuce。封装的好处就是隐藏了具体的实现，使调用更简单，

但是有人测试过jedis效率要10-30倍的高于redisTemplate的执行效率，所以单从执行效率上来讲，

jedis完爆redisTemplate。redisTemplate的好处就是基于springBoot自动装配的原理，

使得整合redis时比较简单。

2、jedis作为老牌的redis客户端，采用同步阻塞式IO，采用线程池时是线程安全的。

优点是简单、灵活、api全面，

缺点是某些redis高级功能需要自己封装。

3、lettuce作为新式的redis客户端，基于netty采用异步非阻塞式IO，是线程安全的，

优点是提供了很多redis高级功能，例如集群、哨兵、管道等，

缺点是api抽象，学习成本高。lettuce好是好，但是jedis比他生得早。

4、redission作为redis的分布式客户端，同样基于netty采用异步非阻塞式IO，是线程安全的，

优点是提供了很多redis的分布式操作和高级功能，

缺点是api抽象，学习成本高。

1、主从复制