Redis实战总结-Redis的高可用性

在之前的博客《Redis实战总结-配置、持久化、复制》给出了一种Redis主从复制机制,简单地实现了Redis高可用。然后,如果Master服务器宕机,会导致整个Redis瘫痪,这种方式的高可用性较低。正常会采用多台Redis服务器构成一个集群,即使某台,或者某几台Redis宕机,Redis集群仍能正常运行,从而提高其高可用性。

在Redis中,主要存在两种方式实现Redis集群机制:

  • Redis Sentinel集群机制:在Redis2.X版本,往往都是通过这种方式实现Redis的高可用。redis-sentinel是在master-slave机制上加入监控机制哨兵Sentinel实现的。

  • Redis Cluster集群机制:在Redis3.0版本后推出了redis-cluster集群机制。redis-cluster集群中各个节点之间是对等的,即master-master模式。

**注意:**Redis Sentinel集群是解决HA问题的(主从同步),Redis Cluster集群是解决sharding问题的(分区),两种不重复,可以混合使用。

下面详解这两种集群,并给出具体的演示示例。

1. Redis Sentinel集群机制

Redis-Sentinel是在master-slave机制上加入监控机制哨兵Sentinel实现的。Sentinel主要功能就是为Redis Master-Slave集群提供:

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

在Sentinel集群中,一个最小的Master-Slave单元包含一个master和一个slave服务器。当master失效后,sentinel自动将slave提升为master,从而可以减少管理员的人工切换slave的操作过程。

1.1 Redis-Sentinel集群架构图

Redis实战总结-Redis的高可用性

1.2 各个机器配置

部署在本地机器上,保证各个端口号不一样,具体配置如下

  • Redis服务器:

    • master:127.0.0.1:6379
    • slave01:127.0.0.1:6389
    • slave02:127.0.0.1:6399
  • Sentinel服务器

    • sentinel01:127.0.0.1:26379
    • sentinel02:127.0.0.1:26389
    • sentinel03:127.0.0.1:26399

1.3 redis.conf和sentinel.conf配置

  • redis.conf

    • master特殊配置如下:

    # 后台线程启动 daemonize yes # 监听端口号 port 6379 # 访问验证密码 requirepass "123456"
    • slave特殊配置如下:

    # 后台线程启动 daemonize yes # 监听端口号,如果为slave02,端口号为6399 port 6389 # 主节点访问密码 masterauth "123456" # 访问验证密码 requirepass "123456" # 主节点服务器IP和端口号 slaveof 127.0.0.1 6379
  • sentinel.conf

# 后台线程启动
daemonize yes
# 监听端口号,如果为sentinel02,则端口号为26389,如果为sentinel01,则端口号为26399
port 26379
#1表示在sentinel集群中只要有两个节点检测到redis主节点出故障就进行切换
sentinel monitor mymaster 127.0.0.1 6379 1
# master节点密码验证
sentinel auth-pass mymaster 123456
#如果3秒内mymaster无响应,则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
# 选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长
sentinel parallel-syncs mymaster 1
#如果10秒后,mysater仍没活过来,则启动failover
sentinel failover-timeout mymaster 10000

注意:

  • 1.如果上述涉及的所有配置均放置在同一目录下,需保证各配置名称不同;
  • 2.在配置中,不同实例的日志输出、快照文件要求名称不能一样,具体可自行配置;
  • 3.一定要保证”sentinel myid”不相同,否则无法进行故障转移

1.4 启动集群及启动后结果详情展示

  • 各Redis节点启动:

    redis-server redis_****.conf
  • 各Sentinel节点启动

    redis-sentinel sentinel_*****.conf
  • Redis Master节点详情展示
  • Redis实战总结-Redis的高可用性

Redis Slave节点效果截图展示

Redis实战总结-Redis的高可用性

各个Sentinel节点详情展示

Redis实战总结-Redis的高可用性

1.5 高可用性场景测试

  • Master宕机

Redis实战总结-Redis的高可用性

  • sentinel使用failover机制重新选举出master
  • Master恢复

Redis实战总结-Redis的高可用性

  • master节点恢复后,由Master变成slave
  • Slave宕机

Redis实战总结-Redis的高可用性

  • 哨兵发现6399已经宕机,等待6399的恢复(主观下线)
  • Slave重启6399节点

Redis实战总结-Redis的高可用性

如果想详细了解sentinel机制的话,可以参考博客: 
http://shift-alt-ctrl.iteye.com/blog/1884370

2. Redis Cluster集群机制

2.1 Redis-cluster介绍

Redis-cluster是一种服务器Sharding技术,Redis3.0以后版本正式提供支持。

Redis-cluster没有使用一致性hash,而是引入了哈希槽的概念。Redis-cluster中有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽。Cluster中的每个节点负责一部分hash槽(hash slot),比如集群中存在三个节点,则可能存在的一种分配如下:

  • 节点A包含0到5500号哈希槽;
  • 节点B包含5501到11000号哈希槽;
  • 节点C包含11001 到 16384号哈希槽。

这种集群架构很容易扩展,如果扩充一个节点D,只需要将A、B、C节点中的部分槽放置在D上;如果想移除节点A,只需要将A的slot转移到B和C节点上。由于将哈希槽从一个节点移动到另一个节点不需要停止服务,只需要通过命令直接再分配,因而上述拓展不会造成集群不可用。目前这种方式还是一种半自动的方式,需要人工介入。

2.2 Redis-Cluster主从复制

在Redis-Cluster中,如果某个节点宕机或者处在不可用状态时,那它负责的Hash槽也将失效,导致整个集群不可用。因而为了提供高可用性,正常会将每个节点配置成主从式结构,即一个master节点,挂在多个slave节点。如果Master节点失效时,集群便会选取一个slave节点作为master,继续提供服务,从而不会导致整个集群不可用。

2.3 Redis-Cluster集群模拟

2.3.1 Redis-Cluster集群准备

  • 集群部署图

Redis实战总结-Redis的高可用性

  • 集群由三个节点组成,每个节点均为主从式架构。因而共需要创建6个Redis实例,分配如下:

    • Redis01:127.0.0.1:7000
    • Redis02:127.0.0.1:7001
    • Redis03:127.0.0.1:7002
    • Redis04:127.0.0.1:7003
    • Redis05:127.0.0.1:7004
    • Redis06:127.0.0.1:7005

    对于每个实例的redis_700*.conf配置如下:

    # 监听端口号
    port 700*
    # 开启集群
    cluster-enabled yes
    # 修改集群加载配置文件,不需要手动创建,启动后默认生成,并且需要时自动更新
    cluster-config-file /Users/guweiyu/develop/redis/redis-cluster/workpid/nodes-7000.conf
    # 集群中的节点能够失联的最大时间,超过这个时间,该节点就会被认为故障
    cluster-node-timeout 15000
    # 默认为“no”,表示部分Key所在的节点不可用时,集群仍然为可达节点提供服务;如果为“yes”,表示部分key所在的节点不可用时,则整个集群停止服务。注意:实际使用中要修改为"yes"
    cluster-require-full-coverage no
  • 安装ruby,如果为Mac OS系统,直接执行即可:

    brew install ruby

2.3.2 集群启动

  • 启动所有Redis实例,可以编写一个启动和停止所有redis实例的脚本(start.sh,stop.sh)

    redis-server redis_7000.conf
    redis-server redis_7001.conf
    redis-server redis_7002.conf
    redis-server redis_7003.conf
    redis-server redis_7004.conf
    redis-server redis_7005.conf ps -ef | grep redis-server
    echo "redis 7000-7005全部启动完成"
  • redis-cli -p 7000 shutdown
    redis-cli -p 7001 shutdown
    redis-cli -p 7002 shutdown
    redis-cli -p 7003 shutdown
    redis-cli -p 7004 shutdown
    redis-cli -p 7005 shutdown ps -ef | grep redis-server
    echo "redis-server 7000-7005节点已全部停止"
  • 1创建redis-cluster

Redis中创建集群是通过redis-trib.rb命令实现的,redis-trib.rb位于Redis源码的src目录下,可将其直接拷贝到当前目录下。

运行命令

./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

如果出现如下错误:

/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- redis (LoadError)
from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from ./redis-trib.rb:25:in `<main>'

这是由于没有安装redis的第三方接口导致的。因此需要给Ruby安装client包,如下(必须加上sudo执行,否则会执行失败):

sudo gem install redis

再执行创建集群命令,结果如下:

>>> Creating cluster
>>> Performing hash slots allocation on 6 nodes...
Using 3 masters:
127.0.0.1:7000
127.0.0.1:7001
127.0.0.1:7002
Adding replica 127.0.0.1:7004 to 127.0.0.1:7000
Adding replica 127.0.0.1:7005 to 127.0.0.1:7001
Adding replica 127.0.0.1:7003 to 127.0.0.1:7002
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: aab0162a039d2f224322afe6caf2e153230f2d82 127.0.0.1:7000
slots:0-5460 (5461 slots) master
M: 058204226f52757925a606b9697a8e39756bfdff 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
M: 857075aef280cf35cd369ebc30738cd31c05e479 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
S: 7dac141fa9510315905f505be52bba0208c391ab 127.0.0.1:7003
replicates aab0162a039d2f224322afe6caf2e153230f2d82
S: 65a2bc432e5930e97f0fd172eb838af9f07229b6 127.0.0.1:7004
replicates 058204226f52757925a606b9697a8e39756bfdff
S: 3d2a665d2e2eb28acb0a187c1a0b4bbce9ce87d2 127.0.0.1:7005
replicates 857075aef280cf35cd369ebc30738cd31c05e479
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join...
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: aab0162a039d2f224322afe6caf2e153230f2d82 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
S: 3d2a665d2e2eb28acb0a187c1a0b4bbce9ce87d2 127.0.0.1:7005
slots: (0 slots) slave
replicates 857075aef280cf35cd369ebc30738cd31c05e479
S: 65a2bc432e5930e97f0fd172eb838af9f07229b6 127.0.0.1:7004
slots: (0 slots) slave
replicates 058204226f52757925a606b9697a8e39756bfdff
S: 7dac141fa9510315905f505be52bba0208c391ab 127.0.0.1:7003
slots: (0 slots) slave
replicates aab0162a039d2f224322afe6caf2e153230f2d82
M: 857075aef280cf35cd369ebc30738cd31c05e479 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
M: 058204226f52757925a606b9697a8e39756bfdff 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

创建成功,16384个Hash槽分配完成,所有节点(Master和slave节点)均已加入到集群中。三个Master节点分配的Hash槽及从节点如下:

  • Master01:127.0.0.1:7000

    M: aab0162a039d2f224322afe6caf2e153230f2d82
    slots:0-5460 (5461 slots) master
    127.0.0.1:7004 to 127.0.0.1:7000
  • Master02:127.0.0.1:7001
  • M: 058204226f52757925a606b9697a8e39756bfdff
    slots:5461-10922 (5462 slots) master
    127.0.0.1:7005 to 127.0.0.1:7001
  • Master03:127.0.0.1:7002

  • M: 857075aef280cf35cd369ebc30738cd31c05e479
    slots:10923-16383 (5461 slots) master
    127.0.0.1:7003 to 127.0.0.1:7002

2.3.3 集群测试

  • 测试集群存取值

客户端命令redis-cli连接集群需要带上”-c”, 比如redis-cli -c -p 端口号

127.0.0.1:7000> set test1 guweiyu
OK
127.0.0.1:7000> set name guweiyu
-> Redirected to slot [5798] located at 127.0.0.1:7001
OK
127.0.0.1:7001> get name
"guweiyu"
127.0.0.1:7001> get test1
-> Redirected to slot [4768] located at 127.0.0.1:7000
"guweiyu"
127.0.0.1:7000>

测试发现”set test1 guweiyu”,直接返回OK,说明该值就是存储在7000上,执行“set name guweiyu”发生了Redirected到7001上,获取的时候,同样出现上述情况。这个是Redis Cluster去中心特性,访问集群中的任一节点,均可直接操作集群。

  • 主节点宕机测试

  • 从节点宕机

上一篇:Centos 7 安装jdk 配置环境变量


下一篇:解决织梦channel标签 指定typeid或设置son时 currentstyle无效的修复办法