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

淩亂°似流年 2022-06-01 11:41 151阅读 0赞

在之前的博客《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问题的（分区），两种不重复，可以混合使用。

*  Sharding机制：[http://blog.csdn.net/basycia/article/details/52013098][http_blog.csdn.net_basycia_article_details_52013098]
 *  HA机制：[https://baike.baidu.com/item/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7(HA)/2355576][https_baike.baidu.com_item_E9_AB_98_E5_8F_AF_E7_94_A8_E6_80_A7_HA_2355576]

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

## 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集群架构图 ####

![这里写图片描述][SouthEast]

#### 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节点详情展示  
    ![这里写图片描述][SouthEast 1]
 *  Redis Slave节点效果截图展示  
    ![这里写图片描述][SouthEast 2]
 *  各个Sentinel节点详情展示  
    ![这里写图片描述][SouthEast 3]

#### 1.5 高可用性场景测试 ####

*  Master宕机  
    ![这里写图片描述][SouthEast 4]  
    sentinel使用failover机制重新选举出master
 *  Master恢复  
    ![这里写图片描述][SouthEast 5]  
    master节点恢复后，由Master变成slave
 *  Slave宕机  
    ![这里写图片描述][SouthEast 6]  
    哨兵发现6399已经宕机，等待6399的恢复(主观下线)
 *  Slave重启6399节点  
    ![这里写图片描述][SouthEast 7]  
    如果想详细了解sentinel机制的话，可以参考博客：  
    [http://shift-alt-ctrl.iteye.com/blog/1884370][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集群准备 ####

*  集群部署图  
    ![这里写图片描述][SouthEast 8]
 *  集群由三个节点组成，每个节点均为主从式架构。因而共需要创建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节点已全部停止"
 *  创建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去中心特性，访问集群中的任一节点，均可直接操作集群。

*  主节点宕机测试
 *  从节点宕机
 *  \*

[http_blog.csdn.net_basycia_article_details_52013098]: http://blog.csdn.net/basycia/article/details/52013098
[https_baike.baidu.com_item_E9_AB_98_E5_8F_AF_E7_94_A8_E6_80_A7_HA_2355576]: https://baike.baidu.com/item/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7%28HA%29/2355576
[SouthEast]: /images/20220601/3f391bf42b8b4be08862bd106422dcb1.png
[SouthEast 1]: /images/20220601/3f3a2f75c1834b2fa57893d220d6dd5f.png
[SouthEast 2]: /images/20220601/30518e93602945dd8c782c890da375b5.png
[SouthEast 3]: /images/20220601/d2ad4e97813d432ebbca0da8d4adefe5.png
[SouthEast 4]: /images/20220601/12a155592b21419c975d221ccf095fff.png
[SouthEast 5]: /images/20220601/1b784634676645b5a0b32d82040ce662.png
[SouthEast 6]: /images/20220601/27a04084902d4e52918f3b3aee2967e7.png
[SouthEast 7]: /images/20220601/4e0f2a7e6625443c9eb5d06aab83e5cb.png
[http_shift-alt-ctrl.iteye.com_blog_1884370]: http://shift-alt-ctrl.iteye.com/blog/1884370
[SouthEast 8]: /images/20220601/47d9024ea40c43bda032f8dd7b950ea6.png