Redis: 集群环境搭建，集群状态检查，分析主从日志，查看集群信息

集群环境搭建

• 在 Redis 5版本以前是用 Ruby 来搭建集群，在后面的版本中仍保留了相关功能
• 可以再源码src目录中，看到 redis-trib.rb 这个东西，只是现在用这种方式搭建的少了
• 我们看新的版本是怎样搭建集群的，新版构建集群的方式简单好用
• 构建集群我们可以用6台机器，如果机器少，也可以使用3台，每台机器上有2个redis实例
• 但是，这里需要注意, 主从机器不是我们说的算，而是基于它内部的算法来确定
• 也就是说，同一台机器上，不一定是主从的关系，这个要明确
• 我们现在用这种方式，在3台机器上提供6台Redis实例的方式来搭建集群模拟
  • 每天机器上基于端口来区分，使用不同的配置文件
  • 最好的方式，还是每台机器上一个Redis，提供至少6台机器的方式
  • 但是这里没有太多资源，做模拟集群，搭建方式大同小异
  • 我们使用 redis-cli --cluster 的方式来搭建集群

1 ) 节点准备

• 在3个节点分别创建如下目录

  • $ mkdir -p /usr/local/redis/cluster/conf /usr/local/redis/cluster/data /usr/local/redis/cluster/log
  • $ vi /usr/local/redis/cluster/conf/redis-6371.conf 这个仅做演示，分别在不同节点上创建不同的配置

• 3个节点，分别创建 redis-*.conf，这个 * 替换成上面准备的端口，并添加如下通用配置信息

• 示例： vi /usr/local/redis/cluster/conf/redis-6371.conf

  # 放行访问IP限制
  bind 0.0.0.0
  # 端口
  port 6371
  # 后台启动
  daemonize yes
  # 日志存储目录及日志文件名
  logfile "/usr/local/redis/custer/log/redis-6371.log"
  # rdb数据文件名
  dbfilename dump-6371.rdb
  # aof模式开启和aof数据文件名
  appendonly yes
  appendfilename "appendonly-6371.aof"
  # rdb数据文件和aof数据文件的存储目录
  dir /usr/local/redis/cluster/data
  # 设置密码
  requirepass 123456
  # 从节点访问主节点密码（必须与 requirepass 一致）
  masterauth 123456
  # 是否开启集群模式，默认 no
  cluster-enabled yes
  # 集群节点信息文件，会保存在dir配置对应目录下
  cluster-config-file nodes-6371.conf
  # 集群节点连接超时时间
  cluster-node-timeout 15000
  # 集群节点 IP
  cluster-announce-ip 192.168.10.101
  # 集群节点映射端口
  cluster-announce-port 6371
  # 集群节点总线端口
  cluster-announce-bus-port 16371
  

• 上面为什么会有一个总线端口？

  • 每个 Redis 集群节点需要打开两个TCP的连接
  • 一个是为客户端提供服务的正常的 Redis TCP 端口, 比如这里的 6371
  • 还有一个是基于这个端口加1w产生的 16371, 这个端口是集群总线
  • 集群总线它是一个二进制协议的节点到节点通信的一个通道
  • 就是节点之间使用这个端口来进行故障检测，配置更新，故障转移授权等等

• 所以，客户端不要跟这个集群总线端口进行通信，与正常的 Redis 的TCP的这个端口通信即可

• 你现在要搭建集群，要确保防火墙里边这两个端口都是打开的

  • 或者说你把防火墙直接关了，简单粗暴
  • 否则你的这个 Redis 集群可能没有办法互相通信，就构建不了集群环境

• 注意，其他节点在修改 IP 和 端口 部分内容的时候，使用 vi 命令 %s/old/new/g 全局替换

  • 示例：$ :%s/6371/6372/g
  • 注意每个节点的 IP 不要搞错了

• 在其余节点上都进行上述快速的配置

2 ）开始构建集群

• 并在3个节点上，启动上述 6个 redis 实例
  • 示例：$ /usr/ocal/redis/bin/redis-server /usr/local/redis/cluster/conf/redis-6371.conf
  • 从 6371 ~ 6376 3个节点上redis-server全部启动
• 每个节点上，启动后，都需要检查一下：$ ps -ef | grep redis
• 创建集群的语法如下：
  • $ /usr/local/redis/bin/redis-cli --cluster create --cluster-replicas 1
    • --cluster 构建集群环境的所有 Redis 节点 IP + PORT 信息
    • --cluster-replicas 表示构建集群中主从的比例，1:1
• 在101节点上(随便找一个节点即可操作)，开始创建集群

  /usr/local/redis/bin/redis-cli -a 123456 --cluster create \
  192.168.10.101:6371 192.168.10.101:6372 \
  192.168.10.101:6373 192.168.10.101:6374 \
  192.168.10.101:6375 192.168.10.101:6376 \
  --cluster-replicas 1
  

  • 输入 yes
• 现在，一个高可用的 Redis Cluster 集群搭建完成，该集群包含 6个 Redis 节点，3主3从
• 3个节点会分配槽，处理客户端的命令请求，而从节点可用在主节点故障后，顶替主节点

检查集群状态

• 找到任意集群内的节点，执行
  • $ /usr/local/redis/bin/redis-cli -a 123456 --cluster check 192.168.10.103:6371
• 这里可以看到很多集群内的信息
  • 主节点IP和端口，存储了多少key, 槽有多少，对应备份从节点多少
  • 这里有很多信息，可以反映集群内的情况

分析主从日志

• 在这个集群中，去查看主节点和它对应的从节点即可，否则没有太多意义
• 比如现在：101:6371 是一个主节点，102:6374 是其从节点
  • $ tail -f -n 1000 /usr/local/redis/cluster/log/redis-6371.log
  • 这里面有整个集群初始化的过程
• 再来看从节点的日志, 这个要去到 102 节点上了
  • $ tail -f -n 1000 /usr/local/redis/cluster/log/redis-6374.log
  • 主要和6371.log的区别在于，变为从节点之前的准备工作
    • 连接到主节点，主从同步开始，触发SYNC非阻塞连接事件
    • 收到 Master 的 PING, 尝试增量复制被Master拒绝(因为环境初始化需要全量复制)
    • 在全量复制之前，会抛弃之前缓存的主节点的状态
    • 全量复制会：接收数据，刷新数据，加载数据到内存
    • 之后，加载RDB相关，主从复制顺利完成
    • 后台开启 aof 基于aof来继续写入数据，aof 完成
  • 这是初次构建集群中从节点的初始化日志

查看集群信息

• 随便找一个节点：$ /usr/local/redis/bin/redis-cli -c -a 123456 -h 192.168.10.103 -p 6376
  *-c 表示以集群的方式，让客户端连接

• 连接进来之后，$ CLUSTER INFO

  cluster_state:ok
  cluster_slots_assigned:16384
  cluster_slots_ok:16384
  cluster_slots_pfail:0
  cluster_slots_fail:0
  cluster_known_nodes:6
  cluster_size:3
  cluster_current_epoch:6
  cluster_my_epoch:3
  cluster_stats_messages_ping_sent:2027
  cluster_stats_messages_pong_sent:2171
  cluster_stats_messages_meet_sent:1
  cluster_stats_messages_sent:4199
  cluster_stats_messages_ping_received:2171
  cluster_stats_messages_pong_received:2028
  cluster_stats_messages_received:4199
  

  • cluster_slots_assigned 在集群中分配的总槽数
  • cluster_slots_ok 成功分配的总槽数
  • cluster_slots_pfail 可能失效的槽数
  • cluster_slots_fail 已经失效的槽数
  • cluster_known_nodes 集群环境的节点
  • cluster_size 主节点的个数/分片的个数
  • cluster_current_epoch 当前环境的节点
  • cluster_my_epoch 我的节点

• $ CLUSTER NODES

  f3353d11eae2dae1e46cdee9134beea872d1c6e8 192.168.10.103:6375@16375 master -0 1607339167170 5 connected 10923 -16383
  afe0b3936c837a46972055c7b9b691bdd8149b7d 192.168.10.101:6371@16371 master -0 1607339166164 1 connected 0-5460
  70613e4ec9d16162808accd9e5e2da0792c9ec12 192.168.10.101:6372@16372 slave f3353d11eae2dae1e46cdee9134beea872d1c6e8 0 1607339165000 5 connected
  b444cc7e6a6ee077e2d2292c68abde22977c7e5d 192.168.10.102:6374@16374 slave afe0b3936c837a46972055c7b9b691bdd8149b7d 0 1607339165000 1 connected
  d3028e6da602735c18f5917102a818daaf4f5a8a 192.168.10.103:6376@16376 myself,slave 339e0d0b6f92322fb269a83c0b43c44850e7e0aa 0 1607339163000 3 connected
  339e0d0b6f92322fb269a83c0b43c44850e7e0aa 192.168.10.102:6373@16373 master -0 1607339167000 3 connected 5461-10922
  

  • 第一个是节点ID，之后是 当前这个节点的一个IP:端口@集群总线端口
  • 再后面是 节点的角色，如果当前节点是 slave(从节点)，后面会紧跟主节点的ID
  • 再后面 -0 表示当前没有从节点连接到这个主节点，负号通常表示没有连接的从节点数量（即，这是一个主节点，且当前没有从属关系
  • 再后面是 集群最近一次向节点发送PING命令之后过了多长时间还没有收到回复
  • 再后面就是节点纪元的配置，
  • 之后是节点网络情况，如果是 master 角色那它最后是所在插槽的范围

• 上面的输出也会被存储在 /usr/local/redis/cluster/data/nodes-*.conf 中，这个是之前配置文件中指定的

  • 这里的 * 替换成自己之前配置的数字

关于纪元

• 纪元（Epoch）在Redis集群中是一个重要的概念，它用于记录集群状态变更的递增版本号
• 以下是关于Redis集群中纪元的详细解释

1 ) 纪元的定义

• 纪元是一个整数，它在Redis集群中用于标识集群状态的不同版本
• 每当集群的拓扑结构发生变化时（例如，添加或删除节点、主从切换等），纪元就会递增
• 这样，集群中的每个节点都可以通过比较纪元来确定哪个节点的集群状态信息是最新的

2 ）纪元的类型

• 在Redis集群中，主要有两种类型的纪元：
  • currentEpoch：当前纪元，表示集群当前的状态版本号。每当集群状态发生变化时，currentEpoch就会增加。集群中的每个节点都会维护一个currentEpoch，并且最终会达成一致，以确保对集群状态的认知是一致的
  • configEpoch：配置纪元，用于记录节点的配置信息（如负责的槽位）的版本号。当节点的配置发生变化时（例如，负责的槽位发生变化），configEpoch就会增加。这有助于解决节点配置冲突的问题

3 ）纪元的作用

• 确保集群状态的一致性：通过递增的纪元，集群中的节点可以确保它们对集群状态的认知是一致的。当某个节点发起状态变更时，它会增加currentEpoch，并通知其他节点。其他节点在收到通知后，会更新自己的currentEpoch，以确保与发起变更的节点保持一致

• 解决配置冲突：在Redis集群中，每个节点都有自己的configEpoch。当多个节点试图同时更新同一个槽位的配置时，它们会比较自己的configEpoch。具有更大configEpoch的节点的配置将被接受，从而解决配置冲突

• 支持故障转移：在Redis集群中，当主节点发生故障时，其从节点会尝试发起故障转移流程。在这个过程中，从节点会增加自己的currentEpoch，并向其他节点发起拉票请求。其他节点在收到请求后，会根据currentEpoch的大小来判断是否投票给该从节点。当从节点获得足够多的选票时，它就会成为新的主节点，并增加自己的configEpoch来更新槽位配置

4 ）纪元的更新机制

• 在Redis集群中，纪元的更新通常是由节点间的通信和状态变更触发的。例如，当某个节点接收到来自其他节点的状态变更通知时，它会比较通知中的纪元与自己的纪元。如果通知中的纪元更大，则更新自己的纪元。此外，在故障转移等过程中，节点也会主动增加自己的纪元来发起或响应状态变更

• 综上所述，纪元是Redis集群中用于记录集群状态变更和确保集群一致性的重要机制。通过递增的纪元版本号，集群中的节点可以确保它们对集群状态的认知是一致的，并解决可能出现的配置冲突问题