توکن‌های شمشیربازی چگونه مانع از خطای دوپارگی مغز در قفل‌های توزیع‌شده می‌شوند؟

توکن‌های شمشیربازی (Fencing Tokens) با سنجاق کردن یک شماره ترتیب اکیداً صعودی به هر نوبت از تصاحب قفل، جلوی خطای فاجعه‌بار «دوپارگی مغز» (Split-Brain) و تخریب داده‌ها را می‌گیرند؛ سازوکاری که به سیستم ذخیره‌سازی زیرین اجازه می‌دهد درخواست‌های نوشتن کلاینت‌هایی را که مدت اجاره قفل‌شان به پایان رسیده، بی‌درنگ پس بزند. در عمل، وقتی سامانه‌ای با وقفه کامل جمع‌آوری زباله حافظه (Stop-the-world GC) مواجه می‌شود، کلاینت برای مدتی منجمد شده، اعتبار قفلش را از دست می‌دهد و سپس با این توهم بیدار می‌شود که هنوز مالک انحصاری منبع است.[1]

این آسیب‌پذیری ساختاری در تمام معماری‌های توزیع‌شده‌ای که برای حفظ انحصار متقابل به اجاره‌های زمان‌دار تکیه می‌کنند، وجود دارد. در این الگو، سرورِ مدیریت قفل به کلاینت اجازه می‌دهد برای بازه زمانی مشخصی—مثلاً ۳۰ ثانیه—یک منبع مشترک را دستکاری کند.[2]

اگر کلاینت ناگهان از کار بیفتد، مهلت اجاره تمام می‌شود تا منبع برای همیشه قفل نماند؛ ایده‌ای که روی کاغذ منطقی است، اما تکیه بر مفهوم طول عمر (TTL) در بستر واقعی محیط‌های اجرای امروزی، به یک حفره مهلک امنیتی ختم می‌شود.[1]

برنامه‌هایی که با زبان‌هایی مثل جاوا یا گو نوشته می‌شوند، هر از گاهی تمام رشته‌های پردازشی را متوقف می‌کنند تا حافظه آزاد شود. این وقفه‌های پاک‌سازی حافظه معمولاً بین ۵ تا ۵۰ میلی‌ثانیه طول می‌کشند، اما زیر بار سنگین کاری، مواردی ثبت شده که این تعلیق به ۱۲۰ ثانیه یا حتی بیشتر کشیده شده است.[1]

خطر نوشتن در وضعیت دوپارگی مغز

در طول چنین وقفه سنگینی، کل فرآیند کلاینت موقتاً فلج شده و هیچ ارتباطی با شبکه ندارد. سرور قفل که این سکوت طولانی را می‌بیند، فرض را بر مرگ کلاینت گذاشته و اجازه می‌دهد اجاره ۳۰ ثانیه‌ای باطل شود.[3]

سپس قفل بدون هیچ هشداری به کلاینت دوم واگذار می‌شود و آن کلاینت نیز پردازش همان وظیفه را آغاز می‌کند. فاجعه درست در لحظه‌ای رقم می‌خورد که وقفه حافظه کلاینت اول به پایان می‌رسد.[1]

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

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

مارتین کلپمن، پژوهشگر برجسته سیستم‌های توزیع‌شده، در تحلیل جریان‌ساز خود در سال ۲۰۱۶ خاطرنشان کرد: «قفل‌ها محدودیت زمانی دارند که فی‌نفسه ایده خوبی است؛ وگرنه اگر کلاینتی از کار بیفتد، منبع تا ابد قفل می‌ماند. با این حال، اگر وقفه جمع‌آوری زباله بیشتر از زمان انقضای اجاره طول بکشد، کلاینت به کارش ادامه داده و تغییراتی ناامن اعمال می‌کند.»[1]

اعمال ترتیب با توکن‌های شمشیربازی

نکته اینجاست که خودِ سرویس قفل‌گذاری هیچ توانی برای جلوگیری از این تداخل ندارد. تا زمانی که کلاینت تأخیرخورده بیدار شود و بسته نوشتن خود را به شبکه بفرستد، سرور قفل دیگر هیچ نقشی در این تراکنش ایفا نمی‌کند.[3]

کلاینت مستقیماً با لایه ذخیره‌سازی صحبت می‌کند؛ لایه‌ای که به خودی خود هیچ اطلاعی از وضعیت قفل‌های توزیع‌شده ندارد. این نقطه کور معماری نشان می‌دهد که پیچیده‌تر کردن الگوریتم‌های اجماع در سرور قفل، هیچ کمکی به حل این رقابت مخرب (Race Condition) نمی‌کند.[1]

چه مدیریت قفل را به یک سرور منفرد بسپارید و چه آن را روی کلاستری با قابلیت اطمینان بالا سوار کنید، موتور ذخیره‌سازی همچنان در برابر بسته‌های تأخیری بی‌دفاع است. این نظارت باید حتماً در مقصد نهایی پیاده شود.[1]

برای پر کردن این شکاف، مهندسان به سراغ توکن‌های شمشیربازی رفته‌اند؛ یک شماره ترتیبی اکیداً یکنواخت و صعودی که توسط سرویس قفل تولید می‌شود. هر بار که کلاینتی قفلی را می‌گیرد یا آن را تمدید می‌کند، سرویس یک عدد صحیح برمی‌گرداند که قطعاً از تمام شماره‌های قبلی بزرگ‌تر است.[1]

کلاینت موظف است این توکن را همراه تمام درخواست‌های نوشتن خود به سیستم ذخیره‌سازی بفرستد. در مقابل، موتور پایگاه داده نیز بالاترین رقمی را که تاکنون پردازش کرده به عنوان سقف معتبر ذخیره نگه می‌دارد.[5]

تولید دنباله‌های اکیداً صعودی

همین مقایسه ریاضی ساده، سدی نفوذناپذیر در برابر داده‌های سوخته می‌سازد. وقتی کلاینت اول پس از وقفه‌ای طولانی بیدار می‌شود، تلاش می‌کند داده‌ها را با همان توکن قدیمی‌تر خود، مثلاً ۳۳، بنویسد.[1]

سیستم ذخیره‌سازی این عدد را با توکن بالاتری که قبلاً از کلاینت دوم دریافت کرده (مثلاً ۳۴) مقایسه می‌کند. پایگاه داده با تشخیص نقض ترتیب زمانی، درخواست نوشتن کلاینت تأخیرخورده را در دم رد می‌کند.[1]

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

در مستندات رسمی ردیس درباره الگوهای قفل‌گذاری توزیع‌شده صراحتاً آمده است: «شما باید توکن‌های شمشیربازی را پیاده‌سازی کنید. این موضوع به‌ویژه برای فرآیندهایی که زمان زیادی می‌برند حیاتی است و در مورد هر سیستم قفل توزیع‌شده‌ای صدق می‌کند.»[2]

البته همه پیاده‌سازی‌های قفل توزیع‌شده به صورت پیش‌فرض قادر به تولید توکن‌های اکیداً صعودی نیستند. به عنوان مثال، در ساختارهای استاندارد ردیس، توسعه‌دهندگان ناچارند خودشان اسکریپت جداگانه‌ای برای افزایش اتمیک شمارنده در کنار دریافت قفل بنویسند.[2]

محدودیت‌های فرضیات مبتنی بر زمان

در نقطه مقابل، سیستم‌های مبتنی بر اجماع اساساً برای ارائه همین تضمین‌های ترتیبی طراحی شده‌اند. آپاچی زوکیپر به هر تغییر وضعیتی یک شناسه تراکنش ۶۴ بیتی ترتیبی به نام zxid اختصاص می‌دهد.[3]

کلاینت‌ها می‌توانند به راحتی از این شناسه به عنوان یک توکن شمشیربازی امن استفاده کنند. به همین ترتیب، پایگاه داده etcd که وظیفه هماهنگی کلاسترهای کوبرنتیز را به دوش می‌کشد، تمام اصلاحات را با یک شماره بازنگری (Revision) سراسری ۶۴ بیتی دنبال می‌کند.[4]

هنگامی که کلاینتی در etcd یک اجاره توزیع‌شده دریافت می‌کند، شماره ویرایش ایجاد آن کلید، نقش یک توکن خودکار و فزاینده را بازی می‌کند که تمامی الزامات شمشیربازی داده را برآورده می‌سازد.[4]

فریم‌ورک هیزل‌کست (Hazelcast) این سازوکار را مستقیماً در قالب واسط کاربری FencedLock پیاده کرده و زحمت تولید دستی اعداد ترتیبی را از دوش منطق برنامه برداشته است. این فریم‌ورک وضعیت قفل را در یک گروه اجماع تکثیر کرده و با هر بار جابه‌جایی قفل، مقدار توکن را به‌طور خودکار افزایش می‌دهد.[5]

مهندسان هیزل‌کست در گزارش فنی خود پیرامون این قابلیت توضیح داده‌اند: «واسط FencedLock زنده بودن دارندگان قفل را از طریق مکانیزم نشست یکپارچه پایش می‌کند و اجازه می‌دهد سیستم‌های متفرقه نیز به راحتی در پروتکل قفل‌گذاری مشارکت داشته باشند.»[5]

پیاده‌سازی کنترل‌ها در لایه ذخیره‌سازی

ضرورت به‌کارگیری توکن‌های شمشیربازی پرده از یک واقعیت تلخ در سیستم‌های توزیع‌شده برمی‌دارد: زمان ساعت دیواری چیزی جز یک توهم نیست. تکیه بر اجاره ۳۰ ثانیه‌ای فرض را بر این می‌گذارد که ۳۰ ثانیه سرور قفل با ۳۰ ثانیه کلاینت مو نمی‌زند.[1]

در دنیای واقعی، خطای رانش ساعت و زمان‌بندی پردازنده مفهوم زمان را کاملاً متغیر می‌کنند. یک هایپروایزر در حال مدیریت ماشین‌های مجازی می‌تواند کل سیستم‌عامل مهمان را برای انتقال به یک سرور فیزیکی دیگر ناگهان متوقف کند.[1]

نوسانات و تأخیرهای شبکه هم دقیقاً بدون نیاز به هیچ‌گونه توقف فرآیندی، همین خطر را خلق می‌کنند. ممکن است کلاینت درخواست نوشتن خود را کاملاً در مهلت معتبر اجاره ارسال کرده باشد، اما بسته در یک سوئیچ شبکه کند به دام بیفتد.[1]

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

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

اگر پرس‌وجو به صفر سطر اثر بگذارد، کلاینت بلافاصله می‌فهمد که توکنش منقضی شده و قفل از دست رفته است. با حذف متغیر غیرقابل اعتماد زمان و اتکا به توالی اعداد، توکن‌های شمشیربازی امکان دستیابی به ثبات قطعی در معماری‌های توزیع‌شده را فراهم می‌سازند.[6]