consensus-algorithms

Understand and apply distributed consensus algorithms for leader election, distributed locks, and consistent state. Outputs algorithm selection guide, Raft/Paxos explanation, implementation patterns, and failure scenario analysis.

インストールへ移動

リポジトリ: kalilurrahman/kr-claudiator-skills
ソースの最終更新活動: 2026年3月29日 13:04
検出された SKILL.md の言語: 英語
スター: 1
フォーク: 0

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。

npx skills add https://github.com/kalilurrahman/kr-claudiator-skills --skill consensus-algorithms

コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。

ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md

ソースの指示 · 読み取り専用プレビュー

検索に戻るインストールに戻る

Consensus Algorithms

Consensus algorithms allow distributed nodes to agree on a single value even when some nodes fail. They underpin leader election, distributed locks, configuration management, and any system requiring strong consistency across replicas. Understanding consensus is essential for understanding Kubernetes, etcd, ZooKeeper, and Kafka.

The Consensus Problem

CHALLENGE: N nodes must agree on a value Any node can fail (crash or network partition) No shared memory; only message passing SAFETY requirements (what must never happen): Only a single value is decided A decided value was proposed by some node LIVENESS requirement (what must eventually happen): Some value is eventually decided (Not guaranteed during partition — see CAP theorem) CAP Theorem: Consistency (linearisability) + Availability + Partition Tolerance Choose 2. Consensus algorithms choose CP — consistency over availability.

Raft (Most Understandable)

RAFT ROLES: Leader: Receives writes; replicates to followers Follower: Passively replicate from leader Candidate: Seeking election; in between leader terms LEADER ELECTION: 1. All nodes start as followers with random election timeout (150-300ms) 2. If no heartbeat received before timeout → become Candidate 3. Increment term; vote for self; request votes from peers 4. Win majority → become Leader for this term 5. Send heartbeats to prevent new elections LOG REPLICATION: 1. Leader receives write; appends to its log 2. Leader sends AppendEntries to all followers 3. Followers append to their log; acknowledge 4. When majority acknowledge → entry is committed 5. Leader notifies followers of commit; they apply to state machine KEY PROPERTIES: - Leader has all committed entries (election guarantee) - Committed entries never overwritten - At most one leader per term

Consensus Algorithms

The Consensus Problem

Raft (Most Understandable)

import etcd3 import time import threading # etcd uses Raft internally; provides distributed KV with watches class DistributedLock: """Leader election / mutual exclusion using etcd leases.""" def __init__(self, etcd_endpoints: list[str], lock_name: str, ttl: int = 30): self.client = etcd3.client(host=etcd_endpoints[0].split(":")[0], port=int(etcd_endpoints[0].split(":")[1])) self.lock_name = f"/locks/{lock_name}" self.ttl = ttl self._lease = None self._acquired = False self._keepalive_thread = None def acquire(self, timeout: float = None) -> bool: """Try to acquire the lock. Returns True if acquired.""" deadline = time.time() + timeout if timeout else None while True: # Create a lease (auto-expires if we crash) self._lease = self.client.lease(self.ttl) lease_id = self._lease.id # Try to atomically create the lock key with our lease success, _ = self.client.transaction( compare=[self.client.transactions.version(self.lock_name) == 0], success=[self.client.transactions.put(self.lock_name, "locked", lease=self._lease)], failure=[], ) if success: self._acquired = True # Keep lease alive self._keepalive_thread = threading.Thread( target=self._keepalive, daemon=True ) self._keepalive_thread.start() return True if deadline and time.time() >= deadline: self._lease.revoke() return False time.sleep(0.1) def _keepalive(self): """Refresh lease to prevent expiry while we hold the lock.""" for _ in self.client.refresh_lease(self._lease): if not self._acquired: break def release(self): """Release the lock by revoking the lease.""" self._acquired = False if self._lease: self._lease.revoke() def __enter__(self): if not self.acquire(timeout=10): raise TimeoutError("Could not acquire distributed lock") return self def __exit__(self, *args): self.release() # Usage with DistributedLock(["etcd:2379"], "payment-processor", ttl=30) as lock: # Only one instance runs this at a time process_pending_payments()

name	consensus-algorithms
description	Understand and apply distributed consensus algorithms for leader election, distributed locks, and consistent state. Outputs algorithm selection guide, Raft/Paxos explanation, implementation patterns, and failure scenario analysis.
argument-hint	["cluster size","consistency requirements","network characteristics","failure tolerance"]
allowed-tools	Read, Write

name	consensus-algorithms
description	Understand and apply distributed consensus algorithms for leader election, distributed locks, and consistent state. Outputs algorithm selection guide, Raft/Paxos explanation, implementation patterns, and failure scenario analysis.
argument-hint	["cluster size","consistency requirements","network characteristics","failure tolerance"]
allowed-tools	Read, Write

Algorithm	Understandability	Performance	Flexibility	Use Case
Raft	High	Good	Moderate	etcd, CockroachDB, TiDB
Paxos	Low	Good	High	Google Chubby, Spanner
Zab (ZooKeeper)	Medium	Good	Low	Kafka, Hadoop coordination
PBFT	Very Low	Poor	High	Byzantine fault tolerance
Viewstamped Replication	Medium	Good	Moderate	Research, some databases

Anti-Pattern	Problem	Fix
Using consensus for high-throughput writes	Consensus adds latency; not for every write	Consensus for coordination; eventual consistency for data
Single etcd/ZooKeeper node	Defeats the purpose — no fault tolerance	Minimum 3 nodes (tolerates 1 failure); 5 for 2-failure tolerance
Ignoring network partitions	Leader may not know it lost leadership	Lease-based approach; leader steps down if lease expires
Rolling your own consensus	Extremely hard to get right	Use etcd, ZooKeeper, or Consul
Consensus for everything	Over-engineered; slow	Consensus only for coordination; not for all state

consensus-algorithms

インストール方法

ソースファイルを確認