چگونه شاخص ثبت مبتنی بر حد نصاب در Raft، یکپارچگی ماشین حالت توزیع‌شده را تضمین می‌کند

در یک پایگاه داده توزیع‌شده، لحظه‌ای که یک تراکنش دائمی می‌شود، نه زمانی است که سرور اصلی آن را روی دیسک می‌نویسد و نه زمانی که کلاینت پیام موفقیت دریافت می‌کند. در واقع، نتیجه در آستانه خاصی به نام «شاخص ثبت» (commit index) تعیین می‌شود؛ نقطه دقیقی که در آن اکثریت سرورهای کلاستر — یعنی یک حد نصاب — تایید می‌کنند که دستور را با موفقیت ذخیره کرده‌اند. تا زمانی که این شاخص جلو نرود، داده‌ها صرفا یک پیشنهاد هستند. اما به محض پیشروی آن، انتقال ماشین حالت از نظر ریاضی غیرقابل بازگشت می‌شود. این تمایز، موتور محرک الگوریتم اجماع Raft است؛ همان مکانیسمی که به سیستم‌هایی مانند etcd، Consul و CockroachDB اجازه می‌دهد بدون خراب کردن داده‌هایشان، از خرابی‌های فاجعه‌بار سخت‌افزاری جان سالم به در ببرند.[3]

مشکلی که Raft حل می‌کند، برای زیرساخت‌های مدرن بنیادی است. پیش از سال ۲۰۱۴، اجماع توزیع‌شده تحت سلطه Paxos بود؛ پروتکلی که پیاده‌سازی آن به قدری دشوار بود که مهندسان اغلب تقریب‌های ناقصی از آن می‌ساختند. دیگو اونگارو و جان اوسترهوت، Raft را با یک اولویت رادیکال معرفی کردند: قابل‌فهم بودن. همان‌طور که در تحلیل‌های اولیه این پروتکل اشاره شده است، «به جای اینکه همه سرورها روی هر مقداری توافق کنند، سرورها روی یک رهبر توافق می‌کنند و سپس همیشه حق با رهبر است.» آن‌ها مشکل اجماع را به سه زیرمسئله مجزا تقسیم کردند: انتخاب رهبر، تکثیر لاگ و ایمنی؛ و چارچوبی ساختند که توسعه‌دهندگان واقعا می‌توانستند آن را درک و تحلیل کنند.[1]

بازاریابی پیرامون سیستم‌های توزیع‌شده اغلب وعده «دسترس‌پذیری بالای یکپارچه» و «زمان ازکارافتادگی صفر» را می‌دهد. اما در پس این هیاهوی تبلیغاتی، یک سیستم توزیع‌شده صرفا گروهی از ماشین‌های مستقل است که سعی می‌کنند روی یک شبکه غیرقابل‌اعتماد به یکدیگر دروغ نگویند. Raft این کار را با اعمال یک سلسله‌مراتب سخت‌گیرانه انجام می‌دهد. در هر زمان مشخص، یک کلاستر Raft دقیقا ۱ رهبر دارد، در حالی که بقیه گره‌ها به عنوان پیرو عمل می‌کنند. این مدل رهبر قدرتمند، جریان داده‌ها را ساده کرده و تضمین می‌کند که تمام تغییرات حالت، به جای نیاز به مذاکرات پیچیده همتا به همتا، از یک منبع واحد و معتبر سرچشمه می‌گیرند.[2]

رهبر به عنوان تنها نقطه ورود برای تمام درخواست‌های کلاینت عمل می‌کند. وقتی دستوری می‌رسد — مثلا تنظیم مقدار پایگاه داده روی x = 3 — رهبر بلافاصله آن را اجرا نمی‌کند. در عوض، دستور را به عنوان یک ورودی جدید به لاگ ماندگار خود اضافه می‌کند. در این مرحله، دستور هنوز ثبت نهایی نشده است. اگر رهبر در همین لحظه از کار بیفتد، دستور ناپدید شده و حالت سیستم بدون تغییر باقی می‌ماند. رهبر پیش از آنکه بتواند با اطمینان تراکنش را تایید کند، ابتدا باید مطمئن شود که دستور فراتر از سخت‌افزار فیزیکی خودش بقا می‌یابد.

برای تبدیل دستور از یک پیشنهاد شکننده به یک واقعیت دائمی، رهبر یک فراخوانی روال از راه دور (RPC) به نام افزودن ورودی‌ها را برای هر پیرو در کلاستر صادر می‌کند. اینجاست که مکانیک حد نصاب وارد عمل می‌شود. در یک کلاستر استاندارد ۵ گرهی، رهبر به حداقل ۲ پیرو نیاز دارد (که با احتساب خودش، اکثریت ۵۱ درصدی یعنی ۳ گره را تشکیل می‌دهند) تا ورودی را با موفقیت در لاگ‌های مربوطه خود بنویسند و با یک تاییدیه پاسخ دهند. سیستم منتظر کندترین گره‌ها نمی‌ماند؛ بلکه تنها به پاسخ سریع‌ترین اکثریت نیاز دارد.[3]

این همان گام حیاتی است: پیشبرد شاخص ثبت. شاخص ثبت به سادگی یک عدد صحیح است که بالاترین ورودی لاگ را که می‌دانیم در یک حد نصاب تکثیر شده، ردیابی می‌کند. به محض اینکه رهبر آن ۲ تاییدیه پیروان را دریافت کند، شاخص ثبت داخلی خود را افزایش می‌دهد. تنها در آن زمان است که رهبر دستور را در ماشین حالت محلی خود اعمال کرده، مقدار را به 3 تغییر می‌دهد و پیام موفقیت را به کلاینت برمی‌گرداند. پیروان نیز به محض دریافت شاخص ثبت به‌روزرسانی‌شده در سیگنال حیات بعدی، دستور را در ماشین‌های حالت خود اعمال خواهند کرد.[3]

ظرافت حد نصاب در این است که از نظر ریاضی هم‌پوشانی را تضمین می‌کند. اگر یک کلاستر ۵ گرهی به دلیل خرابی شبکه دوپاره شود، تنها طرفی که حداقل ۳ گره دارد می‌تواند حد نصاب تشکیل داده و شاخص ثبت خود را جلو ببرد. سمت اقلیت از نظر فیزیکی قادر به ثبت ورودی‌های جدید نیست و برای پیشرفت، دقیقا به ۱ رفت‌وبرگشت به یک حد نصاب نیاز دارد. این امر از سناریوی وحشتناک «دوپارگی مغز» که در آن پایگاه داده به دو واقعیت متناقض تقسیم می‌شود، جلوگیری می‌کند. سیستم برای حفظ یکپارچگی مطلق داده‌ها، پیشرفت را در سمت اقلیت متوقف می‌کند.[3]

اما چه اتفاقی می‌افتد اگر رهبر پس از نوشتن لاگ توسط حد نصاب، اما پیش از آنکه بتواند شاخص ثبت به‌روزرسانی‌شده را پخش کند، از کار بیفتد؟ اینجاست که ویژگی ایمنی Raft، به ویژه ویژگی تطابق لاگ، می‌درخشد. وقتی گره‌های باقی‌مانده غیبت رهبر را از طریق پایان زمان انتظار سیگنال حیات — که معمولا بین ۱۵۰ تا ۳۰۰ میلی‌ثانیه تصادفی شده است — تشخیص می‌دهند، یک انتخابات جدید را آغاز می‌کنند. تایمرهای تصادفی تضمین می‌کنند که همه گره‌ها همزمان درخواست رای نکنند، که این امر از بن‌بست‌های انتخاباتی بی‌پایان جلوگیری کرده و به کلاستر اجازه می‌دهد به سرعت بازیابی شود.[2]

در طول انتخابات، یک نامزد باید از کلاستر درخواست رای کند. با این حال، یک پیرو هر نامزدی را که لاگ آن نسبت به لاگ خودش کمتر به‌روز باشد، قاطعانه رد می‌کند. از آنجا که دستور قبلی در یک حد نصاب نوشته شده بود، هر حد نصاب جدیدی که برای انتخاب رهبر لازم است، باید حداقل شامل ۱ گره باشد که آن آخرین ورودی لاگ را در اختیار دارد. این ویژگی اشتراک تضمین می‌کند که به‌روزترین داده‌ها همیشه باقی می‌مانند و به عنوان یک سد نفوذناپذیر در برابر از دست رفتن داده‌ها در طول انتقال رهبری عمل می‌کند.[1]

در نتیجه، تضمین می‌شود که رهبر تازه انتخاب‌شده تمام ورودی‌های ثبت‌شده را در اختیار دارد. به محض اینکه قدرت را به دست می‌گیرد، پیروان را مجبور می‌کند لاگ او را کپی کنند و هرگونه ورودی ثبت‌نشده و متفاوتی را که ممکن است داشته باشند، بازنویسی می‌کند. ماشین حالت کاملا یکپارچه باقی می‌ماند و خرابی سخت‌افزاری را به طور کامل از دید کاربر نهایی پنهان می‌کند. یک کلاستر ۷ گرهی با استفاده از همین مکانیسم می‌تواند از ۳ خرابی همزمان جان سالم به در ببرد و تا زمانی که اکثریت ۴ گرهی آنلاین و در حال ارتباط باقی بمانند، به طور یکپارچه به عملیات خود ادامه دهد. این تاب‌آوری همان دلیلی است که Raft را به ستون فقرات زیرساخت‌های مدرن ابری تبدیل کرده است.[3]

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

برای دور زدن این محدودیت، سیستم‌هایی مانند Yugabyte و CockroachDB یک گروه عظیم Raft را اجرا نمی‌کنند. در عوض، آن‌ها پایگاه داده را شارد کرده و هزاران گروه اجماع Raft مستقل در سطح پارتیشن را به طور همزمان اجرا می‌کنند. این امر به آن‌ها اجازه می‌دهد تا در حالی که خطی‌پذیری تک‌کلیدی را حفظ می‌کنند، نوشتن‌های همزمان را در کلیدهای مختلف پردازش کنند. با موازی‌سازی مکانیسم اجماع، این پایگاه‌های داده بدون فدا کردن تضمین‌های ایمنی سخت‌گیرانه پروتکل زیربنایی، به مقیاس‌پذیری افقی عظیمی که مشتریان سازمانی نیاز دارند دست می‌یابند. هر شارد به طور مستقل انتخاب رهبر و شاخص ثبت خود را مدیریت کرده و عملا گلوگاه رهبر واحد را دور می‌زند.[3]

علاوه بر این، در حالی که مشخصات پایه Raft خرابی‌های غیربیزانسی را فرض می‌کند — به این معنی که گره‌ها ممکن است از کار بیفتند یا قطع شوند، اما فعالانه پیام‌های مخرب جعل نمی‌کنند — استقرار سیستم‌های مدرن باید زیرساخت‌های در معرض خطر را نیز در نظر بگیرد. پروتکل استاندارد به طور ضمنی به رهبر اعتماد دارد. اگر یک گره هک شود و بتواند در انتخابات پیروز شود، می‌تواند ماشین حالت را خراب کند. این محدودیت، تحقیقات مداوم روی نسخه‌های مقاوم در برابر خطای بیزانس Raft را پیش برده است که برای تایید اصالت هر ورودی لاگ، به امضاهای رمزنگاری‌شده و حد نصاب‌های بزرگ‌تری نیاز دارند.[4]

با وجود این موارد استثنایی، شاخص ثبت مبتنی بر حد نصاب همچنان یکی از قوی‌ترین مکانیسم‌ها در زیرساخت‌های مدرن است. Raft با تغییر تعریف «انجام شد» از دیسک یک ماشین واحد به اکثریت ریاضی شبکه، در ۱۲ سال گذشته اجماع توزیع‌شده را از یک معمای آکادمیک به یک کالای قابل‌اعتماد و قابل‌استقرار تبدیل کرد. این پروتکل ثابت می‌کند که در یک سیستم توزیع‌شده، یکپارچگی واقعی نه با دیکته کردن حقیقت توسط یک رهبر، بلکه با به خاطر سپردن جمعی آن توسط یک حد نصاب به دست می‌آید.[1][4]