Redis Caching & Messaging (Pub/Sub, Streams) · レッスン

リーダー選出パターン

高可用性を実現する分散サービスで、Redis をリーダー選出に活用する方法を学びます。

「リーダー選出パターン」はCoddyKit上の無料Redis Caching & Messaging (Pub/Sub, Streams)レッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応の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.

よくある質問

「リーダー選出パターン」レッスンは無料ですか？

はい。「リーダー選出パターン」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Redis Caching & Messaging (Pub/Sub, Streams)コースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Redis Caching & Messaging (Pub/Sub, Streams)コースには全4レッスンが含まれています。

「リーダー選出パターン」で何を学びますか？

高可用性を実現する分散サービスで、Redis をリーダー選出に活用する方法を学びます。ブラウザで直接実行するハンズオンコードでRedis Caching & Messaging (Pub/Sub, Streams)を演習し、24時間対応の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)に戻る