خب اول از همه یه اصطلاحی داریم که تو این سناریو اتفاق افتاده و بهش میگن Check-Then-Act
فرض کنید یک صندلی خالی تو سینما مونده. شما سایت رو باز میکنید و میبینید صندلی خالیه (مرحله Check). همزمان دوستتون هم با گوشی خودش همون صفحه رو باز میکنه و اونم میبینه صندلی خالیه. حالا جفتتون با هم دکمه «خرید» رو میزنید (مرحله Act). نتیجه چی میشه؟ جفتتون پول میدید اما فقط یک صندلی وجود داره!
توی برنامهنویسی به این مشکل میگن Race Condition (شرایط مسابقه). یعنی دو تا درخواست مثل دو تا ماشین مسابقه با هم کورس میذارن و چون سیستم فقط عمل «نگاه کردن» رو انجام داده، گول میخوره و به هر دو اجازه میده عملیات رو انجام بدن.
تو مثال پرداخت هم دقیقاً همین شد:
۱. درخواست اول میپرسه: کلید پرداخت هست؟ سیستم میگه: نه.
۲. درخواست دوم (در همون هزارم ثانیه) میپرسه: کلید پرداخت هست؟ سیستم میگه: نه.
۳. حالا هر دو درخواست میرن از حساب کاربر پول کم میکنن! (فاجعه دو بار کم شدن پول از حساب کاربر)
پس اگر جایی این اصطلاح رو شنیدین از امروز دیگ بلدشین که یه پترن برای پیاده سازی عه که عموما باعث ایجاد ریس کاندیشن میشه و چیز جالبی اصلا اصلا نیست و بهتره ازش هیچ وقت استفاده نکنین !
@codehalics | کدهالیک
Post #731
605
کدهالیک | codehalic سوال مصاحبه 👇 فرض کنید برای جلوگیری از اجرای تکراری عملیات پرداخت از Idempotency Key استفاده کردهاید. پیادهسازی فعلی به این شکل است: 1. بررسی میکنیم کلید وجود دارد یا نه 2. اگر وجود نداشت، عملیات پرداخت را انجام میدهیم 3. سپس کلید را ذخیره میکنیم …
- ❤ 2