Idempotence یک ویژگی یک عملیات است که تضمین می کند، اگر عملیات یک یا چند بار تکرار شود، همان نتیجه را دریافت می کنید.

یک یا چند بار آن را بکار ببرید و نتیجه یکسان است، ناتوانی نام آن است.

جدا از همه قافیه ها، ناتوانی مفهوم مهمی است که اغلب در طراحی چیزهای روزمره استفاده می شود. اصل اساسی ناتوانی - جایی که اقدامات مکرر نتیجه را تغییر نمی دهد، فراتر از اقدام اولیه - به طور ضمنی یا صریح هم در دنیای فیزیکی و هم در دنیای دیجیتال محاسبات ابری و برنامه های کاربردی نرم افزار اعمال شده است.

این مقاله چند نمونه از ناتوانی در دنیای فیزیکی و همچنین نحوه استفاده از آن در معماری های نرم افزاری برای ساختن سیستم های قابل اعتماد و مقاوم به خطا را به شما نشان می دهد.

ناتوانی در دنیای فیزیکی

دکمه های Idempotent در سیستم های روزمره مانند دکمه های چراغ راهنمایی، دکمه توقف در اتوبوس های لندن و دکمه های تماس آسانسور استفاده می شوند.

فشار دادن چندباره دکمه چراغ راهنمایی باعث نمی شود که چراغ سریعتر تغییر کند - فقط یک بار نیاز به عبور عابر پیاده را ثبت می کند.

به همین ترتیب، فشار دادن دکمه توقف در اتوبوس لندن به راننده سیگنال می‌دهد که در ایستگاه بعدی توقف کند – اما چند بار فشار دادن آن مسیر اتوبوس را تغییر نمی‌دهد، توقف اتوبوس را سریع‌تر می‌کند یا درخواست توقف اولیه را لغو نمی‌کند.

الگوهای ناتوانی در معماری نرم افزار

الگوهای مختلف ناتوانی در معماری نرم افزار استفاده می شود. ما در اینجا به دو مورد محبوب خواهیم پرداخت.

طراحی API

در API های REST، روش های HTTP مانند GET، HEAD، PUT و DELETE ذاتاً فاقد قدرت هستند.

GET: برای بازیابی اطلاعات از یک سرور استفاده می شود. چندین درخواست GET به یک منبع امن هستند و باید همان داده ها را برگردانند، با این فرض که هیچ تغییری در این منبع ایجاد نشده است.

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

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

DELETE: یک منبع را حذف می کند. چندین بار حذف یک منبع منجر به یک نتیجه می شود: منبع پس از اولین درخواست موفقیت آمیز حذف می شود و درخواست های بعدی DELETE معمولاً وضعیت 404 Not Found یا 204 No Content را برمی گرداند که نشان می دهد هیچ منبعی برای حذف وجود ندارد.

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

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

چگونه یک عملیات POST Idempotent بسازیم

نمودار توالی زیر نحوه عملکرد الگوی PRG برای جلوگیری از سفارشات تکراری در یک برنامه وب تجارت الکترونیک را توضیح می دهد:

پست : زمانی که کاربر فرمی را برای ثبت سفارش ارسال می کند، مرورگر یک درخواست POST را به سرور ارسال می کند.

تغییر مسیر : پس از اینکه سرور درخواست POST را پردازش کرد (به عنوان مثال، سفارش را انجام داد)، یک پاسخ تغییر مسیر به مرورگر ارسال می کند، معمولاً با کد وضعیت HTTP 303/302، آن را به یک URL جدید هدایت می کند. این URL معمولاً یک صفحه تأیید سفارش است.

دریافت : سپس مرورگر یک درخواست GET به URL ارائه شده توسط تغییر مسیر می دهد. کاربر صفحه ای را می بیند که سفارش او را تایید می کند یا آنها را به حالت ایمن باز می گرداند که در آن هیچ سفارش تکراری به طور تصادفی ایجاد نمی شود.

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

این الگو با جلوگیری از اشتباهات رایج، مانند دوبار کلیک کردن روی دکمه ارسال یا تازه کردن صفحه، ایجاد سفارشات تکراری ناخواسته، تجربه کاربر را افزایش می دهد.

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

سیستم های صف پیام

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

این در سیستم‌های توزیع‌شده که در آن خرابی‌های شبکه، خرابی سیستم یا سایر مسائل می‌تواند منجر به پردازش چندباره یک پیام شود، بسیار مهم است.

بیایید به مثالی نگاه کنیم که شامل پرداخت است. هیچ مشتری نمی خواهد هنگام خرید تصادفاً دو بار شارژ شود، پس اطمینان از عدم توانایی سیستم بسیار مهم است.

صف پیام پیامی را به سیستم پرداخت ارسال می کند تا حساب را بدهکار کند.

این پیام دارای شناسه تراکنش منحصربفرد است. پایگاه داده شناسه های پردازش شده سابقه ای از شناسه تراکنش های پردازش شده را نگهداری می کند. سیستم پرداخت شناسه تراکنش را در مقابل پایگاه داده شناسه های پردازش شده تحلیل می کند و تحلیل می کند که آیا این پرداخت قبلاً پردازش شده است یا خیر.

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

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

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

در این مثال، سیستم بی‌توانی را با موارد زیر تضمین می‌کند:

تحلیل شناسه‌های تراکنش برای پرداخت‌های جدید در برابر پایگاه داده‌ای از پرداخت‌های قبلاً انجام شده

ارسال تاییدیه به صف پس از نادیده گرفتن پیام یا پردازش توسط سیستم پرداخت. پس تضمین می کند که همان پیام فقط یک بار به سیستم پرداخت ارسال می شود.

آوردن آن با هم

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

اصل اساسی ناتوانی در طراحی اشیاء روزمره که در دنیای فیزیکی با آنها تعامل داریم، از دکمه های چراغ راهنمایی برای عابران پیاده گرفته تا دکمه های تماس آسانسور استفاده می شود.

در دنیای انتزاعی معماری نرم‌افزار، idempotence تضمین می‌کند که عملیات مکرر همان اثری را که انجام آن عملیات فقط یک بار انجام می‌دهد، داشته باشد. Idempotence به ما اجازه می دهد تا معماری های قابل اعتماد و مقاوم در برابر خطا بسازیم.

خبرکاو