前言:

在开发环境中,我们一般的都是使用单例Redis而非Redis集群,但是在生产环境中如果该对于可用性和可靠性的要求比较高的话就需要引入搭建Redis集群啦!下面给大家介绍三种Redis的集群方案.

Redis的三种集群方案

  1. 主从复制模式
  2. Sentinel(哨兵)模式
  3. Cluster模式
1. 主从复制模式

主从复制模式中包含一个主数据库实例(master)和一个或者多个从数据库实例(slave),如下图

redis集群设计 redis集群方案有哪些_redis


客户端对于主数据库可以进行读写功能对于从数据库进行读操作,主数据库写入的数据会实时的同步到从数据库中.

其具体步骤如下:

1.从数据库(一下简称slave)启动后想主数据库(一下简称master)发送SYNC(同步)指令,master接收到同步指令后通过bgsave保存快照,并使用缓冲区记录保存快照这段时间内执行的写命令.

2.master将保存的快照文件发送给slave,并继续记录执行的写命令.

3.slave在接收到快照文件后加载文件载入数据.

4.master快照发送完后开始向slave发送缓冲区的写命令,slave接收命令并且执行完成复制初始化.

5.此后master每执行一个写命令都会同步发送到slave,保证master和slave之间的数据一致性.

具体配置如下:
Redis版本为5.0.3
redis.conf的主要配置

protected-mode no # 关闭保护模式,使用密码访问
port 6379 # 端口号 建议还是使用默认端口号
timeout 30 #客户端的空闲多久后断开连接,单位秒,0表示禁用

###通用配置###
daemonize yes #在后台运行
pidfile /var/run/redis_6379.pid #pid进程文件名
logfile /user/local/redis/logs/redis.log #日志文件的位置

###RDB持久化配置###
save 900 1 # 900内至少一直写操作则执行bgsave进行RDB持久化
save 300 10
save 60 10000
rdbcompression yes #是否对RDB文件进行压缩,建议设置为no,以(磁盘)空间换(cpu)时间
dbfilename dump.rdb #RDB文件名
dir /user/local/redis/datas #RDB文件的保存路径,AOF文件也保存在这里

###AOF配置###
appendonly yes # 默认值是no ,表示不使用AOF增量持久化
appendfsync everysec # 可选值always、everysec、no,建议设置为everysec

###设置密码###
requirepass 123456 # 密码可行设置

部署主从复制模式只需要稍微调整slave的配置,在redis.conf中添加如下配置:

replicaof 127.0.0.1 6379  # master(主数据库)的ip和端口号
masterauth 123456 # master的密码(上面设置的密码)
replica-serve-stale-data no # 如果slave无法与master同步,设置成slave不可读,方便监控脚本发现问题.

此模式的优缺点如下
优点:

  1. master能自动的将数据同步到slave,可以进行读写分离分担maser的读压力.
  2. master、slave之间的同步是以费阻塞的方式进行的,同步期间,客户端仍然可以提交查询或者更新请求.

缺点:
1. 不具备自动容错和恢复功能,master或者slave宕机都可能导致客户端请求失败,需要等待机器重启或者手动切换客户端ip才能够恢复.
2. master宕机如果宕机前的数据没有同步完就会存在数据丢失和切换ip后数据不一致的情况.
3. 难以支持在线扩容,Redis的容量受限于单机配置.

Sentinel(哨兵)模式

哨兵模式是基于主从复制模式的只是对其进行了优化,加入了哨兵来监控与自动处理故障.相当于实现了Redis集群的高可用和和故障转移的问题.哨兵的主题功能如下:
1.监控master和slave是否正常运行.
2.当master出现故障的时候能够自动将一个slave转换成master
3.多个哨兵可以监控同一个Redis,哨兵之间也可以互相监控.
哨兵模式的具体工作原理:
在配置文件中通过sentinel monitor 标签来定位master的ip、端口,如果要监控多个master的话只需要提供多个配置就可以了.哨兵启动后会与要监控的master建立俩条连接:

  1. 一条连接用来订阅master的_sentinel_:hello频道与获取其他的监控master的哨兵节点信息.
  2. 另一条连接定期向master发送INFO的步伐命令获取master本身的信息.
    具体配置:
    Redis版本为5.0.3版本
    哨兵的配置文件为sentinel.conf,在配置文件中添加如下配置:
sentinel monitor mymaster 127.0.0.1 6379 1 # mymaster定义一个master数据库的名称,后面是master数据库的ip和端口号,1表示至少需要一个sentinel进程同意才能将master判断为失效,如果不满足这个条件则自动故障转移(failover)不会执行
sentinel auth-pass mymaster 123456 #master的连接密码

sentinel down-after-milliseconds mymaster  5000 # 5秒未回复PING,则认为master下线了,默认30秒
sentinel parallel-syncs mymaster 2 # 指定在执行故障转移的时候最多可以有多少个slave实例在同步master实例,在slave实例较多的情况下这个数字越小同步的时间越长完成故障转移的时间越长
sentinel failover-timeout mymaster 30000 # 如果该时间内(毫秒)未能完成故障转移操作则认为故障转移失败

哨兵模式的优缺点
优点:

  1. 哨兵模式基于主从复制模式,所以主从复制的优点它都有.
  2. master宕机了也可以自动进行切换master提高了系统的可用性和稳定性.

缺点:

  1. Redis的在线扩容难,容量还是受限于单机配置.
  2. 需要额外的资源来启动sentinel进程实现相对来说复杂一点,同时slave节点作为备份节点不提供服务.
Cluster模式

Cluster模式实现了Redis的分布式存储可以解决主从复制模式和哨兵模式在线扩容难的问题.
特点:

  1. 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.
  2. 节点的fail是通过集群中超过半数的节点检测失效时才生效.
  3. 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点就可以了.
    工作机制:
    1.在redis的每个节点上都有一个插槽(slot)取值范围是0-16383.
    2.当我们存储key的时候Redis会根据CRC16的算法得出一个结果,然后把结果对16384求余数,这样每个key都会对应一个编号在16383之间的哈希槽,通过这个值去找对应的插槽所对应的节点,然后直接自动跳转到这个对应节点上进行存取操作.
    3.为了保证高可用,cluster模式也引入主从复制模式一个主节点对应一个或者多个节点,当主节点宕机的时候就会启用从节点.
    4.当其他主节点PING一个主节点A时,如果半数以上的主节点与A通信超时,那么认为主节点A宕机了,于是改集群无法再提供服务啦!
    Cluster模式集群节点最小配置6个节点(3主3从,因为需要半数以上),其中主节点提供读写从节点作为备用节点不提供请求只作为故障转移使用.
    具体配置:
    Redis版本5.0.3
    在redis.conf中:
port 6100 # 本实例6个节点端口分别为6100，6200，6300，6400，6500，6600
daemonize yes # 后台运行
pidfile /var/run/redis_6100.pid # pid进程名
cluster-enabled yes # 开启集群模式
masterauth password # 如果设置了密码需要指定master密码
cluster-config-file nodes_6100.conf # 集群的配置文件
cluster-node-timeout 1500 # 请求超时时间,默认15秒,可自行设置.

分别以6100,6200,6300,6400,6500,6600端口启动Redis因为是在一台机器上演示所以需要设置不同的端口,如果是有六台服务器的话就不要这样子了.然后通过如下命令将这六个实例组成一个3主3从节点的集群

redis-cli --cluster create --cluster-replicas 1 127.0.0.1:6100 127.0.0.1:6200 127.0.0.1:6300 127.0.0.1:6400 127.0.0.1:6500 127.0.0.1:6600 -a password

cluster模式的优缺点:
优点:
1.无中心架构数据按照slot分布在多个节点.
2.集群中每个节点都是平等的关系,每个节点都保存各自的数据和整个集群的状态.每个节点都和其他所有节点连接,而且这些连接保持活跃这样就保证了我们只需要连接集群中的任意一个节点就获取到其他节点的数据.
3.可线性扩展到1000多个节点,节点可动态添加或删除.
4.节点实现自动转移故障,节点之间通过gossip协议交换信息,用投票机制完成slave到master的角色转换.
缺点:
1.客户端实现比较复杂,驱动要求实现Smart Client,缓存slots mapping信息并及时更新,增加了开发难度.目前好像只有JedisCluster比较成熟,异常处理还不完善,比如常见的"maxredirect exception"
2.节点会因为某些原因发生在阻塞(阻塞时间大于ckuster-node-timeout)被判断下线.
3,数据通过异步复制不保证数据的强一致性.
4.salve只是充当备胎,不能缓解读压力.
5.批量操作限制,目前及支持具有相同得slot值的key执行批量操作.
6.可以事务支持有限,只支持多key在同一节点的事务操作,多key分布在不同节点的时候不支持事务.
7.不支持多数据库空间,单机Redis可以支持16个DB,集群模式下只能使用一个即db 0

Redis Cluster模式不建议使用pipeline和muti-keys操作,减少max redirect产生的场景.