نودجی اس | Nodejs | NestJS | javascript | جاوااسکریپت | typescript

اولین قسمت از تراکنش ها: Pessimistic 🆚 Optimistic قبلش اینو بگم اگه دوست داشتید این پلی لیست مفاهیم دیتابیس رو که قسمت چهارمش ACID هست رو مطالعه کنید بدون هیچ بحث اضافه دیگه ای بریم سر اصل مطلب ✅ توی Pessimistic Concurrency Control دیتابیس به صورت خیلی بدبینانه به تراکنش ها نگاه میکنه و این احتمال رو میده که تراکنش ها باهم تداخل داشته باشن پس میاد از سیستم lock اش استفاده میکنه ✅ فرض کنیم موجودی فعلی حساب ما 800 تاست و شخص A میخواد 200 تا برداشت کنه و شخص B هم 100 تا اضاف کنه ✅ اول ببینیم اگه دیتابیس چیزی رو lock نکنه و هردوتا درخواست همزمان برسه چی پیش میاد 🧐 🔹شخص A مبلغ 800 رو از دیتابیس میخونه و بعد 200 تومن ازش کم میکنه 🔹شخص B هم 800 تومن رو از دیتابیس میخونه(درحالیکه باید 600 میخوند) و 100 تا بهش اضاف میکنه حالا نتیجه نهایی ما به جای 700 میشه 900😱 اینجوری خیلی خوشبحال طرف میشه نه؟😎 ✅ حالا اگه دیتابیس از سیستم lock استفاده کنه و به صورت بدبینانه نگاه کنه چطور؟🤔 درخواست شخص A به دیتابیس ارسال میشه اما اینجا دیتابیس میگه وایسا وایسا من باید اول حسابتو lock کنم تا تراکنش دیگه ای همزمان اعمال نشه حالا: شخص A مقدار 800 تومن رو از دیتابیس میخونه و 200 تومن از حساب کم میکنه پس موجودی میشه 600 تومن ✅ حالا lock ازاد میشه درخواست شخص B میرسه و دوباره دیتابیس lock میکنه. اینبار 600 رو از دیتابیس میخونه و 100 تومن رو اضافه میکنه و در اخر موجودی حساب ما میشه 700(نه 900)🥳 ☝️حالا کجا خوبه ؟ کجا بده؟ اونجایی خوبه که تراکنش ها زیاد دچار تداخل میشن و اونجایی بده که این قفل کردن های مکرر باعث کندی سیستم ما بشه ✅ چطور توی کد نویسی اعمالش کنیم؟ با استفاده از کوعری به اسم for update میتونی اعمالش کنی به chat GPT بگی برات کدشو به هر زبونی که دلته میزنه🤩 اونجا هست که توی سایت دیجی کالا میزنه فقط یه دونه کالا توی انباره؟ و همزمان چند نفر درخواست خرید میکنن؟اونجاست که بکار میاد😏 ✅ حالا بریم سراغ Optimistic Concurrency Control ✅ توی این روش دیتابیس ما پسر خوبی شده و خیلی خوشبینانه به موضوع نگاه میکنه و پیش خودش میگه بعید بدونم دوتا درخواست همزمان بیاد سمتم. ولی در عوضش توی برنامه نویس بیا یه زحمتی بکش برای جدولت یه ستون به اسم version بزار که توی هر تراکنش اونو اپدیت کنیم و اینطوری از تداخل درخواست ها جلوگیری کنیم ✅ یعنی چک کنیم ایا ورژن همون ورژنه یا عوض شده؟ اگه عوض شده که خب درخواست میره تو دیوار اگه همون بود پس تراکنش رو انجام بده و بعد یکی بهش اضاف کن (ورژن فعلی رو 0 در نظر بگیرید) ✅ طبق مثال قبل فرض کنیم موجودی حساب ما 800 هست و شخص A میخواد 200 برداشت کنه و شخص B هم 100 اضاف کنه درخواست A و B همزمان به دیتابیس میرسه 1⃣ مرحله اول شروع تراکنش ها: به صورت همزمان شخص A و B موجودی و version رو از دیتابیس میخونن 2⃣ مرحله دوم پردازش تراکنش ها: به صورت همزمان شخص A مبلغ 800 تومن رو میخونه و 200 تا ازش کم میکنه و شخص B هم 800 تومن رو میخونه و 100 تومن بهش اضاف میکنه ولی دقت کنید که فقط محسابه انجام میشه و هنوز چیزی توی دیتابیس commit نشده 3⃣ مرحله سوم کامیت: ابتدا شخص A ورژن رو چک میکنه که ایا با ورژن خودش برابر یا نه(فرض کنیم برابره) پس commit انجام میشه و موجودی حساب میشه 600 و حالا یه دونه به ورژن اضاف میکنه، پس ورژن ما از 0 میشه 1 ✅ حالا شخص B ورژن رو چک میکنه و میبینه عه عه، ور چه ژنی؟ ورژن خودش 0 عه در حالی که ورژن ردیف مورد نظرش توسط تراکنش دیگه ای تغییر کرده و شده 1 پس کامیت انجام نمیشه و درخواست B به دیوار میخوره🥴 ✅ در نتیجه شخص B خطا بهش برمیگرده و باید دوباره درخواست رو بفرسته ✅ برای بار دوم که درخواست میره، دوباره موجودی (که 600عه) و version رو میخونه ولی اینبار دیگه ورژن ها اوکی هستن پس اعمال میشه و موجودی ما میشه 700 و دوباره ورژن یکی بهش اضاف میشه ✅ پس بدون اینکه قفلی از طرف دیتابیس اعمال بشه تونستیم تداخل تراکنش هارو مدیریت کنیم و چون lockایی درکار نیست سرعت بالاتر رفته، اما از اون طرف یکی از درخواست هامون همیشه میره تو دیوار ✅ پست بعدی وارد دنیای distributed ها میشیم و میریم سراغ outbox pattern 😎 @LearnByLearn #transaction #concurrency