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

时间：2022-12-28 22:20:54

在之前的博客《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去中心特性，访问集群中的任一节点，均可直接操作集群。

  • 主节点宕机测试

  • 从节点宕机

相关文章