یک نویسنده، چند عامل: کنترل هم‌زمانی مقاوم در برابر خرابی

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

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

تصمیم عملیاتی این است: برای هر منبع مشترک باید مالکیت را بخش‌بندی کرد، نوشتن را به یک نویسنده سپرد، نسخه را با compare-and-swap سنجید، تغییر را در تراکنش ثبت کرد، از اجاره همراه توکن حصارکشی استفاده کرد، یا به‌جای نوشتن مستقیم پیشنهادهای قابل‌ادغام ساخت؟ پاسخ باید در معماری برنامه ثبت شود؛ نه اینکه مدل زبانی پس از آغاز رقابت آن را بداهه بسازد.

هم‌زمانی نام دیگری برای تلاش دوباره نیست

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

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

سه ادعا باید جدا بماند:

1. کارگر زمانی مالکیت را گرفته است. هماهنگ‌کننده به او اجاره داده یا او را رهبر انتخاب کرده است.
2. کارگر هنوز تصور می‌کند مالک است. زمان‌سنج، کش یا نشست محلی خلاف آن را نگفته است.
3. مقصد فقط مالکیت جاری را می‌پذیرد. پایگاه داده، سرویس یا آداپتور در لحظه ثبت، نسخه یا توکن حصارکشی یکنواخت افزایشی را می‌سنجد.

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

سامانه‌های تثبیت‌شده واقعاً چه تضمینی می‌دهند

HTTP از قبل یک ابزار مفید برای کنترل خوش‌بینانه هم‌زمانی دارد. RFC 9110 سرآیند If-Match را برای درخواست‌های تغییردهنده وضعیت تعریف می‌کند: سرور مبدأ پیش از اجرای روش، برچسب موجودیت قوی را می‌سنجد و معمولاً اگر نمایش منبع عوض شده باشد پاسخ 412 Precondition Failed می‌دهد. استاندارد این رفتار را راهی برای جلوگیری از «به‌روزرسانی گم‌شده» می‌داند. استاندارد نمی‌گوید گردش کار هوش مصنوعی تعارض را چگونه حل کند؛ اما به‌جای بازنویسی خاموش، یک امتناع صادقانه تحویل می‌دهد.

راهنمای هم‌زمانی Amazon DynamoDB میان کنترل نسخه خوش‌بینانه برای رقابت کم، تراکنش برای تغییر اتمی چند قلم و قفل مبتنی بر اجاره و ضربان قلب برای هماهنگی طولانی تمایز می‌گذارد. همین راهنما هشدار می‌دهد که جدول‌های سراسری از سازوکار «آخرین نویسنده برنده است» استفاده می‌کنند؛ بنابراین الگوی نسخه در چند ناحیه همان حفاظت را ایجاد نمی‌کند. قرارداد تکثیر مخزن داده به‌اندازه کدی که پیرامون آن نوشته‌ایم اهمیت دارد.

در سطح پایگاه داده، مستندات جداسازی تراکنش PostgreSQL 18 می‌گوید اثر تراکنش‌های Serializable که با موفقیت ثبت شده‌اند با اجرای یکی‌یکی آن‌ها سازگار است. وقتی PostgreSQL ناهنجاری ترتیب‌پذیری را تشخیص می‌دهد، برنامه باید کل تراکنش را دوباره اجرا کند. خواندن داده، یک دقیقه گفت‌وگو با مدل و سپس باز کردن تراکنشی تازه، نمای اولیه را حفظ نمی‌کند؛ خواندن و نوشتن حیاتی باید در همان مرز تراکنش باشد.

سامانه‌های هماهنگی، مالکیت طولانی‌تر را پوشش می‌دهند. اجاره‌های Kubernetes برای ضربان قلب گره و انتخاب رهبر به کار می‌روند تا یک نمونه فعال کار کنترلی را انجام دهد و همتایان آماده جانشینی باشند. دستور پخت قفل در Apache ZooKeeper از گره‌های موقت ترتیبی استفاده می‌کند، فقط گره قبلی را زیر نظر می‌گیرد تا ازدحام بیدارباش رخ ندهد و یک GUID می‌افزاید تا اگر پاسخ ساخت گم شد، مشتری بتواند بفهمد عملیات واقعاً موفق شده است یا نه.

این سازوکارها در انتخاب مالک کمک می‌کنند، اما به‌تنهایی مانع رسیدن دیرهنگام مالک قبلی به یک مقصد بیرونی نمی‌شوند. مقاله اصلی گوگل درباره سرویس قفل Chubby حلقه مفقود را روشن می‌کند: دارنده قفل می‌تواند sequencer حاوی نسل قفل را به سرور مقصد بفرستد و سرور sequencer نامعتبر یا قدیمی‌تر را رد کند. این همان الگوی حصارکشی است. مالکیت به مقداری تبدیل می‌شود که مقصد اثر می‌تواند مقایسه کند، نه صرفاً باوری در ذهن کارگر.

ذخیره‌سازی شیء نیز همین اصل را بدون استفاده از واژه قفل ارائه می‌کند. پیش‌شرط‌های درخواست Google Cloud Storage اجازه می‌دهند نوشتن یا حذف، به نسل دقیق شیء مشروط شود. در این صورت حذف دیررسی که برای نسل قدیمی صادر شده، شکست می‌خورد و شیء تازه‌ای را که همان نام را دارد پاک نمی‌کند. پیش‌شرط، عمل را به همان نمونه‌ای از شیء می‌بندد که فراخواننده واقعاً دیده است.

این‌ها رفتارهای تأییدشده پروتکل‌ها هستند. مدل عملیاتی ادامه مقاله، تحلیل ژرف بر پایه ترکیب آن‌ها برای سامانه‌های هوش مصنوعی ابزارمحور است.

کوچک‌ترین قرارداد محافظ قاعده را انتخاب کنید

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

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

راهنمای کنترل پذیرش اینجا نیز مهم است: ترتیب‌دهی، رقابت را به صف منتقل می‌کند؛ پس صف همچنان به سقف، انقضا، انصاف و وضعیت رد شفاف نیاز دارد. ایمنی هم‌زمانی نباید انباری بی‌نهایت از کارهای منقضی بسازد.

پاکت مالکیت را بیرون از پرامپت نگه دارید

هر نوشتن پیامددار باید در کنار آرگومان‌های کسب‌وکار، فیلدهای هم‌زمانی تولیدشده توسط برنامه قابل‌اعتماد را حمل کند:

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

پاکت هم‌زمانی را به انتشار ثبت‌شده در گذرنامه انتشار هوش مصنوعی پیوند دهید. کارگری با آداپتور قدیمی ممکن است قالب توکن حصارکشی را اشتباه بسازد یا پیش‌شرط نسخه را جا بیندازد. در نتیجه هویت انتشار باید کنار هویت منبع در زنجیره مدرک ثبت شود.

کنترل را روی آخرین مرز اثر اجرا کنید

نگهبان باید همان‌جایی باشد که تغییر برگشت‌ناپذیر یا مرجع رخ می‌دهد. اگر هماهنگ‌کننده توکن را بسنجد و سپس API بدون محافظ فروشنده را صدا بزند، کارگر دیررس می‌تواند از مسیری دیگر تضمین را دور بزند.

برای ردیف پایگاه داده، شرط نسخه را در همان دستور به‌روزرسانی اجرا کنید یا تراکنش بسازید. برای شیء، پیش‌شرط نسل یا ETag بخواهید. برای کنترل‌گر استقرار، بالاترین توکن پذیرفته‌شده هر سرویس را نگه دارید و توکن پایین‌تر را رد کنید. اگر API بیرونی کنترل هم‌زمانی ندارد، یک آداپتور کنترل‌شده و تک‌نویسنده جلوی آن بگذارید؛ تماس‌ها را همان‌جا مرتب، وضعیت مرجع را بازبینی و دسترسی مستقیم کارگران به اعتبارنامه فروشنده را قطع کنید.

فراخوانی مدل را بیرون تراکنش پایگاه داده و معمولاً بیرون کوتاه‌ترین قفل نگه دارید. یک نما بگیرید، برنامه بسازید و اعتبارسنجی کنید؛ سپس درست پیش از ثبت، دوباره مالکیت بگیرید یا وضعیت جاری را بسنجید. اگر وضعیت عوض شده، برنامه منقضی است حتی اگر متن آن هنوز منطقی به نظر برسد. دوباره بخوانید، سیاست را بازبینی کنید و یا برنامه تازه بسازید یا تعارض را نمایش دهید.

پاسخ 409 یا 412، شکست شرط یا خطای ترتیب‌پذیری را با همان آرگومان قدیمی خودکار تکرار نکنید. رد هم‌زمانی، اطلاعات تازه است. پاسخ درست شاید محاسبه دوباره، ادغام، امتناع، ارجاع به انسان یا اعلام منسوخ شدن قصد باشد.

مثال عملی: عامل استقرار دیررس

فرض کنید کنترل‌گر استقرار مقادیر release=R12، version=41 و highest_fence=781 را نگه می‌دارد.

1. عامل A هشدار رخداد را می‌گیرد، اجاره با توکن 782 می‌گیرد، نسخه 41 را می‌خواند و بازگشت به R11 را آماده می‌کند.
2. اختلال شبکه عامل A را پیش از ثبت متوقف می‌کند. فرایند محلی او ادامه دارد و هنوز اجاره را معتبر می‌پندارد.
3. اجاره تمام می‌شود. عامل B توکن 783 می‌گیرد، سرویس جاری را می‌خواند، اصلاحیه R13 را اعتبارسنجی می‌کند و با expected_version=41 و fence=783 ثبت می‌کند.
4. کنترل‌گر به‌صورت اتمی release=R13، version=42 و highest_fence=783 را ذخیره می‌کند.
5. فرمان دیررس بازگشت عامل A با expected_version=41 و fence=782 می‌رسد.

کنترل‌گر A را به دو دلیل مستقل رد می‌کند: نسخه منبع تغییر کرده و توکن حصارکشی از بالاترین توکن پذیرفته‌شده قدیمی‌تر است. A وضعیت STALE_OWNER ثبت می‌کند، نسخه 42 را می‌خواند و قصد اولیه رخداد را برای ارزیابی دوباره می‌فرستد. او بازگشت را «برای کمک» روی R13 دوباره اجرا نمی‌کند.

اگر کنترل‌گر فقط می‌سنجید که A زمانی اجاره داشته، بازگشت منقضی می‌توانست برنده شود. اگر فقط نسخه مورد انتظار را می‌سنجید، عملی متفاوت که آن نسخه را تغییر نمی‌دهد شاید شکاف دیگری بسازد. مقصد باید قوی‌ترین قواعدی را که مالک آن‌هاست، هم‌زمان و اتمی با اثر اجرا کند.

کار چندمنبعی را یک گردش کار صریح بدانید

بسیاری از اقدامات عامل از پایگاه داده، سامانه تیکت، ذخیره‌سازی شیء و API فروشنده عبور می‌کنند. یک قفل نمی‌تواند این سامانه‌ها را به یک تراکنش تبدیل کند. ترتیب معیار و ماشین حالت روشنی تعریف کنید:

• PROPOSED: برنامه وجود دارد اما هنوز مالک چیزی نیست؛
• CLAIMED: مالک محدود و توکن حصارکشی صادر شده است؛
• PREPARED: نسخه جاری و کنترل سیاست تأیید شده است؛
• COMMITTING: اقدام محافظت‌شده در حال اجراست؛
• COMMITTED: نتیجه مرجع و نسخه تازه ثبت شده است؛
• CONFLICTED: پیش‌شرط یا کنترل ترتیب‌پذیری عمل را رد کرده است؛
• STALE_OWNER: توکن حصارکشی تازه‌تری وجود دارد؛
• RECONCILIATION_REQUIRED: نتیجه یا وضعیت میان سامانه‌ها نامعلوم است.

برای هر ثبت بیرونی دفتر اثر نگه دارید. اگر مرحله دوم پس از موفقیت مرحله اول شکست خورد، با یک قفل سراسری خیالی گردش کار را اتمی ننامید. وضعیت جزئی را ثبت کنید، جانشین ناسازگار را متوقف کنید و با همان انضباط راهنمای لغو، جبران یا بازبینی انجام دهید.

خرابی‌هایی که از آزمون عادی عبور می‌کنند

• قفل بدون حصارکشی: مالک منقضی پس از شروع مالک تازه نوشتن دیررس می‌فرستد.
• آخرین نویسنده برنده است: سیاست تکثیر منظم، اقدام آگاهانه‌تر را بی‌صدا کنار می‌گذارد.
• TTL به‌جای حقیقت: اختلاف ساعت، توقف پردازش یا اختلال شبکه برآورد محلی پایان اجاره را از هماهنگ‌کننده جدا می‌کند.
• کلید اشتباه منبع: دو نام مستعار برای یک مشتری، شاخه، دارایی یا شیء دو قفل جدا می‌گیرند.
• اول بررسی، بعد عمل: کد نسخه را می‌سنجد، محافظ را رها می‌کند و بعداً می‌نویسد.
• تکرار کور تعارض: کارگر آرگومان منقضی را آن‌قدر می‌فرستد تا شرط تصادفاً بگذرد.
• فراخوانی بلند مدل داخل تراکنش: قفل، اتصال یا نمای داده بسیار طولانی‌تر از بخش حیاتی زنده می‌ماند.
• یک توکن و چند مقصد: سامانه اول حصارکشی را اجرا می‌کند، اما آداپتور دوم نادیده می‌گیرد.
• ادغام با خلاصه روان: مدل ویرایش‌های ناسازگار را بدون حفظ قواعد آن‌ها ترکیب می‌کند.
• موفقیت پیش از راستی‌آزمایی: رابط کاربر به پاسخ کارگر تکیه می‌کند، نه وضعیت مرجع تازه.

درمان این خطاها زنجیره فکر طولانی‌تر نیست؛ دامنه مالکیت کوچک‌تر، ثبت محافظت‌شده و حالت تعارض صریح است.

مسابقه را آزمایش کنید، نه فقط دو مسیر سالم را

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

قواعد زیر را بسنجید:

• برای یک نسخه منبع، حداکثر یک ثبت ناسازگار پذیرفته می‌شود؛
• توکن حصارکشی پایین‌تر هرگز نمی‌تواند توکن بالاتر پذیرفته‌شده را بازنویسی کند؛
• شکست پیش‌شرط هیچ اثر جزئی نمی‌سازد؛
• تلاش دوباره وضعیت مرجع را می‌خواند و بودجه محدود دارد؛
• مالک منقضی به حالت نهایی یا بازبینی می‌رسد و در حلقه نمی‌ماند؛
• رابط کاربر میان انتظار، تعارض، مالک منقضی، نامعلوم و ثبت‌شده فرق می‌گذارد؛
• هر اثر پذیرفته‌شده به قصد، منبع، نسخه، توکن، انتشار و مدرک نتیجه متصل است.

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

مدرک لازم برای اثبات ادعا را نگه دارید. راهنمای شواهد ممیزی الگوی کامل‌تر را توضیح می‌دهد: ادعایی را ثبت کنید که بازرس باید اثبات کند، نه تمام توکن‌هایی را که مدل تولید کرده است.

دروازه یک نویسنده

پیش از آنکه چند عامل هوش مصنوعی وضعیت مشترکی را تغییر دهند، به این پرسش‌ها پاسخ مثبت بدهید:

1. آیا منبع معیار و قاعده محافظت‌شده صریحاً نام‌گذاری شده است؟
2. آیا مالکیت هرجا ممکن بوده بخش‌بندی شده است؟
3. آیا قرارداد انتخاب‌شده—صف، compare-and-swap، تراکنش، اجاره با حصارکشی یا ادغام—با شدت رقابت و پیامد تناسب دارد؟
4. آیا مقصد مرجع، نسخه یا توکن حصارکشی را اتمی با اثر اجرا می‌کند؟
5. آیا مالک قبلی می‌تواند به اجرا ادامه دهد بی‌آنکه قادر به ثبت باشد؟
6. آیا فراخوانی مدل بیرون کوتاه‌ترین بخش حیاتی نگه داشته می‌شود؟
7. آیا تعارض به بازخوانی و ارزیابی دوباره منجر می‌شود، نه تلاش کور؟
8. آیا اثر جزئی کار چندمنبعی صادقانه نمایش و بازبینی می‌شود؟
9. آیا همه آداپتورها هویت منبع و معنای توکن یکسانی دارند؟
10. آیا تأخیر، جابه‌جایی ترتیب، انقضا، خرابی، جانشینی و نام مستعار آزمایش شده‌اند؟
11. آیا اپراتور می‌بیند مالک کار کیست، کدام نسخه خوانده شده و چرا ثبت رد شده است؟
12. آیا مدرک می‌تواند نویسنده دقیق و وضعیتی را که مقصد پذیرفته اثبات کند؟

عامل‌های موازی مفیدند چون زمان انجام کار را کم می‌کنند و تخصص‌های مختلف را وارد گردش کار می‌کنند. خطر زمانی آغاز می‌شود که هم‌زمانی فقط جزئی از زمان‌بندی تلقی شود. طراحی قابل‌اعتماد برای هر قاعده مشترک یک ترتیب ثبت اجرایی می‌سازد و اختیار منقضی را همان‌جایی رد می‌کند که رد شدن هنوز می‌تواند جلوی آسیب را بگیرد.

یادداشت منابع — بازبینی در ۱۲ اوت ۲۰۲۶

• RFC 9110: HTTP Semantics — استاندارد ژوئن ۲۰۲۲ که در تاریخ انتشار بازبینی شد؛ منبع برچسب موجودیت قوی، If-Match، If-None-Match، جلوگیری از به‌روزرسانی گم‌شده و رفتار 412 Precondition Failed.
• PostgreSQL 18: Transaction Isolation — مستندات جاری بازبینی‌شده در تاریخ انتشار؛ منبع تضمین Serializable، خطای ترتیب‌پذیری و ضرورت اجرای دوباره کل تراکنش.
• Amazon DynamoDB: Best practices for handling concurrent updates — مستندات جاری بازبینی‌شده در تاریخ انتشار؛ منبع کنترل نسخه خوش‌بینانه، تراکنش، قفل مبتنی بر اجاره و محدودیت جدول‌های سراسری.
• Kubernetes: Leases — مستندات جاری بازبینی‌شده در تاریخ انتشار؛ منبع کاربرد Lease برای ضربان قلب و انتخاب رهبر.
• Apache ZooKeeper: Recipes and Solutions — مستندات نسخه ۳.۷.۲ بازبینی‌شده در تاریخ انتشار؛ منبع گره موقت ترتیبی، پایش گره قبلی، بازیابی با GUID و قفل مشترک.
• Google Research: The Chubby lock service — مقاله اصلی OSDI سال ۲۰۰۶؛ منبع نسل قفل، sequencer، compare-and-swap، رد نویسنده دیررس و محدودیت lock-delay.
• Google Cloud Storage: Request preconditions — مستندات جاری بازبینی‌شده در تاریخ انتشار؛ منبع محافظ نسل و جلوگیری از مسابقه حذف دیررس.