ویرگول
ورودثبت نام
مهدی امیری متین
مهدی امیری متینبرنامه نویس وب و اندروید
مهدی امیری متین
مهدی امیری متین
خواندن ۷ دقیقه·۲ ماه پیش

آشنایی با الگوریتم کواروم

Quorum Algorithm
Quorum Algorithm

الگوریتم کواروم (Quorum Algorithm) یکی از روش‌های پرکاربرد در سیستم‌های توزیع‌شده برای تصمیم‌گیری و هماهنگ‌سازی بین نودها (Nodes) است. هدف اصلی این الگوریتم اطمینان از این است که حتی در صورت خرابی یا از دسترس خارج شدن بخشی از سیستم، همچنان داده‌ها و تصمیمات یکپارچه (Consistent) باقی بمانند.


ایده اصلی کواروم

ایده کواروم بر این اصل استوار است که برای انجام یک عملیات حساس (مثل نوشتن یا انتخاب لیدر)، لازم نیست همه نودها شرکت کنند، بلکه کافی است تعداد مشخصی از آن‌ها که به آن حد نصاب کواروم (Quorum Size) گفته می‌شود، موافقت کنند.

به عنوان مثال، در یک کلاستر ۵ نودی:

  • حد نصاب کواروم برای عملیات اکثریت معمولاً ۳ نود است.

  • حتی اگر ۲ نود از کار بیفتند، سیستم همچنان می‌تواند با ۳ نود باقی‌مانده و به کار ادامه دهد.


مفهوم رأی‌گیری و حداقل نودهای لازم

در بسیاری از الگوریتم‌های اجماع مانند Raft یا Paxos، رأی‌گیری برای انتخاب لیدر یا تأیید یک تراکنش بر اساس کواروم انجام می‌شود.

  • اگر یک نود درخواست نوشتن داده‌ای را داشته باشد، باید موافقت بیش از نصف تعداد نودها را به دست آورد.

  • این روش باعث می‌شود که هیچ دو گروه جدا از هم (در صورت تقسیم شبکه) نتوانند تصمیم متناقض بگیرند.


رابطه کواروم با تحمل خطا (Fault Tolerance)

کواروم ارتباط مستقیمی با تحمل خطا دارد. برای یک کلاستر با N نود:

  • حداکثر تعداد نودهایی که می‌توانند از کار بیفتند بدون آنکه سیستم از دسترس خارج شود، برابر است با:

(N-1)/2 = F

به عنوان مثال:

  • در کلاستر ۳ نودی ← حداکثر ۱ نود می‌تواند از کار بیفتد.

  • در کلاستر ۵ نودی ← حداکثر ۲ نود می‌توانند از کار بیفتند.

کاربردها در دیتابیس‌ها و سیستم‌های کلان

  • Etcd و Consul برای ذخیره‌سازی تنظیمات و هماهنگی بین سرویس‌ها

  • Cassandra برای کواروم خواندن (Quorum Read) و نوشتن (Quorum Write)

  • Galera Cluster برای هماهنگی عملیات نوشتن بین چند پایگاه داده MySQL همزمان

  • سیستم‌های CDN (Content Delivery Network) برای هماهنگ‌سازی داده‌ها بین چند مرکز داده (Data Center)


 سناریوی کواروم در کلاستر سه‌نودی

یکی از رایج‌ترین و ساده‌ترین پیاده‌سازی‌های کواروم (Quorum) در سیستم‌های توزیع‌شده، استفاده از یک کلاستر سه‌نودی (3-Node Cluster) است. این معماری به دلیل سادگی و توانایی ایجاد اجماع (Consensus) با حداقل منابع، در بسیاری از پایگاه‌های داده و سیستم‌های هماهنگی سرویس‌ها کاربرد دارد.

معماری

یک کلاستر سه‌نودی شامل سه سرور (یا نود) است که هر کدام یک نسخه کامل از داده‌ها یا وضعیت سیستم را نگهداری می‌کنند.

  • این سه نود به صورت همزمان با یکدیگر در ارتباط هستند.

  • معمولاً یکی از آن‌ها به عنوان لیدر (Leader) انتخاب شده و دو نود دیگر فالوئر (Followers) هستند.

فرآیند رأی‌گیری

در این معماری، برای انجام یک عملیات حساس مانند:

  • انتخاب لیدر

  • ثبت یک تراکنش جدید

  • تغییر وضعیت پیکربندی

باید حداقل ۲ نود (اکثریت) با آن موافق باشند.

مثال:

  • اگر نود A خراب شود، نودهای B و C می‌توانند به توافق برسند و عملیات ادامه یابد.

  • اگر ارتباط بین دو نود قطع شود و هر کدام بخواهند مستقل تصمیم بگیرند، مکانیزم کواروم از وقوع Split Brain جلوگیری می‌کند.

حد نصاب کواروم (Quorum Size)

در یک کلاستر سه‌نودی:

Quorum Size=1+[N/2]

که برای N=3N = 3N=3 برابر با:

Quorum Size=1+[3/2] = 2

یعنی برای تصمیم‌گیری معتبر، باید موافقت حداقل ۲ نود کسب شود.

مزایا

  • سادگی پیاده‌سازی: فقط سه نود نیاز است.

  • تحمل خطا: خرابی یک نود بدون توقف سیستم مدیریت می‌شود.

  • جلوگیری از Split Brain: اکثریت مشخص مانع از تصمیم‌گیری متناقض می‌شود.

  • هزینه پایین‌تر نسبت به کلاسترهای بزرگ‌تر.

معایب

  • در صورت خرابی دو نود، سیستم از کار می‌افتد.

  • افزایش بار پردازشی روی نودها نسبت به تعداد کم.

  • مقیاس‌پذیری محدود در عملیات نوشتن (Write).

نقاط شکست احتمالی

  • خرابی همزمان دو نود ← از دست رفتن دسترس‌پذیری.

  • قطع ارتباط شبکه بین نودها ← خطر آغاز فرآیند انتخاب لیدر توسط چند گروه جدا (در صورت عدم پیکربندی صحیح).

  • لیدر نامناسب ← انتخاب لیدر با منابع ضعیف می‌تواند باعث افت کارایی شود.


سناریوی کواروم در دو مرکز داده (2 DC – Two Data Centers)

وقتی یک کلاستر بین دو مرکز داده (Data Center) توزیع می‌شود، موضوع کواروم (Quorum) پیچیده‌تر از حالت تک دیتاسنتر می‌شود. دلیل این پیچیدگی، احتمال قطع ارتباط بین مراکز داده و ایجاد شرایطی شبیه به Split Brain است.


نحوه توزیع نودها

در یک سناریوی دو مرکز داده، معمولاً دو الگوی اصلی وجود دارد:

  1. الگوی متقارن – تعداد برابر نودها در هر مرکز داده

    • مثال: ۲ نود در DC1 و ۲ نود در DC2 (برای کلاستر ۴ نودی).

    • مشکل: در صورت قطع ارتباط بین دو DC، هر طرف می‌تواند نصف نودها را داشته باشد و احتمال Split Brain بالا می‌رود.

  2. الگوی نامتقارن – تعداد نودها طوری توزیع می‌شود که یک طرف همیشه اکثریت داشته باشد

    • مثال: ۲ نود در DC1 و ۱ نود در DC2 (برای کلاستر ۳ نودی).

    • مزیت: در صورت قطع ارتباط، تنها طرفی که اکثریت دارد، تصمیم‌گیری را ادامه می‌دهد.


مزایا

  • افزایش تحمل خطا (Fault Tolerance): خرابی یک مرکز داده کامل لزوماً باعث توقف سرویس نمی‌شود (در الگوی نامتقارن).

  • پایداری جغرافیایی: داده‌ها در دو مکان فیزیکی مجزا نگهداری می‌شوند و در برابر بلایای طبیعی مقاوم‌تر هستند.

  • کاهش تاخیر برای کاربران منطقه‌ای: کاربران هر منطقه می‌توانند به نزدیک‌ترین DC متصل شوند.

معایب

  • افزایش تاخیر بین نودها (Inter-DC Latency) به دلیل فاصله فیزیکی بین مراکز داده.

  • احتمال Split Brain در طراحی متقارن اگر مکانیزم جلوگیری از آن وجود نداشته باشد.

  • پیچیدگی مدیریت و مانیتورینگ به دلیل وجود زیرساخت در دو مکان متفاوت.

مشکلات Split Brain و روش‌های پیشگیری

Split Brain زمانی رخ می‌دهد که هر دو DC تصور کنند اکثریت دارند و هر کدام یک لیدر مستقل انتخاب کنند. این موضوع باعث ناسازگاری داده‌ها می‌شود.

روش‌های پیشگیری:

  • طراحی نامتقارن – قرار دادن تعداد نودها به شکلی که تنها یک طرف بتواند اکثریت داشته باشد.

  • استفاده از شاهد (Witness Node) – اضافه کردن یک نود سبک‌وزن در مکان سومی که فقط برای رأی‌گیری استفاده می‌شود.

  • Quorum-Based Failover – مکانیزمی که فقط به طرفی که اکثریت واقعی دارد اجازه ادامه کار می‌دهد.

  • Inter-DC Heartbeat – مانیتورینگ فعال ارتباط بین DCها و جلوگیری از شروع انتخابات در شرایط نامطمئن.


سناریوی کواروم در سه مرکز داده (3 DC – Three Data Centers)

استقرار یک کلاستر بین سه مرکز داده (Data Center) یکی از مطمئن‌ترین روش‌ها برای جلوگیری از Split Brain و افزایش تحمل خطا است. با این حال، نحوه توزیع نودها بین DCها، تاثیر زیادی بر عملکرد و پایداری سیستم دارد.

حالت اول: توزیع متقارن ۳-۳-۳

معماری

  • هر DC شامل ۳ نود است.

  • مجموع نودها: ۹ نود.

  • حد نصاب کواروم (Quorum Size) = ⌊9/2⌋ + 1 = ۵ نود.

تحلیل انتخاب لیدر در سناریوهای قطعی

۱. قطعی بین دو DC

  • مثال: DC1 و DC2 ارتباطشان قطع می‌شود ولی هر دو به DC3 وصل هستند.

  • چون DC3 با هر دو سمت در ارتباط است، تنها یکی از طرفین می‌تواند لیدر داشته باشد و DC3 نقش داور را بازی می‌کند. Split Brain رخ نمی‌دهد.

2. قطعی کامل بین هر سه DC (Three-Way Partition)

  • هر DC فقط ۳ نود دارد و به حد نصاب ۵ نمی‌رسد.

  • نتیجه: کل سیستم متوقف می‌شود تا از ناسازگاری جلوگیری شود.

3. قطعی یک DC از دو تای دیگر

  • مثال: DC1 از DC2 و DC3 جدا می‌شود، ولی DC2 و DC3 همچنان به هم وصل هستند.

  • DC2 + DC3 = 6Node ← اکثریت دارند و انتخاب لیدر ادامه دارد.

  • DC1 با ۳ نود ← از کار می‌افتد.

مزایا

  • پایداری بالا در برابر خرابی یک DC کامل.

  • جلوگیری از Split Brain در اکثر سناریوهای قطعی.

معایب

  • Latency (تاخیر بالا) به دلیل نیاز به ارتباط بین ۵ نود از مناطق مختلف برای هر تصمیم.

  • هزینه زیاد به دلیل تعداد بالای نودها.

  • توقف کامل سیستم در صورت قطع ارتباط هر سه DC از یکدیگر.

حالت دوم: توزیع نامتقارن ۳-۳-۱

معماری

  • DC1 → ۳ Node

  • DC2 → ۳ Node

  • DC3 → ۱ Node (نود شاهد یا Witness Node)

  • مجموع نودها: ۷ نود.

  • حد نصاب کواروم = ⌊7/2⌋ + 1 = ۴ نود.

تحلیل انتخاب لیدر در سناریوهای قطعی

۱. قطعی بین دو DC

  • مثال: DC1 و DC2 از هم جدا می‌شوند، اما هر دو به DC3 وصل هستند.

  • DC3 به عنوان نود شاهد تعیین می‌کند کدام سمت اکثریت دارد.

  • معمولاً یکی از DC1 یا DC2 لیدر می‌شود و دیگری متوقف می‌گردد.

2. قطعی کامل بین هر سه DC

  • DC1 = ۳ نود، DC2 = ۳ نود، DC3 = ۱ نود.

  • هیچ‌کدام به حد نصاب ۴ نمی‌رسند ← سیستم متوقف می‌شود.

3. قطعی یک DC از دو تای دیگر

  • مثال: DC1 جدا می‌شود، DC2 + DC3 باقی می‌مانند.

  • DC2 + DC3 = ۴ Node ← اکثریت دارند و ادامه کار می‌دهند.

  • DC1 با ۳ نود ← متوقف می‌شود.

مزایا

  • جلوگیری مؤثر از Split Brain به کمک نود شاهد.

  • هزینه کمتر نسبت به حالت ۳-۳-۳ (فقط ۷ نود).

  • اکثریت راحت‌تر تشکیل می‌شود (۴ نود به جای ۵ نود).

معایب

  • DC3 نقطه حساس سیستم می‌شود (اگر DC3 از دست برود، برخی سناریوهای Failover دشوارتر می‌شوند).

  • همچنان Latency بالا در عملیات بین‌DCی به دلیل فاصله جغرافیایی.

  • وابستگی زیاد به پایداری ارتباط با نود شاهد.

کار
۰
۰
مهدی امیری متین
مهدی امیری متین
برنامه نویس وب و اندروید
شاید از این پست‌ها خوشتان بیاید