🔥 غیر قابل تمدید فقط تا پایان امشب، روز آخر تخفیف‌های بلک فرایدی!
۰ ثانیه
۰ دقیقه
۰ ساعت
۱ صادق
quorum در دیتابیس‌های CP
جامعه هوش مصنوعی ایجاد شده در ۱۴ مرداد ۱۴۰۴

سلام استاد
شما تو این قسمت گفتین تو سیستم‌های CP اگر یه نود downبشه سیستم نمیتونه به کار خودش ادامه بده چون سیستم consistancy نداره؟
آیا منظورتون این بود ک اگر quorum نود‌ها down بشن سیتم دیگ نمیتونه کار کنه یا نه؟
اگر نه پس بحث quorum دقیقا کجا کاربرد داره؟

سلام بله. اجازه دهید کمی بیشتر توضیح بدم:

متوجه سؤال شما شدم، این یک نکته مهم در درک سیستم‌های CP، بحث quorum و نحوه ادامه کار سیستم است.
بیایید قدم‌به‌قدم روشن کنیم.

 

در سیستم‌های CP (Consistency + Partition tolerance):

وقتی یک Partition اتفاق بیفتد (یا نود از دسترس خارج شود)،
سیستم برای حفظ Consistency حاضر است Availability را قربانی کند.

یعنی اگر نتواند از بین همه کپی‌های داده، اتفاق نظر اکثریت (quorum) را بگیرد، درخواست‌ها را پاسخ نمی‌دهد.

 

Quorum مجموعه‌ای حداقلی از نود‌ها یا Replicaهاست که باید با هم توافق داشته باشند تا یک عملیات (خواندن/نوشتن) معتبر شود.

مثلاً در مدل سه‌نسخه‌ای (۳ Replica):

اندازه quorum معمولاً اکثریت است (۳ از ۳ → quorum = ۲).

دلیلش این است که اگر تصمیم‌ها روی اکثریت گرفته شوند، حتی در صورت Partition، دو بخش جداشده هرگز نمی‌توانند دو تصمیم متناقض بگیرند چون اکثریت تداخلی خواهند داشت.


در سیستم‌های CP کار سیستم ادامه می‌یابد تا زمانی که بتوانید quorum را تشکیل دهید.

اگر یک نود از مجموعه ۳تایی down شود، ما هنوز ۲ نود داریم (quorum برقرار) → سیستم می‌تواند ادامه دهد.

ولی اگر به اندازه‌ای نود از دست بروند که quorum ممکن نباشد، سیستم برای حفظ Consistency، درخواست‌های جدید را متوقف می‌کند (یعنی Availability قربانی می‌شود).

بنابراین:

Down شدن یک نود → مشکلی ندارد اگر quorum باقی مانده.

Down شدن quorum → سیستم متوقف می‌شود (از دید کاربر، “Availability” از دست می‌رود).

Quorum معمولا در ۲ جا استفاده می‌شود:

  1. Replication Protocols (مثل Raft، Paxos، ZAB):
    برای commit کردن تغییرات، اکثریت replicaها باید تأیید کنند.
    این باعث می‌شود هیچ دو اکثریتی تصمیم متناقض نداشته باشند.
  2. خواندن و نوشتن در پایگاه‌داده‌های توزیع‌شده (مثل Cassandra، MongoDB با write concern/ read concern):
    • مثلا: W + R > N (مجموع quorum خواندن و نوشتن بزرگتر از کل نودها باشد) → تضمین consistency.
    • W = تعداد نودهایی که باید نوشتن را تأیید کنند.
      R = تعداد نودهایی که باید در خواندن پاسخ بدهند.
      N = کل replicaها.

 

فرض کنید دیتابیس شما ۵ replica دارد (N=5):

Quorum برای write: W=3

Quorum برای read: R=3

هر عملیاتی که کمتر از quorum داشته باشد، reject می‌شود.

 

اگر ۲ نود down شوند → هنوز quorum داریم (۳ نود آنلاین) → سیستم CP ادامه می‌دهد.

اگر ۳ نود down شوند → quorum نداریم → سیستم متوقف می‌شود، چون نمی‌تواند مطمئن باشد دیگر نودها چه وضعیتی دارند.

 

مسعود کاویانی ۱۶ آبان ۱۴۰۴، ۲۰:۴۴