Redis Caching & Messaging (Pub/Sub, Streams) · 课时

领导者选举模式

探索如何使用 Redis 在分布式服务中实现领导者选举，以实现高可用

领导者选举模式 是 CoddyKit 上的免费 Redis Caching & Messaging (Pub/Sub, Streams) 课时。这是第 2 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Redis Caching & Messaging (Pub/Sub, Streams) 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Redis Caching & Messaging (Pub/Sub, Streams) 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Why Leader Election?

In a distributed system, multiple instances of your application run simultaneously. Sometimes, you need one instance to perform a specific task, like processing a queue or coordinating updates, to avoid conflicts or duplicate work.

This is where leader election comes in. It's a process where distributed nodes agree on a single node to be the "leader" at any given time.

Redis for Election Coordination

Redis is an excellent choice for implementing leader election due to its speed, atomic operations, and strong consistency guarantees for single-key operations.

Atomic Operations: Commands like SETNX or SET ... NX EX execute entirely or not at all, preventing race conditions.
Persistence: If configured, Redis can persist data, making leader election state more durable.
Centralized State: Provides a single, agreed-upon source of truth for who the current leader is.

Basic Election: SETNX

The simplest way to attempt leader election with Redis is using the SETNX command. SETNX key value ("Set if Not eXists") sets a key only if it doesn't already exist. If the key is set, it returns 1; otherwise, 0.

The first process to successfully set the leader key becomes the leader.

import redis
import time

# Connect to Redis
r = redis.Redis(decode_responses=True)

LEADER_KEY = "my_app:leader_v1"
MY_ID = "process_A" # Unique ID for this process

print(f"Process {MY_ID} attempting to become leader...")

# Try to acquire leadership
if r.setnx(LEADER_KEY, MY_ID):
    print(f"Process {MY_ID} is now the leader!")
    # Simulate leader work
    time.sleep(3) # Work for 3 seconds
    # In a real scenario, the leader would perform tasks
    # and eventually release leadership or renew its lease.
    r.delete(LEADER_KEY) # Release leadership
    print(f"Process {MY_ID} released leadership.")
el:
    current_leader = r.get(LEADER_KEY)
    print(f"Process {MY_ID}: Another process ({current_leader}) is already the leader.")

The Problem: Leader Failure

Consider the basic SETNX approach. What if the elected leader (process_A from the last example) crashes immediately after setting the LEADER_KEY, but before it has a chance to delete it?

The LEADER_KEY would remain in Redis indefinitely, preventing any other process from becoming leader. This creates a permanent deadlock, breaking your distributed system's high availability.

TTL for Fault Tolerance

To prevent deadlocks, we must add an expiration time (Time-To-Live, or TTL) to the leader key. This ensures that even if a leader crashes, its leadership key will eventually expire, allowing a new election.

We can use the EXPIRE key seconds command right after SETNX to set a TTL.

import redis
import time

r = redis.Redis(decode_responses=True)

LEADER_KEY = "my_app:leader_v2"
MY_ID = "process_B"
LOCK_TTL = 10 # seconds

print(f"Process {MY_ID} attempting to become leader...")

if r.setnx(LEADER_KEY, MY_ID):
    r.expire(LEADER_KEY, LOCK_TTL) # Set expiration
    print(f"Process {MY_ID} is now the leader with TTL {LOCK_TTL}s!")
    # Simulate leader work for a short period
    time.sleep(LOCK_TTL // 2)
    print(f"Process {MY_ID} completed its short task.")
    if r.get(LEADER_KEY) == MY_ID: # Check if still leader before deleting
        r.delete(LEADER_KEY)
        print(f"Process {MY_ID} released leadership.")
    else:
        print(f"Process {MY_ID}: Leadership lost or expired already.")
el:
    current_leader = r.get(LEADER_KEY)
    print(f"Process {MY_ID}: Another process ({current_leader}) is already the leader.")

The SETNX + EXPIRE Race

While adding EXPIRE is better, a critical race condition still exists! Imagine this sequence:

Process A calls SETNX LEADER_KEY process_A. It succeeds (returns 1).
Process A then crashes before it can call EXPIRE LEADER_KEY 10.

The LEADER_KEY is set, but without a TTL, leading to the same deadlock situation as before. We need an atomic way to set the key and its expiration.

Atomic SET for Robustness

Redis provides a powerful, atomic SET command that combines setting a key's value and its expiration. The format is SET key value [EX seconds | PX milliseconds] [NX | XX].

NX: Only set the key if it does not already exist (like SETNX).
EX seconds: Set an expiration time in seconds.
PX milliseconds: Set an expiration time in milliseconds.

Using SET LEADER_KEY MY_ID NX EX 10 ensures that both conditions (key not existing AND expiration) are applied atomically.

import redis
import time

r = redis.Redis(decode_responses=True)

LEADER_KEY = "my_app:leader_v3"
MY_ID = "process_C"
LOCK_TTL = 10 # seconds

print(f"Process {MY_ID} attempting to become leader atomically...")

# Try to acquire leadership using atomic SET with NX and EX
# This command returns True if the key was set, False otherwise.
if r.set(LEADER_KEY, MY_ID, nx=True, ex=LOCK_TTL):
    print(f"Process {MY_ID} is now the leader with atomic TTL {LOCK_TTL}s!")
    # Simulate leader work
    time.sleep(LOCK_TTL // 2)
    print(f"Process {MY_ID} still working as leader.")
    if r.get(LEADER_KEY) == MY_ID: # Important: check value before deleting!
        r.delete(LEADER_KEY)
        print(f"Process {MY_ID} gracefully released leadership.")
    else:
        print(f"Process {MY_ID}: Leadership lost or expired already.")
el:
    current_leader = r.get(LEADER_KEY)
    print(f"Process {MY_ID}: Another process ({current_leader}) is already the leader.")

Maintaining Leadership: Heartbeats

Once a leader is elected using the atomic SET command, it needs to periodically signal that it's still alive and capable of leading. This is done through "heartbeats."

A heartbeat involves the leader refreshing the expiration time of its leadership key before it expires (e.g., using EXPIRE LEADER_KEY NEW_TTL or PEXPIRE). If the leader fails to send heartbeats, its key will expire, triggering a new election among the remaining processes.

Check Your Understanding

Which of the following are benefits of using the atomic SET key value NX EX seconds command for leader election compared to separate SETNX and EXPIRE commands?

Recap: Leader Election

We've explored how Redis can facilitate leader election in distributed systems. We started with basic SETNX, identified its pitfalls, and learned to improve it with EXPIRE.

Crucially, we discovered the robust and atomic SET key value NX EX seconds command to prevent race conditions and ensure keys always have an expiration. Finally, we touched upon the importance of leader heartbeats to maintain active leadership.

常见问题解答

「领导者选举模式」课时是免费的吗？

是的 — 「领导者选举模式」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Redis Caching & Messaging (Pub/Sub, Streams) 课程的其余内容，请升级到 CoddyKit PRO。 Redis Caching & Messaging (Pub/Sub, Streams) 课程共包含 4 节课。

「领导者选举模式」这节课中我会学到什么？

探索如何使用 Redis 在分布式服务中实现领导者选举，以实现高可用你通过在浏览器中直接运行的动手代码来练习 Redis Caching & Messaging (Pub/Sub, Streams)，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Redis Caching & Messaging (Pub/Sub, Streams) 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Redis Caching & Messaging (Pub/Sub, Streams) 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 2 节课，共 4 节。

「领导者选举模式」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Redis Caching & Messaging (Pub/Sub, Streams) 课中编写并运行代码吗？

能。每节 Redis Caching & Messaging (Pub/Sub, Streams) 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Redis Caching & Messaging (Pub/Sub, Streams)