aech
مفهوم Idempotent یعنی چیه؟ چرا این مفهوم همه جا دیده میشه؟
اگه یه مدتی برنامهنویسی کرده باشید، احتمالاً اسم Idempotent به گوشتون خورده. ممکنه این اصطلاح رو توی APIها، پایگاه داده، سیستمهای توزیعشده، صفهای پیام یا حتی ابزارهای DevOps دیده باشید. اما واقعاً Idempotent یعنی چی؟
بیاید با یه مثال ساده شروع کنیم.
فرض کنید یه کلید برق داریم که فقط وظیفهش روشن کردن چراغه. اگه چراغ خاموش باشه و کلید رو بزنید، چراغ روشن میشه. حالا اگه دوباره همون کلید رو بزنید چی میشه؟ هیچ اتفاق جدیدی نمیافته؛ چراغ همچنان روشنه.
مهم نیست این کار رو یک بار انجام بدید یا ده بار؛ نتیجهی نهایی همیشه یکیه. دقیقاً به چنین رفتاری میگن Idempotent.
حالا یه مثال برعکس.
فرض کنید دکمهای داریم که هر بار فشار دادنش، ۱۰۰ هزار تومان به موجودی کیف پول اضافه میکنه. بار اول موجودی ۱۰۰ هزار تومان زیاد میشه، بار دوم دوباره ۱۰۰ هزار تومان اضافه میشه و بار سوم هم همین اتفاق تکرار میشه.
اینجا هر بار اجرای عملیات، وضعیت سیستم رو تغییر میده. پس این عملیات Idempotent نیست.
تعریف رسمی Idempotent هم تقریباً همینه؛ اگه یه عملیات رو یک بار اجرا کنیم یا چند بار پشت سر هم، وضعیت نهایی سیستم باید یکسان باشه.
یه نکتهی مهم اینجاست که Idempotent بودن به این معنی نیست که خروجی عملیات همیشه یکی باشه. ممکنه هر بار اطلاعات متفاوتی برگرده، زمان اجرا فرق کنه یا حتی پیام متفاوتی نمایش داده بشه. چیزی که مهمه اینه که اجرای دوبارهی همون عملیات، وضعیت سیستم رو بیشتر از دفعهی اول تغییر نده.
یکی از اشتباههای رایج اینه که Idempotent رو با عملیاتی که هیچ تغییری ایجاد نمیکنه، اشتباه میگیرن. در حالی که یه عملیات Idempotent میتونه وضعیت سیستم رو تغییر بده؛ فقط این تغییر باید فقط بار اول اتفاق بیفته.
مثلاً اگه عملیاتی وضعیت یه کاربر رو از «غیرفعال» به «فعال» تغییر بده، بار اول وضعیت عوض میشه، اما اگه دوباره همون عملیات اجرا بشه، دیگه تغییری ایجاد نمیکنه.
پس این عملیات همچنان Idempotent محسوب میشه.
از اون طرف، عملیاتهایی مثل «افزایش موجودی»، «افزایش تعداد بازدید»، «ارسال ایمیل» یا «ثبت سفارش جدید» معمولاً Idempotent نیستن؛ چون هر بار اجرا شدنشون یه اثر جدید روی سیستم میذاره.
دلیل اهمیت Idempotent فقط سادهتر شدن منطق برنامه نیست.
توی سیستمهای واقعی همیشه ممکنه شبکه قطع بشه، درخواست Timeout بشه، کلاینت دوباره درخواست رو Retry کنه یا یه Job دوباره اجرا بشه.
اگه عملیات شما Idempotent باشه، دیگه مهم نیست همون عملیات چند بار اجرا بشه؛ نتیجهی نهایی تغییری نمیکنه و سیستم توی وضعیت درستی باقی میمونه.
به خاطر همین، این مفهوم تقریباً توی همهی شاخههای مهندسی نرمافزار دیده میشه؛ از طراحی APIها گرفته تا پایگاه داده، Message Queueها، Event-Driven Architecture، Infrastructure و حتی ابزارهای مدیریت سرور.
در نهایت، Idempotent یه تکنولوژی یا قابلیت خاص نیست؛ یه ویژگی برای طراحی عملیاته.
هر وقت بتونید عملیاتی طراحی کنید که اجرای دوبارهی اون، وضعیت نهایی سیستم رو تغییر نده، اون عملیات Idempotent محسوب میشه.
#programming #software_engineering
@Syntax_fa
25 · 1.8K ·