首先

由于不太理解当Redis Cluster发生故障转移时如何选择下一个主节点副本，因此我在阅读《实践Redis入门》时，尝试在本地运行并确认其行为。

由于我自己对许多事情仍然理解有限，所以如果有地方解释错误，请您批评指正，我将不胜感激?‍♂️

构建 Redis 集群

启动容器

可以使用docker-compose。
在conf文件中，只指定了调试命令和使用集群模式。

version: '3'

services:
  node:
    image: redis:latest
    ports:
      - 6379
    volumes:
      - $PWD/redis.conf:/usr/local/etc/redis/redis.conf
    command: redis-server /usr/local/etc/redis/redis.conf
    networks:
      - redis_network

networks:
  redis_network:

enable-debug-command yes
cluster-enabled yes

我将启动一个容器。
这次我们选择以master3、replica3的配置来启动6个容器，所以我使用了–scale选项。
我想实时监控日志，所以我选择以附加模式启动，后续的处理将在另一个终端中进行。

$ docker-compose up --scale node=6

创建Redis集群

建立 Redis Cluster。
作为前处理，将每个节点的 IP 存入变量中。

$ NODES=`docker network inspect test-redis-cluster_redis_network | jq -r '.[0].Containers | .[].IPv4Address' | sed -e 's/\/16/:6379 /g' | sed -e ':a' -e 'N' -e '$!ba' -e 's/\n//g'`

$ echo $NODES
172.27.0.7:6379 172.27.0.4:6379 172.27.0.5:6379 172.27.0.6:6379 172.27.0.2:6379 172.27.0.3:6379 

$ docker-compose exec node bash -c "redis-cli --cluster create ${NODES} --cluster-replicas 1"

从这段中可以看出，node_1（172.27.0.7）作为主节点，node_6（172.27.0.2）成为了副本。

M: b969fd526f09d3ca5d1c9d6dbc7fd2d08ed21602 172.27.0.7:6379
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
S: 8fe04f39df4e6b453a395da23f25bdc060559847 172.27.0.2:6379
   slots: (0 slots) slave
   replicates b969fd526f09d3ca5d1c9d6dbc7fd2d08ed21602

在附加状态的终端中，会输出以下类型的日志记录。

师傅与复制品的同步

有两种方法可以让复制品与主控进行同步，分别是完全同步和部分同步。

完全同步是指将主数据库的所有数据进行转储并传输，因此可以在任何时候执行，但需要注意网络带宽压力等性能方面的问题。

由于部分同步是在复制被断开的过程中仅同步增量数据，因此与完全同步相比，同步数据量较少，但如果复制回溯日志(主服务器的缓冲区)不包含副本的偏移量，那么无法进行同步(例如，在断开复制期间写入了超过回溯日志大小的数据等)。

查看附加状态的终端日志，可以看到node_6（副本）首先向node_1（主节点）发送了部分同步请求。

node_6  | 1:S 06 Sep 2023 08:39:07.163 * Before turning into a replica, using my own master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
node_6  | 1:S 06 Sep 2023 08:39:07.163 * Connecting to MASTER 172.27.0.7:6379
node_6  | 1:S 06 Sep 2023 08:39:07.163 * MASTER <-> REPLICA sync started
node_6  | 1:S 06 Sep 2023 08:39:07.163 # Cluster state changed: ok
node_6  | 1:S 06 Sep 2023 08:39:07.163 * Non blocking connect for SYNC fired the event.
node_6  | 1:S 06 Sep 2023 08:39:07.166 * Master replied to PING, replication can continue...
node_6  | 1:S 06 Sep 2023 08:39:07.166 * Trying a partial resynchronization (request 9df651b1729a067c6cb6ef216e93ac3cbd3b23a1:1).

然而，node_1（主节点）由于是全新创建的，自然在日志中不会有任何副本的偏移等内容，因此部分同步失败，将执行完全同步。

通过流RDB传输，副本172.27.0.2:6379成功(套接字)。可确定已完全同步成功(172.27.0.2是node_6的IP)。

node_1  | 1:M 06 Sep 2023 08:39:07.166 * Replica 172.27.0.2:6379 asks for synchronization
node_1  | 1:M 06 Sep 2023 08:39:07.166 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '9df651b1729a067c6cb6ef216e93ac3cbd3b23a1', my replication IDs are 'f9f16c0a4046bff27d18a0b7a78e959715e44180' and '0000000000000000000000000000000000000000')
node_1  | 1:M 06 Sep 2023 08:39:07.166 * Replication backlog created, my new replication IDs are '1d3c4b9e83fe1771fed2b03e6ce385f12ec9b614' and '0000000000000000000000000000000000000000'
node_1  | 1:M 06 Sep 2023 08:39:07.166 * Delay next BGSAVE for diskless SYNC
node_1  | 1:M 06 Sep 2023 08:39:12.042 * Starting BGSAVE for SYNC with target: replicas sockets
node_1  | 1:M 06 Sep 2023 08:39:12.045 * Background RDB transfer started by pid 27
node_1  | 27:C 06 Sep 2023 08:39:12.047 * Fork CoW for RDB: current 0 MB, peak 0 MB, average 0 MB
node_1  | 1:M 06 Sep 2023 08:39:12.047 # Diskless rdb transfer, done reading from pipe, 1 replicas still up.
node_1  | 1:M 06 Sep 2023 08:39:12.052 * Background RDB transfer terminated with success
node_1  | 1:M 06 Sep 2023 08:39:12.052 * Streamed RDB transfer with replica 172.27.0.2:6379 succeeded (socket). Waiting for REPLCONF ACK from slave to enable streaming
node_1  | 1:M 06 Sep 2023 08:39:12.052 * Synchronization with replica 172.27.0.2:6379 succeeded

检查节点的状态

确认容器的ID。

$ docker ps
CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS         PORTS                     NAMES
c95717cf74af   redis:latest   "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes   0.0.0.0:60434->6379/tcp   test-redis-cluster_node_2
c1facc6773b9   redis:latest   "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes   0.0.0.0:60432->6379/tcp   test-redis-cluster_node_4
666bb02b9458   redis:latest   "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes   0.0.0.0:60431->6379/tcp   test-redis-cluster_node_3
02897e83f47f   redis:latest   "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes   0.0.0.0:60433->6379/tcp   test-redis-cluster_node_1
dfafdb0e2309   redis:latest   "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes   0.0.0.0:60430->6379/tcp   test-redis-cluster_node_5
da59e140c108   redis:latest   "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes   0.0.0.0:60429->6379/tcp   test-redis-cluster_node_6

每个节点的状态在启动时会记录在一个名为nodes.conf的文件中，通过查看这个文件可以确认主节点和从节点的关系（也可以使用 redis-cli命令的 CLUSTER NODES等方式进行确认）。

$ docker exec 02897e83f47f bash -c "cat nodes.conf"
8fe04f39df4e6b453a395da23f25bdc060559847 172.27.0.2:6379@16379 slave b969fd526f09d3ca5d1c9d6dbc7fd2d08ed21602 0 1693989548918 1 connected
bf59ab9a08f7c39bceaaec562acfc2ca90f84621 172.27.0.6:6379@16379 slave 382223b947b401c45495a01c254e466630750c80 0 1693989547000 3 connected
cc97431d2343a3ca7a57e6d6b4da6d37bb569198 172.27.0.3:6379@16379 slave a6049751e651642f261095950d469a6b0cb8e611 0 1693989547000 2 connected
382223b947b401c45495a01c254e466630750c80 172.27.0.5:6379@16379 master - 0 1693989547908 3 connected 10923-16383
a6049751e651642f261095950d469a6b0cb8e611 172.27.0.4:6379@16379 master - 0 1693989548000 2 connected 5461-10922
b969fd526f09d3ca5d1c9d6dbc7fd2d08ed21602 172.27.0.7:6379@16379 myself,master - 0 1693989546000 1 connected 0-5460
vars currentEpoch 6 lastVoteEpoch 0

每个参数按照以下顺序排列。

我们可以看到，节点6（172.27.0.2）将节点1（172.27.0.7）作为主节点进行引用。
此外，我们还可以确认每个主节点被均匀分配了0至16383范围内的插槽。

故障转移

时代

在Redis Cluster中，使用称为epoch的值来对节点状态进行版本控制，并在共享最新信息的同时执行故障切换。
（这类似于分布式一致性算法Raft中的term的概念）
epoch有以下3种类型。

currentEpoch

クラスター全体の現在の状態を管理する
currentEpochがインクリメントされると、クラスターの状態が変化したことを表す
全てのノードがcurrentEpochに同意する必要があり、これにより一貫性を保つ

configEpoch

シャードごとに一意の数値が割り当てられる
新しい設定が適用されるとインクリメントされる
異なるノードが異なる構成を主張した際、コンフリクトを解消するために役立つ

lastVoteEpoch

レプリカから認証リクエストが来た際に用いる
マスターは自身のlastVoteEpochより古いcurrentEpochを持つレプリカからの認証リクエストは拒否する
レプリカに投票した後に更新される

将副本升级为主版本的步骤

当主处于离线状态时，我们将按照以下步骤选举出新的主节点。

副本在增加currentEpoch后，向其他主节点发送FALOVER_AUTH_REQUEST（认证请求），然后等待cluster-node-timeout * 2秒的时间进行投票。主节点收到FALOVER_AUTH_REQUEST后会检查发送源副本的currentEpoch。如果currentEpoch小于主节点的currentEpoch和lastVoteEpoch，则不接受投票。如果成功接受投票，则返回FAILOVER_AUTH_ACK（投票），并更新lastVoteEpoch为副本的currentEpoch。当副本接受多数主节点的投票后，将晋升为主节点，并将configEpoch更新为最新的currentEpoch。

在投票完成后，主节点将在 cluster-node-timeout * 2 秒的时间内不回应来自其他副本的认证请求，并且每个时期只能投票一次。因此，当与故障主节点相关联的多个副本存在时，先发送认证请求的副本将占有优势。

然而，当复制品确认主服务器进入“FAIL”状态后，不应立即发送认证请求，而是需要等待以下时间：
500毫秒 + 0~500毫秒（随机）+ 复制品等级 * 1000毫秒
各个参数的详细说明如下。

• 500ms

マスターがFAILになっているという情報がクラスター内に伝播されるのを待つための時間

0~500ms

1レプリカが同時にマスターとして選出されるのを避ける時間

REPLICA_RANK * 1000

REPLICA_RANKはレプリケーションオフセットが進んでいるレプリカ順に0から連番で振られる

简而言之，拥有最靠近主节点最新信息的偏移量（副本）能够更快地发送认证请求并且容易晋升。

停止主服务器并执行故障转移。

那么，让我们将节点1（主节点）关闭，观察故障转移的行为。

$ docker ps
CONTAINER ID   IMAGE                                 COMMAND                  CREATED         STATUS         PORTS                                                                                                                        NAMES
b7f1da8d42ff   redis:latest                          "docker-entrypoint.s…"   7 minutes ago   Up 7 minutes   0.0.0.0:55686->6379/tcp                                                                                                      test-redis-cluster_node_1
18ada60b2206   redis:latest                          "docker-entrypoint.s…"   7 minutes ago   Up 7 minutes   0.0.0.0:55687->6379/tcp                                                                                                      test-redis-cluster_node_2
...

$ docker exec -it b7f1da8d42ff bash
# redis-cli
> DEBUG SEGFAULT

我已经使节点1（主节点）下线。查看nodes.conf文件，可以确认节点1（172.27.0.7）已经变为失败状态，并且节点3（172.27.0.2）已经晋升为主节点。

$ docker exec da59e140c108 bash -c "cat nodes.conf"
b969fd526f09d3ca5d1c9d6dbc7fd2d08ed21602 172.27.0.7:6379@16379 master,fail - 1693993459028 1693993454000 1 connected
8fe04f39df4e6b453a395da23f25bdc060559847 172.27.0.2:6379@16379 myself,master - 0 1693993471000 7 connected 0-5460
bf59ab9a08f7c39bceaaec562acfc2ca90f84621 172.27.0.6:6379@16379 slave 382223b947b401c45495a01c254e466630750c80 0 1693993471116 3 connected
cc97431d2343a3ca7a57e6d6b4da6d37bb569198 172.27.0.3:6379@16379 slave a6049751e651642f261095950d469a6b0cb8e611 0 1693993470000 2 connected
382223b947b401c45495a01c254e466630750c80 172.27.0.5:6379@16379 master - 0 1693993471000 3 connected 10923-16383
a6049751e651642f261095950d469a6b0cb8e611 172.27.0.4:6379@16379 master - 0 1693993472125 2 connected 5461-10922
vars currentEpoch 7 lastVoteEpoch 0

我们停止了node_1。
node_6会在等待500毫秒 + 0~500毫秒（随机值） + REPLICA_RANK * 1000毫秒后，增加自己的currentEpoch，并将FAILOVER_AUTH_REQUEST发送给node_3和node_4。

node_3和node_4确认源复制的currentEpoch大于自己的currentEpoch和lastVoteEpoch之后，会将它们的currentEpoch更新为与源相同的值，然后向node_6发送FAILOVER_AUTH_ACK消息。

由于Node_6获得了半数以上的投票，因此它成功地将configEpoch更新为与currentEpoch相同的值，并成功晋升为主节点！

最后

使用docker-compose在本地搭建Redis Cluster，并通过图解了解了故障转移时副本的选举过程。
虽然意识到了epoch并且对Redis Cluster进行操作的机会可能很少，但如果您能感受到像这样通过这种过程晋升为主节点的感觉，那将是非常幸运的。

再见。