اجماع، Leader Election و Fencing — طراحی سیستم نرم‌افزاری

کپی‌داشتن از داده کافی نیست؛ سرورها باید روی یک موضوع مهم هم توافق کنند: «الان کدام سرور حق تصمیم‌گرفتن و نوشتن دارد؟» اجماع (Consensus) راهی است که چند سرور، حتی وقتی بعضی‌هایشان قطع یا کند شده‌اند، یک جواب مشترک داشته باشند.

مدل شکست و Raft

Crash fault

node خاموش یا بی‌پاسخ می‌شود؛ Raft و Paxos معمولاً این مدل را حل می‌کنند، نه رفتار مخرب Byzantine.

Quorum

اکثریتِ nodeها؛ با N=3 حداقل 2 و با N=5 حداقل 3 رأی لازم است. دو quorum اکثریت حتماً اشتراک دارند.

Raft log

Leader فرمان را به لاگ append می‌کند، پس از تأیید اکثریت commit می‌شود و سپس به state machine اعمال می‌گردد.

Term

دوره رهبری یکنواخت؛ پیام term قدیمی کنار گذاشته می‌شود تا leader قبلی نتواند دوباره بنویسد.

در Raft سه نقش داریم: follower یعنی سروری که دنبال رهبر می‌رود؛ candidate یعنی سروری که برای رهبرشدن درخواست رأی داده؛ و leader یعنی سرور تصمیم‌گیرنده. اگر follower مدتی پیام leader را نبیند، درخواست رأی می‌دهد. رأی اکثریت او را leader می‌کند. کلاینت فقط با leader حرف می‌زند. از Raft برای تنظیمات مهم، قفل و metadata استفاده کن؛ نه برای هر درخواست پرترافیک مثل لایک.

Split-brain فقط با election حل نمی‌شود

فرض کن leader قدیمی به‌خاطر partition از quorum جدا شده اما هنوز به یک storage خارجی می‌نویسد. برای جلوگیری از write دیررس، هر leader یک fencing token یکنواختِ افزایشی می‌گیرد؛ storage فقط token بزرگ‌تر را می‌پذیرد. TTL یا «فکر می‌کنم هنوز leader هستم» به‌تنهایی امنیت نمی‌دهد.

DIAGRAMنوشتن امن با quorum

Client

→

Leader — term 42

→

Follower A

Follower B

→

Commit → state machine

به زبان ساده

چند سرور باید روی «الان کی رئیس است» توافق کنند، حتی وقتی بعضی‌شان قطع‌اند؛ رأی اکثریت رئیس را می‌سازد و نشانِ نوبتی (fencing) جلوی رئیسِ قدیمیِ برگشته را می‌گیرد.

مثال واقعی

فرض کن فقط یک job باید هر شب حقوق را محاسبه کند. اگر دو worker هم‌زمان فکر کنند رئیس‌اند، حقوق دوبار پرداخت می‌شود؛ انتخاب رئیس + fencing token به دیتابیس می‌گوید دستور رئیس قدیمی را قبول نکند.