Gossip ،تشخیص خرابی و Paxos

یک خوشه ۱۰۰۰نودی چطور می‌فهمد چه کسی زنده است، بدون اینکه یک «رئیس مرکزی» همه را پینگ کند؟ و قبل از Raft، پدربزرگ اجماع — Paxos — چطور کار می‌کرد؟ این درس دو تکه گمشده پازل فصل ۹ است.

Gossip: خبرسازی اپیدمیک

• هر نود هر ~۱ ثانیه با چند نود تصادفی حرف می‌زند و دفترچه وضعیت (heartbeat + incarnation number هر نود) را رد و بدل می‌کند — خبر در O(log n) دور به همه می‌رسد.
• مقیاس‌پذیر و بدون نقطه مرکزی: Cassandra برای عضویت و metadata، Redis Cluster برای توپولوژی، Consul/Serf برای سرویس‌ها از همین مدل استفاده می‌کنند.
• Gossip در نهایت همگراست (eventual): برای چند ثانیه ممکن است دو نود نظر متفاوت درباره زنده‌بودن یک نود داشته باشند — برای تصمیم حیاتی (فنسینگ) به آن تکیه نکن.

تشخیص خرابی: timeout ثابت ممنوع

Paxos در پنج دقیقه

• نقش‌ها: Proposer (پیشنهاددهنده مقدار)، Acceptor (رأی‌دهنده)، Learner (یادگیرنده نتیجه).
• فاز Prepare: پیشنهاددهنده با شماره n از اکثریت قول می‌گیرد «به شماره کوچک‌تر رأی نده» و آخرین مقدار پذیرفته‌شده را می‌شنود.
• فاز Accept: مقدار (خودش یا آخرین پذیرفته‌شده) را با همان n می‌فرستد؛ اکثریت که پذیرفتند، مقدار chosen است.
• Basic-Paxos برای یک مقدار است؛ برای لاگِ دنباله‌دار به Multi-Paxos (با leader پایدار) نیاز داری — و دقیقاً همین پیچیدگیِ فهم و پیاده‌سازی بود که Raft را به وجود آورد: Raft همان اجماع است، اما به‌گونه‌ای نوشته شده که آدم‌ها بتوانند درست پیاده‌اش کنند.

به زبان ساده

Gossip یعنی خبرها مثل شایعه دهان‌به‌دهان بین گره‌ها می‌چرخد تا همه بفهمند کی زنده است؛ و Paxos قدیمی‌ترین راه اثبات‌شده توافق است که Raft آن را خوانا کرد.

مثال واقعی

در باشگاه، خبر مرخصی فلانی را هرکس به چند نفر می‌گوید و طی چند دقیقه همه می‌دانند — بدون اطلاعیه رسمی؛ دیتابیس Cassandra همین‌طور سلامت اعضا را پخش می‌کند.