Redis集群

redis 集群形式

• 数据分区方案
  1、客户端分区
  

  客户端分区方案 的代表为 Redis Sharding，Redis Sharding 是 Redis Cluster 出来之前，业界普遍使用的 Redis 多实例集群 方法。Java 的 Redis 客户端驱动库 Jedis，支持 RedisSharding 功能，即 ShardedJedis 以及 结合缓存池 的 ShardedJedisPool。
  优点
  不使用 第三方中间件，分区逻辑 可控，配置 简单，节点之间无关联，容易 线性扩展，灵活性强。
  缺点
  客户端 无法 动态增删 服务节点，客户端需要自行维护 分发逻辑，客户端之间 无连接共享，会造成 连接浪费。
  2、代理分区
  

  代理分区常用方案有 Twemproxy 和 Codis。
  3、redis-cluster

• 高可用方式
  1、Sentinel（ 哨兵机制）支持高可用
  前面介绍了主从机制，但是从运维角度来看，主节点出现了问题我们还需要通过人工干预的方式把从节点设为主节点，还要通知应用程序更新主节点地址，这种方式非常繁琐笨重， 而且主节点的读写能力都十分有限，有没有较好的办法解决这两个问题，哨兵机制就是针对第一个问题的有效解决方案，第二个问题则有赖于集群！哨兵的作用就是监控 Redis 系统的运行状况，其功能主要是包括以下三个：

  • 监控(Monitoring): 哨兵(sentinel) 会不断地检查你的 Master 和 Slave 是否运作正常。

  • 提醒(Notification): 当被监控的某个 Redis 出现问题时, 哨兵(sentinel) 可以通过 API向管理员或者其他应用程序发送通知。

  • 自动故障迁移(Automatic failover): 当主数据库出现故障时自动将从数据库转换为主数据库
    
    哨兵的原理
    Redis 哨兵的三个定时任务，Redis 哨兵判定一个 Redis 节点故障不可达主要就是通过三个定时监控任务来完成的：

  • 每隔 10 秒每个哨兵节点会向主节点和从节点发送"info replication" 命令来获取最新的拓扑结构
    

  • 每隔 2 秒每个哨兵节点会向 Redis 节点的_sentinel_:hello 频道发送自己对主节点是否故障的判断以及自身的节点信息，并且其他的哨兵节点也会订阅这个频道来了解其他哨兵节点的信息以及对主节点的判断

  • 每隔 1 秒每个哨兵会向主节点、从节点、其他的哨兵节点发送一个 “ping” 命令来做心跳检测
    

  如果在定时 Job3 检测不到节点的心跳，会判断为“主观下线”。如果该节点还是主节点那么还会通知到其他的哨兵对该主节点进行心跳检测，这时主观下线的票数超过了数时，那么这个主节点确实就可能是故障不可达了，这时就由原来的主观下线变为了“客观下线”。
  故障转移和 Leader 选举
  如果主节点被判定为客观下线之后，就要选取一个哨兵节点来完成后面的故障转移工作，选举出一个 leader，这里面采用的选举算法为 Raft。选举出来的哨兵 leader 就要来完成故障转移工作，也就是在从节点中选出一个节点来当新的主节点，这部分的具体流程可参考引用https://blog.csdn.net/nuomizhende45/article/details/82831966
  2、Redis-Cluster
  https://redis.io/topics/cluster-tutorial/
  Redis 的官方多机部署方案，Redis Cluster。一组 Redis Cluster 是由多个 Redis 实例组成，官方推荐我们使用 6 实例，其中 3 个为主节点，3 个为从结点。一旦有主节点发生故障的时候，Redis Cluster 可以选举出对应的从结点成为新的主节点，继续对外服务，从而保证服务的高可用性。那么对于客户端来说，知道知道对应的 key 是要路由到哪一个节点呢？Redis Cluster把所有的数据划分为 16384 个不同的槽位，可以根据机器的性能把不同的槽位分配给不同的 Redis 实例，对于 Redis 实例来说，他们只会存储部分的Redis 数据，当然，槽的数据是可以迁移的，不同的实例之间，可以通过一定的协议，进行数据迁移。

1、槽

槽

Redis 集群的功能限制；Redis 集群相对 单机 在功能上存在一些限制，需要 开发人员 提前了解，在使用时做好规避。JAVA CRC16 校验算法

• key 批量操作 支持有限。
  • 类似 mset、mget 操作，目前只支持对具有相同 slot 值的 key 执行 批量操作。对于 映射为不同 slot 值的 key 由于执行 mget、mget 等操作可能存在于多个节点上，因此不被支持。
• key 事务操作 支持有限。
  • 只支持 多 key 在 同一节点上 的 事务操作，当多个 key 分布在 不同 的节点上时 无法 使用事务功能。
• key 作为 数据分区 的最小粒度
• 不能将一个 大的键值 对象如 hash、list 等映射到 不同的节点。
• 不支持 多数据库空间
  • 单机 下的 Redis 可以支持 16 个数据库（db0 ~ db15），集群模式 下只能使用 一个 数据库空间，即 db0。
• 复制结构 只支持一层
  • 从节点 只能复制 主节点，不支持 嵌套树状复制 结构。
• 命令大多会重定向，耗时多

一致性 hash

一致性哈希 可以很好的解决 稳定性问题，可以将所有的 存储节点 排列在 收尾相接 的Hash 环上，每个 key 在计算 Hash 后会 顺时针 找到 临接 的 存储节点 存放。而当有节点 加入 或 退出 时，仅影响该节点在 Hash 环上 顺时针相邻 的 后续节点。

Hash 倾斜

如果节点很少，容易出现倾斜，负载不均衡问题。一致性哈希算法，引入了虚拟节点，在整个环上，均衡增加若干个节点。比如 a1，a2，b1，b2，c1，c2，a1 和 a2 都是属于 A 节点的。解决 hash 倾斜问题

cluster方式部署

创建6个redis节点

for循环脚本

for port in $(seq 7001 7006); \
do \
mkdir -p /mydata/redis/node-${port}/conf
touch /mydata/redis/node-${port}/conf/redis.conf
cat << EOF >/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 /mydata/redis/node-${port}/data:/data \ -v /mydata/redis/node-${port}/conf/redis.conf:/etc/redis/redis.conf \ -d redis:5.0.7 redis-server /etc/redis/redis.conf; \
done

停掉与删除

docker stop $(docker ps -a |grep redis-700 | awk '{ print $1}')
docker rm $(docker ps -a |grep redis-700 | awk '{
      print $1}`)

使用 redis 建立集群

#进入redis容器
docker exec -it redis-7001 bash
#配置 任意选取节点
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

测试

#随便进入某个 redis 容器
docker exec -it redis-7002 /bin/bash
#使用 redis-cli 的 cluster 方式进行连接
redis-cli -c -h 192.168.56.10 -p 7006
cluster info #获取集群信息
cluster nodes#获取集群节点
Get/Set #命令测试，将会重定向
#节点宕机，slave 会自动提升为 master，master 开启后变为 slave

作者声明

如有问题，欢迎指正！