redis集群介绍、部署

一：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 等操作可能存在于多个节
     点上，因此不被支持。
• 2. key 事务操作 支持有限：只支持 多 key 在 同一节点上 的 事务操作，当多个 key 分布在 不同 的节点上
     时 无法 使用事务功能。
• 3. key 作为 数据分区 的最小粒度
• 4. 不能将一个 大的键值 对象如 hash、list 等映射到 不同的节点。
• 5. 不支持 多数据库空间：单机 下的 Redis 可以支持 16 个数据库（db0 ~ db15），集群模式 下只能使用 一
     个 数据库空间，即 db0。
• 6. 复制结构 只支持一层：从节点 只能复制 主节点，不支持 嵌套树状复制 结构。
• 7. 命令大多会重定向，耗时多
     
     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