logo头像
Snippet 博客主题

了解常见的Redis集群方式

1. Redis单节点模式

Redis单节点部署架构,即Redis单机版。

1.1 优缺点对比

优点:

  • 架构简单,部署与维护方便;

  • 成本低,数据量小的情况下,性价比高

缺点:

  • 单点故障严重,数据可靠性和服务可用性无法保证;

  • 完全基于内存,强依赖于物理硬件,大数量下,性能会达到瓶颈。

  • 大数据量下,进程重启后,持久化数据恢复慢。

1.2 单节点安装

  1. 下载Redis安装程序包并解压,我这里选择目前最新的Redis 5.0.8稳定版(Stable)。

    1
    2
    3
    4
    5
    6
    [root@litong bin]# wget http://download.redis.io/releases/redis-5.0.8.tar.gz
    [root@litong bin]# tar -xzvf redis-5.0.8.tar.gz
    [root@litong bin]# ll
    总用量 1944
    drwxrwxr-x. 6 root root 4096 3月 12 23:07 redis-5.0.8
    -rw-r--r--. 1 root root 1985757 3月 12 23:08 redis-5.0.8.tar.gz
  2. 我们可以查阅解压目录里README.md文件中Building Redis完成构建安装。

    1
    2
    3
    4
    5
    [root@litong redis-5.0.8]# cd redis-5.0.8/  # 先进入到解压目录里
    [root@litong redis-5.0.8]# make # 使用make编译安装,如果命令make缺失,请安装gcc后执行make distclean
    [root@litong src]# cd src/ # 构建完成后会生成src目录
    [root@litong src]# ll | grep redis-server # redis-server就是我们最终的安装程序
    -rwxr-xr-x. 1 root root 8125016 4月 9 10:33 redis-server
  3. 复制一个单结点出来

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    [root@litong src]# make PREFIX=/usr/local/bin/redis install  # 拷贝安装到/usr/local/bin/redis一份实例
    CC Makefile.dep

    Hint: It's a good idea to run 'make test' ;)

    INSTALL install
    INSTALL install
    INSTALL install
    INSTALL install
    INSTALL install

    [root@litong src]# cd /usr/local/bin/redis/bin/ # 进入安装后可执行目录的
    [root@litong bin]# ll
    总用量 32772
    -rwxr-xr-x. 1 root root 4366824 4月 9 10:49 redis-benchmark
    -rwxr-xr-x. 1 root root 8125016 4月 9 10:49 redis-check-aof
    -rwxr-xr-x. 1 root root 8125016 4月 9 10:49 redis-check-rdb
    -rwxr-xr-x. 1 root root 4807800 4月 9 10:49 redis-cli
    lrwxrwxrwx. 1 root root 12 4月 9 10:49 redis-sentinel -> redis-server
    -rwxr-xr-x. 1 root root 8125016 4月 9 10:49 redis-server
  4. 启动测试

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    [root@litong redis-5.0.8]# cd /usr/local/bin/redis-5.0.8/utils/  #redis官方工具
    [root@litong utils]# ll | grep install_server.sh
    -rwxrwxr-x. 1 root root 9567 3月 12 23:07 install_server.sh # 执行完成交互即可安装到系统服务(开启启动、服务启动)
    [root@litong ~]# ps -ef | grep redis # 查看Redis进程
    root 3440 21316 0 10:58 pts/1 00:00:00 /usr/local/bin/redis/bin/redis-server 127.0.0.1:6379
    [root@litong bin]# ./redis-cli
    127.0.0.1:6379> ping
    PONG
    127.0.0.1:6379> set name litong
    OK

注意事项:

如果出现本地可以连接,远程连接不了,请进行如下检查设置

  1. 检查能否ping通redis服务的IP,检查网络是否可达;
  2. 关闭防火墙,确保redis端口开发;
  3. 在redis.conf文件里将bind 127.0.0.1注释掉;
  4. 将保护模式protected-mode yes改为protected-mode no(redis3.2版本以后);
  5. 加上配置文件后重启bash nohup ./redis-server redis.conf &即可.

2. Redis主从复制模式

2.1 优缺点对比

优点:

  • 一定程度上解决了单点故障问题,读性能迅速提升.

  • 全量数据主从复制,主数据库同步到从数据库,可做读写分离,Redis 2.6.x版本开始,从服务器默认状态只运行读操作.

  • Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间,客户端仍然可以提交查询或修改请求;

  • Slave Server同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,Redis则返回同步之前的数据;

缺点:

  • 多节点的全量数据副本.

  • 数据强一致性,降低了系统的可用性.

  • 很难支持在线扩容.

  • 不支持自动容错和恢复功能,需要人工干预,费时费力.

2.2 搭建1主3从的主从复制架构

  1. 启动三个4个redis实例,端口号分别为8001-8004

  2. 启动后为从节点设置主节点

    1
    2
    127.0.0.1:8001> REPLICAOF 127.0.0.1 8001 # 方式1:为后三个从节点设置主节点,需要注意的是5.0.x之前的版本SLAVEOF,5.0.x及其之后的版本用REPLICAOF命令
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$./redis-server --port 8001 --replicaof 127.0.0.1 8001 # 方式2:启动从节点通过启动命令设置主节点
  3. 查询节点角色

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    127.0.0.1:8001> ROLE # 查询当前节点的角色,2.8.12版本以后可使用,复杂度为O(1)
    1) "master" # 这是一个主节点
    2) (integer) 101 # 复制的偏移量为101
    3) 1) "127.0.0.1" # 第一个从节点的IP地址
    2) "8002" # 第一个从节点的端口号
    3) "101" # 复制的偏移量为101
    4) 1) "127.0.0.1" # 第二个从节点的IP地址
    2) "8003" # 第二个从节点的端口号
    3) "101" # 复制的偏移量为101
    5) 1) "127.0.0.1" # 第三个从节点的IP地址
    2) "8003" # 第三个从节点的端口号
    3) "101" # 复制的偏移量为101
    127.0.0.1:8002> ROLE # 查询当前节点的角色
    1) "slave" # 这是一个从节点
    2) "127.0.0.1" # 主节点IP
    3) (integer) 8001 # 主节点的端口号
    4) "connected" # 主节点在线,已连接到主节点
    5) "101" # 复制的偏移量为101
  4. 测试使用

    1
    2
    3
    4
    5
    6
    127.0.0.1:8001> set name litong # 在主服务set name
    ok
    127.0.0.1:8002> get name # 在从服务get name
    "litong"
    127.0.0.1:8003> get name # 在从服务get name
    "litong"

注意:

  • 在执行了REPLICAOF操作后,主从节点将执行数据同步操作,从服务器的数据将会被清空.注意从数据库历史数据备份.

  • 复杂度:REPLICAOF命令本身的复杂度为O(1),但它引起的异步复制操作的复杂度为O(N),其中N为主服务器包含的键值对总数量。REPLICAOF no one命令的复杂度为O(1)。

  • REPLICAOF no one, 使当前从节点停止复制,数据不会清空

2.3 主从复制同步过程原理

2.3.1 完整同步

当一个Redis服务器接收到REPLICAOF命令,开始对另一个服务器进行复制的时候,主从服务器会执行以下操作:

1)主服务器执行BGSAVE命令,生成一个RDB文件,并使用缓冲区存储起在BGSAVE命令之后执行的所有写命令。

2)当RDB文件创建完毕,主服务器会通过套接字将RDB文件传送给从服务器。

3)从服务器在接收完主服务器传送过来的RDB文件之后,就会载入这个RDB文件,从而获得主服务器在执行BGSAVE命令时的所有数据。

4)当从服务器完成RDB文件载入操作,并开始上线接受命令请求时,主服务器就会把之前存储在缓存区中的所有写命令发送给从服务器执行。

5) 如果主服务接受到从节点复制请求时已经完成一次RDB的创建,并且RDB文件之后没有发生任何改变,那么直接重用这个RDB文件给从服务器同步数据。

6) 如果有多个从服务器请求主服务同步数据,恰好此时,主服务在创建RDB文件,那么这些从服务器的同步请求全部载入队列,等RDB创建完成后,再把它发送给队列中所有的从服务器。

2.3.2 在线更新

1) 当主节点有数据写入,从节点还没同步数据的时候,主从数据也不是永久一致的。

2) 每当主服务器执行完一个写命令之后,它就会将相同的写命令或者具有相同效果的写命令发送给从服务器执行。

3) 因为完整同步之后的主从服务器在执行最新出现的写命令之前,两者的数据库是完全相同的,而导致两者数据库出现不一致的正是最新被执行的写命令,因此从服务器只要接收并执行主服务器发来的写命令,就可以让自己的数据库重新与主服务器数据库保持一致。

4) 需要注意的是在线更新是异步更新的,要求强一致性的程序只能从主节点读取数据。比如主节点在执行完写命令后向从节点发送相同的写命令,万一中间主节点出现故障,可能会导致数据不一致的情况。

2.3.3 增量同步

在Redis2.8.x版本以前,假设出现主从数据不一致的情况,它们必须通过完整复制重新同步数据,这种重新同步方法是非常浪费资源的。

在Redis2.8.x开始支持增量。当一个Redis服务器成为另一个服务器的主服务器时,它会把每个被执行的写命令都记录到一个特定长度的先进先出队列中。

● 当断线的从服务器尝试重新连接主服务器的时候,主服务器将检查从服务器断线期间,被执行的那些写命令是否仍然保存在队列里面。如果是,那么主服务器就会直接把从服务器缺失的那些写命令发送给从服务器执行,从服务器通过执行这些写命令就可以重新与主服务器保持一致,这样就避免了重新进行完整同步的麻烦。

● 如果从服务器缺失的那些写命令已经不存在于队列当中,那么主从服务器将进行一次完整同步。

● Redis为这个队列设置的默认大小为1MB,用户也可以根据自己的需要,通过配置选项repl-backlog-size来修改这个队列的大小。

2.3.4 无磁盘复制

主从复制过程中需要主节点创建RDB快照文件,当数据量越大的时候,RDB文件占用的磁盘空间越大,磁盘IO和网络IO是制约同步效率的两大因素。

从2.8.18版本开始引入无磁盘复制特性:启用了这个特性的主服务器在接收到REPLICAOF命令时将不会再在本地创建RDB文件,而是会派生出一个子进程,然后由子进程通过套接字直接将RDB文件写入从服务器。这样主服务器就可以在不创建RDB文件的情况下,完成与从服务器的数据同步。

如果我们使用无磁盘复制,我们将repl-diskless-sync改为yes即可。

需要注意的是无磁盘复制只是避免在主节点创建RDB文件,从节点仍然创建RDB文件进行恢复,该功能目前无法完全无磁盘复制.

2.3.5 主从复制设置优化

假设我们想要让主服务器只在拥有至少3个从服务器,并且这些从服务器与主服务器最后一次成功通信的间隔不超过10s的情况下才执行写命令,那么可以使用配置选项:

1
2
min-replicas-max-lag 10
min-replicas-to-write 3

2.4 主从复制故障问题

如果在主从复制架构中出现宕机的情况,需要分情况看:

2.4.1 从Redis宕机

  1. 这个相对而言比较简单,在Redis中从库重新启动后会自动加入到主从架构中,自动完成同步数据;

  2. 问题? 如果从库在断开期间,主库的变化不大,从库再次启动后,主库依然会将所有的数据做RDB操作吗?还是增量更新?(从库有做持久化的前提下)

    i.不会的,因为在Redis2.8版本后就实现了,主从断线后恢复的情况下实现增量复制。

2.4.2 主Redis宕机

  1. 这个相对而言就会复杂一些,需要以下2步才能完成

    i.第一步,在从数据库中执行SLAVEOF NO ONE命令,断开主从关系并且提升为主库继续服务;

    ii.第二步,将主库重新启动后,执行SLAVEOF命令,将其设置为其他库的从库,这时数据就能更新回来;

  2. 这个手动完成恢复的过程其实是比较麻烦的并且容易出错,有没有好办法解决呢?当前有的,Redis提供的哨兵(sentinel)的功能。

3. Redis哨兵模式

3.1 优缺点对比

优点:

  • Sentinel可以监视Redis主服务器,一旦master服务器正常或因故下线,从服务器可以自动升级为主服务器
  • 部署稍简单,故障自动转移,无需人工干预.

缺点:

  • 资源浪费,Redis 数据节点中 slave 节点作为备份节点不提供服务;
  • 不能解决读写分离问题,实现起来相对复杂。
  • 要想完全实现Redis的高可用,Sentinel必须也是高可用,即2n+1多个节点(Sentinel网格).

3.2 Sentinel搭建使用

  1. 创建sentinel.conf配置文件

    1
    sentinel monitor master_db 127.0.0.1 6379 1 # 监视127.0.0.1:6379这台名为master_db的master redis ,1表示这个服务器下线所需sentinel的数量
  2. 启动sentinel

    1
    ./redis-sentinel  ./sentinel.conf # 启动哨兵,监视主服务器,启动后日志可以看到主从节点信息
  3. 下线master,自动切换master,实现故障转移

    1
    2
    ./redis-cli -h 127.0.0.1 -p 6379  # 进入到主服务器
    127.0.0.1:8001> shutdown # 下线主服务器
  4. 稍等一会,查看其他某个从节点的服务器角色自动升级到主服务器

    1
    2
    3
    4
    5
    6
    7
    ./redis-cli -h 127.0.0.1 -p 6379  # 进入到主服务器
    127.0.0.1:6377> ROLE # 查询当前节点的角色,2.8.12版本以后可使用,复杂度为O(1)
    1) "master" # 这是一个主节点
    2) (integer) 240 # 复制的偏移量为101
    3) 1) "127.0.0.1" # 第一个从节点的IP地址
    2) "6378" # 第一个从节点的端口号
    3) "240" # 复制的偏移量为101

4. Redis Cluster模式

Redis集群是Redis 3.0版本开始正式引入的功能,它给用户带来了在线扩展Redis系统读写性能的能力,而Redis 5.0更是在集群原有功能的基础上,进一步添加了更多新功能,并且对原有功能做了相当多的优化,使得整个集群系统更简单、易用和高效。

4.1 优缺点对比

优点:

  • 无中心架构;
  • 数据按slot插槽动态分散存储,解决主从模式全量数据复制的问题,可扩展性强;
  • 可以做到不停服,可动态添加或删除节点;

  • 部分节点不可用时,集群仍可用,高可用性大大提高;

  • 集群本身丰富的工具和命令,运维成本低。

缺点:

  • 主节点与从节点的数据通过异步复制,不保证数据强一致性,在极端情况(主节点长时间挂、网络分区)下,很有可能丢失正在写入数据。

  • 没有大量的生产实践,出了问题无法从根本入手。

4.2 基本特性

4.2.1 复制与高可用

Redis Cluster与单机版Redis服务器一样,也提供了主从复制功能。

在Redis Cluster中,其中主节点(master node)负责处理客户端发送的读写命令请求,而从节点(replica/slave node)

则负责对主节点进行复制。

除了复制功能之外,Redis Cluster还提供了类似于单机版Redis Sentinel的功能,以此来为集群提供高可用特性。简单来说,集群中的各个节点将互相监视各自的运行状况,并在某个主节点下线时,通过提升该节点的从节点为新主节点来继续提供服务。

4.2.2 分片与重分片

Redis Cluster通过将数据库分散存储到多个节点上来平衡各个节点的负载压力。

Redis Cluster会将整个数据库空间划分为16384个槽(slot)来实现数据分片,而集群中的各个主节点则会分别负责处理其中的一部分槽。

当用户尝试将一个键存储到集群中时,客户端会先计算出键所属的槽,接着在记录集群节点槽分布的映射表中找出处理该槽的节点,最后再将键存储到相应的节点中

当用户想要向集群添加新节点时,只需要向Redis Cluster发送几条简单的命令,集群就会将相应的槽以及槽中存储的数据迁移至新节点。

与此类似,当用户想要从集群中移除已存在的节点时,被移除的节点也会将自己负责处理的槽以及槽中数据转交给集群中的其他节点负责。

最重要的是,无论是向集群添加新节点还是从集群中移除已有节点,整个重分片(reshard)过程都可以在线进行,Redis Cluster无须因此而停机

4.2.3 高性能

Redis Cluster采用无代理模式,客户端发送的所有命令都会直接交由节点执行。

对于经过优化的集群客户端来说,客户端发送的命令在绝大部分情况下都不需要实施转向,或者仅需要一次转向,因此在Redis Cluster中执行命令的性能(不考虑节点之间互通信息带来的性能损耗之外)与在单机Redis服务器上执行命令的性能非常接近。

从理论上来讲,集群每增加一倍数量的主节点,集群对于命令请求的处理性能就会提高一倍。

4.3 Redis Cluster架构

  1. 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.
  2. 节点的fail是通过集群中超过半数的节点检测失效时才生效.
  3. 客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
  4. redis-cluster把所有的物理节点映射到[0-16383]slot(插槽)上,cluster 负责维护node<->slot<->value

4.4 手动搭建Redis Cluster

  1. 创建集群目录和节点目录

    1
    2
    3
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ mkdir redis-cluster #  创建集群根目录
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ cd redis-cluster/ #
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ mkdir node1 node2 node3 node4 node5 node6 # 创建6个(3主3从)节点目录
  2. 为每个节点创建redis.conf配置文件,并为每个节点设置配置,端口设置为7001-7006

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    # 节点端口号
    port 7001
    # 是否启用集群
    cluster-enabled yes
    # 集群节点的超时时间
    cluster-node-timeout 5000
    # 开启AOF持久化
    appendonly yes
    # 保存数据的AOF文件名称
    appendfilename "appendonly.aof"
    # Redis后台运行
    daemonize yes
    # 日志存放路径
    logfile "./node1.log"
  3. 复制redis-server和redis-cli可执行文件到redis-cluster目录

    1
    2
    3
    4
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ cp /media/litong/软件/programs/tools/redis/redis-5.0.8/src/redis-server ./
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ cp /media/litong/软件/programs/tools/redis/redis-5.0.8/src/redis-cli ./
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ls
    node1 node2 node3 node4 node5 node6 redis-server redis-cli
  4. 启动6个redis实例,这里以第一个节点启动,其他节点类似启动

    1
    2
    3
    4
    5
    6
    7
    8
    9
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ cd node1
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ../redis-server ./redis.conf
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster/node6$ ps -ef | grep redis
    litong 4748 1 0 19:36 ? 00:00:00 ../redis-server *:7001 [cluster]
    litong 8987 1 0 19:37 ? 00:00:00 ../redis-server *:7002 [cluster]
    litong 10563 1 0 19:38 ? 00:00:00 ../redis-server *:7003 [cluster]
    litong 11696 1 0 19:38 ? 00:00:00 ../redis-server *:7004 [cluster]
    litong 15806 1 0 19:39 ? 00:00:00 ../redis-server *:7005 [cluster]
    litong 16959 1 0 19:39 ? 00:00:00 ../redis-server *:7006 [cluster]
  5. 为当前6个实例创建集群,并分配槽

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ./redis-cli --cluster create 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 127.0.0.1:7006 --cluster-replicas 1
    >>> Performing hash slots allocation on 6 nodes...
    Master[0] -> Slots 0 - 5460
    Master[1] -> Slots 5461 - 10922
    Master[2] -> Slots 10923 - 16383
    Adding replica 127.0.0.1:7005 to 127.0.0.1:7001
    Adding replica 127.0.0.1:7006 to 127.0.0.1:7002
    Adding replica 127.0.0.1:7004 to 127.0.0.1:7003
    >>> Trying to optimize slaves allocation for anti-affinity
    [WARNING] Some slaves are in the same host as their master
    M: dd6a5286d3f8a739c486b6c4f6adc42ac59564c1 127.0.0.1:7001
    slots:[0-5460] (5461 slots) master
    M: dc915340a56265b785a0aa60b1d4a8def8bdf294 127.0.0.1:7002
    slots:[5461-10922] (5462 slots) master
    M: 2cb729c0b5401be36c370d7d62de8fa2db1a3638 127.0.0.1:7003
    slots:[10923-16383] (5461 slots) master
    S: 17379fe77de821b38e3ba18ce6c86d81e60dda7f 127.0.0.1:7004
    replicates dc915340a56265b785a0aa60b1d4a8def8bdf294
    S: 18b35efcfc2741a8c6fa120464b19f5e78cbaf74 127.0.0.1:7005
    replicates 2cb729c0b5401be36c370d7d62de8fa2db1a3638
    S: 04cfbd2b01cd304281b1ef2d120b112b55b67d51 127.0.0.1:7006
    replicates dd6a5286d3f8a739c486b6c4f6adc42ac59564c1
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    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:7001)
    M: dd6a5286d3f8a739c486b6c4f6adc42ac59564c1 127.0.0.1:7001
    slots:[0-5460] (5461 slots) master
    1 additional replica(s)
    S: 17379fe77de821b38e3ba18ce6c86d81e60dda7f 127.0.0.1:7004
    slots: (0 slots) slave
    replicates dc915340a56265b785a0aa60b1d4a8def8bdf294
    S: 04cfbd2b01cd304281b1ef2d120b112b55b67d51 127.0.0.1:7006
    slots: (0 slots) slave
    replicates dd6a5286d3f8a739c486b6c4f6adc42ac59564c1
    M: dc915340a56265b785a0aa60b1d4a8def8bdf294 127.0.0.1:7002
    slots:[5461-10922] (5462 slots) master
    1 additional replica(s)
    S: 18b35efcfc2741a8c6fa120464b19f5e78cbaf74 127.0.0.1:7005
    slots: (0 slots) slave
    replicates 2cb729c0b5401be36c370d7d62de8fa2db1a3638
    M: 2cb729c0b5401be36c370d7d62de8fa2db1a3638 127.0.0.1:7003
    slots:[10923-16383] (5461 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
  6. 查询集群状态以及集群节点信息

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ./redis-cli -p 7001
    127.0.0.1:7001> info replication
    # Replication
    role:master
    connected_slaves:1
    slave0:ip=127.0.0.1,port=7006,state=online,offset=448,lag=0
    master_replid:315becdb2f224589cad3ab226c9101f1780ec071
    master_replid2:0000000000000000000000000000000000000000
    master_repl_offset:448
    second_repl_offset:-1
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:1
    repl_backlog_histlen:448
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ./redis-cli -h 127.0.0.1 -p 7001 cluster nodes
    17379fe77de821b38e3ba18ce6c86d81e60dda7f 127.0.0.1:7004@17004 slave dc915340a56265b785a0aa60b1d4a8def8bdf294 0 1586606499545 4 connected
    dd6a5286d3f8a739c486b6c4f6adc42ac59564c1 127.0.0.1:7001@17001 myself,master - 0 1586606499000 1 connected 0-5460
    04cfbd2b01cd304281b1ef2d120b112b55b67d51 127.0.0.1:7006@17006 slave dd6a5286d3f8a739c486b6c4f6adc42ac59564c1 0 1586606499645 6 connected
    dc915340a56265b785a0aa60b1d4a8def8bdf294 127.0.0.1:7002@17002 master - 0 1586606499545 2 connected 5461-10922
    18b35efcfc2741a8c6fa120464b19f5e78cbaf74 127.0.0.1:7005@17005 slave 2cb729c0b5401be36c370d7d62de8fa2db1a3638 0 1586606500647 5 connected
    2cb729c0b5401be36c370d7d62de8fa2db1a3638 127.0.0.1:7003@17003 master - 0 1586606499000 3 connected 10923-16383
  7. 关闭集群,可整理为shell脚本

    1
    2
    3
    4
    5
    6
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ./redis-cli -c -p 7001 shutdown
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ./redis-cli -c -p 7002 shutdown
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ./redis-cli -c -p 7003 shutdown
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ./redis-cli -c -p 7004 shutdown
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ./redis-cli -c -p 7005 shutdown
    litong@LT:/media/litong/软件/programs/tools/redis/redis-cluster$ ./redis-cli -c -p 7006 shutdown

4.5 集群故障机制

  1. 集群中的每个节点都会定期的向其它节点发送PING命令,并且通过有没有收到回复判断目标节点是否下线;

  2. 集群中每一秒就会随机选择5个节点,然后选择其中最久没有响应的节点放PING命令;

  3. 如果一定时间内目标节点都没有响应,那么该节点就认为目标节点疑似下线;

  4. 当集群中的节点超过半数认为该目标节点疑似下线,那么该节点就会被标记为下线;

  5. 当集群中的任何一个节点下线,就会导致插槽区有空档,不完整,那么该集群将不可用;

  6. 如何解决上述问题?
    6.1 在Redis集群中可以使用主从模式实现某一个节点的高可用

    6.2 当该节点(master)宕机后,集群会将该节点的从数据库(slave)转变为(master)继续完成集群服务;

5. 自研Redis代理中间件

5.1 Codis代理中间件

5.1.2 Codis简介

Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务.

Codis 由四部分组成:

  • Codis Proxy (codis-proxy)
  • Codis Manager (codis-config)
  • Codis Redis (codis-server)
  • ZooKeeper

codis-proxy 是客户端连接的 Redis 代理服务, codis-proxy 本身实现了 Redis 协议, 表现得和一个原生的 Redis 没什么区别 (就像 Twemproxy), 对于一个业务来说, 可以部署多个 codis-proxy, codis-proxy 本身是无状态的.

codis-config 是 Codis 的管理工具, 支持包括, 添加/删除 Redis 节点, 添加/删除 Proxy 节点, 发起数据迁移等操作. codis-config 本身还自带了一个 http server, 会启动一个 dashboard, 用户可以直接在浏览器上观察 Codis 集群的运行状态.

codis-server 是 Codis 项目维护的一个 Redis 分支, 基于 2.8.13 开发, 加入了 slot 的支持和原子的数据迁移指令. Codis 上层的 codis-proxy 和 codis-config 只能和这个版本的 Redis 交互才能正常运行.

Codis 依赖 ZooKeeper 来存放数据路由表和 codis-proxy 节点的元信息, codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy.

Codis 支持按照 Namespace 区分不同的产品, 拥有不同的 product name 的产品, 各项配置都不会冲突.

目前 Codis 已经是稳定阶段,目前豌豆荚已经在使用该系统。

5.1.2 优缺点对比

优点:

  • 自动平衡
  • 使用非常简单
  • 图形化的面板和管理工具
  • 支持绝大多数 Redis 命令,完全兼容 twemproxy
  • 支持 Redis 原生客户端
  • 安全而且透明的数据移植,可根据需要轻松添加和删除节点
  • 提供命令行接口
  • RESTful APIs

缺点:

  • 增加一层代理,网络开销大
  • 瓶颈在于这层代理层,一挂全挂
  • 自研产品维护成本高

6. 相关文档

支付宝打赏 微信打赏

请作者喝杯咖啡吧