فصل ۱۲ — ساگاهای تراکنشی

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

مسئله و زمینه

تراکنش محلی با ACID حس بدیهیِ «همه‌چیز یا هیچ‌چیز» می‌دهد؛ اما وقتی تغییر یک فرایند میان چند سرویس و چند پایگاه داده پخش شود، atomicity سراسری به مسئله‌ای پرهزینه و شکننده بدل می‌شود. Saga نامی برای مدل‌کردن این کار توزیع‌شده است: هر سرویس تراکنش محلی خود را انجام می‌دهد و معماری باید موفقیت، شکست، جبران یا همگرایی نهایی را مدیریت کند.

فصل ساگا را نتیجهٔ ترکیب سه محور می‌داند: ارتباط synchronous/asynchronous، سازگاری atomic/eventual و هماهنگی orchestrated/choreographed. نام‌های داستانی الگوها مهم‌تر از خود ابعاد نیستند؛ هدف این ماتریس، جلوگیری از انتخاب یک ویژگی به‌صورت جدا از پیامدهایش است.

مفاهیم و الگوهای مرکزی

atomicity در برابر eventual consistency

الگوی Epic Saga (sao) با فراخوانی همگام، orchestrator و سازگاری atomic، نزدیک‌ترین تجربه به monolith را بازسازی می‌کند. اگر یکی از گام‌ها شکست بخورد، mediator درخواست‌های compensating می‌فرستد تا تغییرهای قبلی برگردند. این مدل آشنا و برای فهم مسیر موفق ساده است، اما coupling بسیار بالا، availability و scale ضعیف، و failure modeهای فراوان دارد.

جبران، rollback واقعی نیست. در معماری توزیع‌شده isolation سراسری نداریم: ممکن است یک سرویس تحلیلی اثر تغییر اولیه را پیش از رسیدن پیام جبرانی مصرف کرده باشد. حتی خود compensation نیز ممکن است شکست بخورد. قفل‌کردن شرکت‌کنندگان برای حل این وضع، عملاً responsiveness و scalability را نابود می‌کند. بنابراین atomic distributed transaction باید یک نیاز اثبات‌شده باشد، نه واکنش پیش‌فرض به اضطراب دربارهٔ سازگاری.

جایگزین اصلی، مدیریت state همراه با eventual consistency است. در این رویکرد، خطای سرویس فرعی الزاماً پاسخ کاربر را متوقف نمی‌کند؛ saga به حالت خطا می‌رود، retry یا اصلاح خودکار/دستی در پس‌زمینه اجرا می‌شود و پس از همگرایی بسته می‌شود. هزینهٔ این انتخاب، ناهماهنگی موقت داده و نیاز به نمایش و پایش شفاف آن است؛ دستاوردش پاسخ‌گویی بهتر و جداسازی کاربر از جزئیات نامرتبط فرایند است.

نقشهٔ هشت‌گانهٔ ساگا

• Epic (sao): همگام، atomic، orchestrated؛ آشنا اما بیشترین coupling و کمترین scale.
• Phone Tag (sac): همگام، atomic، choreographed؛ حذف mediator گلوگاه را کم می‌کند، ولی منطق جبران و مسیرها را میان سرویس‌ها توزیع می‌کند؛ مناسب فقط برای جریان‌های ساده.
• Fairy Tale (seo): همگام، eventual، orchestrated؛ workflow کنترل‌شده و نسبتاً کم‌پیچیدگی، با مرز تراکنش محلی در هر سرویس. انتخابی متعادل برای بسیاری از microservices.
• Time Travel (sec): همگام، eventual، choreographed؛ برای pipelineهای یک‌طرفه و throughput بالا مناسب است، اما خطا و state پیچیده باید در سرویس‌ها حل شود.
• Fantasy Fiction (aao): ناهمگام، atomic، orchestrated؛ نگه‌داشتن state چند تراکنش معلق، ترتیب و وابستگی‌ها را دشوار می‌کند و معمولاً تلاش ناموفقی برای سریع‌کردن Epic است.
• Horror Story (aac): ناهمگام، atomic، choreographed؛ atomicity را بدون mediator و با پیام‌های خارج از ترتیب مطالبه می‌کند؛ پیچیدگی آن بسیار زیاد است و باید از آن دوری کرد.
• Parallel (aeo): ناهمگام، eventual، orchestrated؛ orchestrator خطا و workflow پیچیده را هدایت می‌کند، درحالی‌که تراکنش‌ها محلی‌اند؛ responsiveness و scale بالاست.
• Anthology (aec): ناهمگام، eventual، choreographed؛ کمترین coupling و بیشترین ظرفیت مقیاس، ولی برای workflowهای ساده با خطاهای کم مناسب‌تر است.

ماشین حالت و اداره‌پذیری

Saga بدون مدل state، فقط زنجیره‌ای مبهم از پیام‌هاست. finite state machine باید نقطهٔ شروع و پایان، stateهای میانی، transitionها، actionها، حالت انتظار و مسیرهای خطا را مشخص کند. نمونهٔ تیکت فصل نشان می‌دهد که «ایجاد»، «تخصیص»، «پذیرش»، «تکمیل»، «تخصیص مجدد» و «اعلان انجام‌نشده» باید همگی stateهای صریح باشند، نه شرط‌های پراکنده در کد.

این مدل مبنای retry، alert، repair دستی و تست است. همچنین ثبت روشن ارتباط هر سرویس با sagaها—مثلاً annotation یا metadata قابل‌کاوش—دامنهٔ اثر تغییر، تست لازم و مالکیت workflow را برای تیم قابل مشاهده می‌کند.

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

ابتدا بپرسید کدام اثر واقعاً باید پیش از پاسخ به کاربر قطعی باشد. اگر ارسال نظرسنجی پس از بسته‌شدن تیکت شکست بخورد، مجبورکردن کاربر به انتظار یا برگرداندن تکمیل تیکت معمولاً مدل کسب‌وکار بدتری است. در چنین موردی، state خطا و repair پس‌زمینه از compensation اتمیک معنادارتر است.

برای هر saga، transition table، idempotency، timeout، سیاست retry، مالک repair و مسیر escalat‌کردن به انسان را پیش از پیاده‌سازی تعیین کنید. الگوی ساده‌تر را فقط وقتی انتخاب کنید که با نیاز consistency سازگار است؛ asynchronous بودن به‌تنهایی یک بهینه‌سازی نیست، زیرا race condition، ترتیب پیام و قابلیت اطمینان صف را وارد مسئله می‌کند.

نکات کلیدی فصل

• Saga محصول انتخاب هم‌زمانِ ارتباط، consistency و coordination است؛ هیچ بُعدی را جداگانه بهینه نکنید.
• compensation تضمین rollback یا isolation نیست و خودش می‌تواند خطا کند.
• eventual consistency همراه با state management اغلب تجربهٔ کاربر و مقیاس‌پذیری بهتری می‌سازد.
• orchestrator برای workflow پیچیده مفید است؛ choreography برای جریان ساده و throughput بالا.
• state machine و ابزار مشاهده‌پذیری، بخشی از طراحی saga هستند نه مستندات اختیاری.

یادداشت‌های مترجم

• Saga، compensation، atomicity، eventual consistency و نام الگوها حفظ شده‌اند تا پیوند با ادبیات فنی و منابع پیاده‌سازی روشن بماند.
• کد سه‌حرفی الگوها به‌ترتیب نوع ارتباط، consistency و coordination را فشرده می‌کند.