一：redis集群介绍

1.1 单实例的Redis缓存存在的问题

1.1.1 写并发

Redis单实例读写分离可以解决读操作的负载均衡，但对于写操作，仍然是全部落在了master节点上面，在海量数据高并发场景，一个节点写数据容易出现瓶颈，造成master节点的压力上升。

1.1.2 大量数据存储的压力

单实例Redis本质上只有一台Master作为存储，如果面对海量数据的存储，一台Redis的服务器就应付不过来了，而且数据量太大意味着持久化成本高，严重时可能会阻塞服务器，造成服务请求成功率下降，降低服务的稳定性。

1.2 什么是Redis集群

Redis3.0加入了Redis的集群模式，实现了数据的分布式存储，对数据进行分片，将不同的数据存储在不同的master节点上面，从而解决了海量数据的存储问题。 Redis集群采用去中心化的思想，没有中心节点的说法，对于客户端来说，整个集群可以看成一个整体，可以连接任意一个节点进行操作，就像操作单一Redis实例一样，不需要任何代理中间件，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node。Redis也内置了高可用机制，支持N个master节点，每个master节点都可以挂载多个slave节点，当master节点挂掉时，集群会提升它的某个slave节点作为新的master节点。
在这里插入图片描述

1.3 redis的三种集群方案

主从复制模式、哨兵机制（又称为Sentinel模式）、集群模式（又称为Cluster模式）

1.3.1 主从复制

1）原理
对读写能力扩展，采用读写分离的方式解决性能瓶颈。从服务器与主服务器进行连接，然后主服务器发送数据副本，从服务器通过网络根据主服务器的数据副本进行准实时更新，主服务器可以进行读写操作，当写操作导致数据发生变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主服务器可以有多个从服务器，但一个从服务器只能有一个主服务器。这样我们就有额外的从服务器来处理读请求，通过将读请求分散到不同的从服务器上面进行处理，用户可以从新添加的从服务器上获得额外的读查询处理能力，并且Redis通过持久化功能，保证了即使服务器宕机或重启的情况下也不会丢失数据，因为持久化会把内存中的数据保存到硬盘上，重启会从硬盘上加载数据。

2）优点

主从复制，主机会自动将数据同步到从机，实现了读写分离
从服务器提供只读操作，主服务器提供读读写操作
从服务器同样可以接受其他从服务器的连接和同步请求，这样可以有效的分载主服务器的同步压力
主服务器是以非阻塞的方式为从服务器提供服务，所以在主从同步期间，客户端依然可以提交查询或修改请求
从服务器也是以非阻塞的方式完成数据同步的，在同步期间，如果有客户端提供查询请求，Redis则返回同步之前的数据

3）缺点

Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或手动切换前端的IP才能恢复（即人工介入）
主机宕机后如果有部分数据没有及时同步到从机，更换主机IP后会导致数据不一致的问题
如果多个从机断线，需要重启的时候，如果在同一时间段进行重启，多个slave重启，都会发送sync请求并进行主机全量同步，那就会导致主机 IO剧增从而主机宕机
Redis较难支持在线扩容，在集群容量达到上限时在线扩容就会变得艰难

1.3.2 哨兵（Sentinel）机制

在这里插入图片描述

1）原理
主从复制这种同步模式，只有一个节点，那么当该主节点宕机后，需要手动切换从服务器为主服务器，这就造成不但需要人工干预，还会造成一段时间内的服务不可用，哨兵机制的集群模式就可以有效的改善这个问题。就是用一个哨兵来监控所有的服务器状态，一旦发现某个主服务器宕机或故障了，就自动让从服务器顶上去。

2）哨兵的三大工作任务

监控（Monitoring）：哨兵会不断检查主服务器和从服务以及其他哨兵是否运作正常
提醒（Notification）: 当被监控的某个服务器出现问题时，哨兵可以通过API向管理员或其他应用程序发送通知
自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时，哨兵会开始一次自动故障转移操作，它会将失效的主服务器的其中一个从服务器升级为新的主服务器，并让失效的主服务器的其他从服务器知晓新的主服务器。当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

3）优点
哨兵机制集群模式是基于主从复制模式的，所以它有主从复制的所有优点，主从服务器可以自动切换，系统更加健壮，可用性更高
4）缺点
Redis较难支持在线扩容，在集群容量达到上限时在线扩容就会变得很复杂

1.3.3 redis内置集群（Cluster模式）

在这里插入图片描述

主从模式实现了数据的热备份，哨兵模式实现了redis的高可用。但是有一个问题，这两种模式都没有解决，这两种模式都只能有一个master节点负责写操作，在高并发的写操作场景，master节点就会成为性能瓶颈。redis的集群模式中可以实现多个节点同时提供写操作，redis集群模式采用无中心结构，每个节点都保存数据，节点之间互相连接从而知道整个集群状态。
1）槽
在这里插入图片描述
Redis 集群的功能限制；Redis 集群相对单机在功能上存在一些限制，需要开发人员提前了解，在使用时做好规避。JAVA CRC16 校验算法

1. key 批量操作支持有限：类似 mset、mget 操作，目前只支持对具有相同 slot 值的 key 执行批量操作。
  对于映射为不同 slot 值的 key 由于执行 mget、mget 等操作可能存在于多个节
  点上，因此不被支持。
1. key 事务操作支持有限：只支持多 key 在同一节点上的事务操作，当多个 key 分布在不同的节点上
  时无法使用事务功能。
1. key 作为数据分区的最小粒度
1. 不能将一个大的键值对象如 hash、list 等映射到不同的节点。
1. 不支持多数据库空间：单机下的 Redis 可以支持 16 个数据库（db0 ~ db15），集群模式下只能使用一
  个数据库空间，即 db0。
1. 复制结构只支持一层：从节点只能复制主节点，不支持嵌套树状复制结构。
1. 命令大多会重定向，耗时多
  
  2）一致性 hash
  一致性哈希可以很好的解决稳定性问题，可以将所有的存储节点排列在收尾相接的Hash 环上，每个 key 在计算 Hash 后会顺时针找到临接的存储节点存放。而当有节点加入或退出时，仅影响该节点在 Hash 环上顺时针相邻的后续节点。
  Hash 倾斜
  如果节点很少，容易出现倾斜，负载不均衡问题。一致性哈希算法，引入了虚拟节点，在整个环上，均衡增加若干个节点。比如 a1，a2，b1，b2，c1，c2，a1 和 a2 都是属于 A 节点的。解决 hash 倾斜问题

二：部署redis集群

2.1 创建 6 个 redis 节点

在这里插入图片描述
3 主 3 从方式，从为了同步备份，主进行 slot 数据分片

2.2 编写创建脚本

for port in $(seq 7001 7006);
do
mkdir -p /data/mydata/redis/node-${port}/conf
touch /data/mydata/redis/node-${port}/conf/redis.conf
cat << EOF >/data/mydata/redis/node-${port}/conf/redis.conf
port ${port}
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 192.168.56.10
cluster-announce-port ${port}
cluster-announce-bus-port 1${port}
appendonly yes
EOF
docker run -p ${port}:${port} -p 1${port}:1${port} --name redis-${port} -v /data/mydata/redis/node-${port}/data:/data -v /data/mydata/redis/node-${port}/conf/redis.conf:/etc/redis/redis.conf -d redis:5.0.7 redis-server /etc/redis/redis.conf;
done

在这里插入图片描述

2.3 使用 redis 建立集群

进入7001到7003，将其作为主节点
1）进入redis
docker exec -it redis-7001 /bin/bash
2）创建三个主节点，三个从节点

redis-cli --cluster create 192.168.56.10:7001 192.168.56.10:7002 192.168.56.10:7003 192.168.56.10:7004 192.168.56.10:7005 192.168.56.10:7006 --cluster-replicas 1

在这里插入图片描述