💎توضیح Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock 💎
خب بچهها امروز میخوایم درباره چند تا مشکل رایج توی تراکنشهای دیتابیس حرف بزنیم که ممکنه به دردتون بخوره. وقتی چند تا تراکنش به صورت همزمان توی دیتابیس کار میکنن، بعضی وقتا اتفاقای غیرمنتظرهای میافته که ممکنه به بینظمی و باگ منجر بشه. این مشکلات شامل Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock هستن. بیاید دونه دونه بررسیشون کنیم.
اول Dirty Read 💾
خب Dirty Read یعنی وقتی یه تراکنش دادههایی رو میخونه که هنوز توسط یه تراکنش دیگه نهایی (commit) نشده. این یعنی شما دارید چیزی رو میخونید که ممکنه عوض بشه یا حتی برگرده.
مثال: فرض کن یکی توی اپلیکیشن شما داره اطلاعات یه سفارش رو تغییر میده ولی هنوز تغییرات رو ذخیره نکرده. حالا یه کاربر دیگه همون سفارش رو میبینه و تصمیم میگیره. اگر اون تغییرات نهایی نشن، اطلاعات اشتباهی به کاربر دوم رسیده.
دوم Non-Repeatable Read 🔄
خب Non-Repeatable Read وقتی پیش میاد که یه تراکنش، دادهای رو چند بار میخونه و دفعههای بعدی اون داده فرق میکنه، چون یه تراکنش دیگه اومده و اون داده رو وسط کار تغییر داده.
مثال: شما قیمت یه محصول رو برای یه مشتری نشون میدید. همزمان یه کاربر دیگه قیمت همون محصول رو تغییر میده. وقتی مشتری دوباره صفحه رو رفرش کنه، قیمت متفاوتی میبینه.
سوم Phantom Read 👻
خب Phantom Read یعنی وقتی یه تراکنش یه مجموعه داده رو میخونه و در طول اجرای تراکنش، رکوردهای جدیدی به اون مجموعه اضافه یا حذف میشن. اینطوری وقتی دوباره همون پرسوجو رو انجام بدی، نتیجه متفاوتی میبینی.
مثال: فرض کن یه مدیر داره تعداد کارمندای یک بخش رو چک میکنه. در همون لحظه یکی دیگه یه کارمند جدید به همون بخش اضافه میکنه. حالا اگر مدیر دوباره تعداد کارمندها رو ببینه، یه کارمند جدید میاد توی لیست که دفعه قبل نبوده.
چهارم Deadlock 🔐
خب Deadlock وقتی اتفاق میافته که دو یا چند تراکنش همزمان منتظر همدیگه بمونن و نتونن کاری کنن. یعنی تراکنشها همدیگه رو قفل میکنن و نمیتونن ادامه بدن.
مثال: فرض کن تراکنش A میخواد رکورد ۱ رو قفل کنه و منتظر رکورد ۲ هم هست. همزمان تراکنش B رکورد ۲ رو قفل کرده و منتظر رکورد ۱ هست. اینجا تراکنشها همدیگه رو بلاک کردن و هیچکدوم نمیتونن کاری بکنن.
جمع بندی 🎯
اینا مشکلات رایجی هستن که توی مدیریت تراکنشها و همزمانی توی دیتابیسها رخ میده. با فهمیدن و شناسایی این مشکلات میتونید از بروز مشکلات جدی توی سیستمهای دیتابیسی جلوگیری کنید و عملکرد بهتری داشته باشید.
امیدوارم مفید بوده باشه :)
@ninja_learn_ir
خب بچهها امروز میخوایم درباره چند تا مشکل رایج توی تراکنشهای دیتابیس حرف بزنیم که ممکنه به دردتون بخوره. وقتی چند تا تراکنش به صورت همزمان توی دیتابیس کار میکنن، بعضی وقتا اتفاقای غیرمنتظرهای میافته که ممکنه به بینظمی و باگ منجر بشه. این مشکلات شامل Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock هستن. بیاید دونه دونه بررسیشون کنیم.
اول Dirty Read 💾
خب Dirty Read یعنی وقتی یه تراکنش دادههایی رو میخونه که هنوز توسط یه تراکنش دیگه نهایی (commit) نشده. این یعنی شما دارید چیزی رو میخونید که ممکنه عوض بشه یا حتی برگرده.
مثال: فرض کن یکی توی اپلیکیشن شما داره اطلاعات یه سفارش رو تغییر میده ولی هنوز تغییرات رو ذخیره نکرده. حالا یه کاربر دیگه همون سفارش رو میبینه و تصمیم میگیره. اگر اون تغییرات نهایی نشن، اطلاعات اشتباهی به کاربر دوم رسیده.
دوم Non-Repeatable Read 🔄
خب Non-Repeatable Read وقتی پیش میاد که یه تراکنش، دادهای رو چند بار میخونه و دفعههای بعدی اون داده فرق میکنه، چون یه تراکنش دیگه اومده و اون داده رو وسط کار تغییر داده.
مثال: شما قیمت یه محصول رو برای یه مشتری نشون میدید. همزمان یه کاربر دیگه قیمت همون محصول رو تغییر میده. وقتی مشتری دوباره صفحه رو رفرش کنه، قیمت متفاوتی میبینه.
سوم Phantom Read 👻
خب Phantom Read یعنی وقتی یه تراکنش یه مجموعه داده رو میخونه و در طول اجرای تراکنش، رکوردهای جدیدی به اون مجموعه اضافه یا حذف میشن. اینطوری وقتی دوباره همون پرسوجو رو انجام بدی، نتیجه متفاوتی میبینی.
مثال: فرض کن یه مدیر داره تعداد کارمندای یک بخش رو چک میکنه. در همون لحظه یکی دیگه یه کارمند جدید به همون بخش اضافه میکنه. حالا اگر مدیر دوباره تعداد کارمندها رو ببینه، یه کارمند جدید میاد توی لیست که دفعه قبل نبوده.
چهارم Deadlock 🔐
خب Deadlock وقتی اتفاق میافته که دو یا چند تراکنش همزمان منتظر همدیگه بمونن و نتونن کاری کنن. یعنی تراکنشها همدیگه رو قفل میکنن و نمیتونن ادامه بدن.
مثال: فرض کن تراکنش A میخواد رکورد ۱ رو قفل کنه و منتظر رکورد ۲ هم هست. همزمان تراکنش B رکورد ۲ رو قفل کرده و منتظر رکورد ۱ هست. اینجا تراکنشها همدیگه رو بلاک کردن و هیچکدوم نمیتونن کاری بکنن.
جمع بندی 🎯
اینا مشکلات رایجی هستن که توی مدیریت تراکنشها و همزمانی توی دیتابیسها رخ میده. با فهمیدن و شناسایی این مشکلات میتونید از بروز مشکلات جدی توی سیستمهای دیتابیسی جلوگیری کنید و عملکرد بهتری داشته باشید.
#db #dead_lock #programing
❤34
دوستان ۶۸۶ نفریم ولی واقعا کسی حمایت نمیکنه. 🙃
ممنون میشیم برای این که انرژی بگیریم و بیشتر فعالیت کنیم لایک و شیر کنید ومارو به دوستانتون معرفی کنید. 🙂
با تشکر از همگی ❤️
ممنون میشیم برای این که انرژی بگیریم و بیشتر فعالیت کنیم لایک و شیر کنید ومارو به دوستانتون معرفی کنید. 🙂
با تشکر از همگی ❤️
❤73🔥4👍3☃1
💎 چطوری مشکلات Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock رو هندل کنیم؟ 💎
توی پست قبلی درباره چند تا مشکل مثل Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock حرف زدیم. امروز میخوایم ببینیم چطوری میتونیم اینا رو توی برنامهمون هندل کنیم. اینا مشکلاتیه که میتونن عملکرد دیتابیس و اپلیکیشن رو خراب کنن، ولی با استفاده از تکنیکهای کنترل همزمانی و ایزولیشن میشه جلوی اینا رو گرفت.
1⃣ Dirty Read 💾
برای جلوگیری از Dirty Read، باید از سطح ایزولیشن مناسبی استفاده کنیم. یکی از بهترین سطوح ایزولیشن برای این کار Read Committed هست. این سطح تضمین میکنه که فقط دادههای commit شده قابل خوندن هستن.
مثال:
فرض کن توی دیتابیستون از سطح ایزولیشن Read Committed استفاده میکنی. اگه تراکنش A داره دادههایی رو آپدیت میکنه، تراکنش B تا وقتی که A کارش تموم نشده و دادهها رو commit نکرده، نمیتونه اون دادهها رو ببینه. پس از Dirty Read جلوگیری میشه.
2⃣ Non-Repeatable Read 🔄
برای جلوگیری از Non-Repeatable Read، باید سطح ایزولیشن رو به Repeatable Read تغییر بدیم. این سطح ایزولیشن تضمین میکنه که اگر یک بار دادهای رو توی تراکنش خوندیم، تا پایان تراکنش دیگه تغییر نمیکنه.
مثال:
فرض کن توی یه فروشگاه آنلاین، وقتی یه کاربر قیمت یه محصول رو چک میکنه، باید مطمئن بشی که اون قیمت تا پایان تراکنش تغییر نمیکنه. با استفاده از Repeatable Read، هر چی کاربر دید، همون میمونه.
3⃣ Phantom Read 👻
برای حل مشکل Phantom Read باید از سطح ایزولیشن Serializable استفاده کنیم. این سطح از ایزولیشن باعث میشه که نه تنها دادههای موجود، بلکه هر داده جدیدی هم تا پایان تراکنش دیده نشه.
مثال:
فرض کن یه مدیر داره گزارش تعداد کارمندای یه بخش رو چک میکنه. با سطح ایزولیشن Serializable، اگر کارمند جدیدی در طول تراکنش اضافه بشه، مدیر اون رو تا پایان تراکنش نمیبینه و از Phantom Read جلوگیری میشه.
4⃣ Deadlock 🔐
برای هندل کردن Deadlock، چند راه وجود داره:
1⃣ اجتناب از قفلهای طولانی:
تراکنشها رو سبک و سریع نگه دار تا قفلهای طولانی ایجاد نشن.
2⃣ ترتیب دسترسی یکسان:
مطمئن شو که تراکنشها به منابع به یه ترتیب دسترسی پیدا میکنن. یعنی اگر A و B هر دو به رکوردهای ۱ و ۲ نیاز دارن، هر دو اول رکورد ۱ رو قفل کنن و بعد برن سراغ رکورد ۲.
3⃣ زمانبندی دوباره تراکنشها:
میتونی از دیتابیس بخوای که اگه Deadlock تشخیص داد، یکی از تراکنشها رو ریست کنه و دوباره اجرا کنه.
مثال:
فرض کن توی اپلیکیشن مالیات دو تراکنش همزمان دارن از منابع یکسان استفاده میکنن. یکی از راههای جلوگیری از Deadlock اینه که مطمئن بشی تراکنشها به یه ترتیب مشخص به منابع دسترسی دارن، مثلاً اول رکورد ۱ رو قفل میگیرن و بعد رکورد ۲.
جمعبندی 🎯
با استفاده از سطوح ایزولیشن و یه سری تکنیکهای مدیریت تراکنش، میتونیم مشکلاتی مثل Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock رو توی دیتابیسهامون حل کنیم. اگر این نکات رو توی اپلیکیشنهاتون رعایت کنید، کارتون خیلی راحتتر و پایدارتر میشه.
امید وارم مفید بوده باشه :)
@ninja_learn_ir
توی پست قبلی درباره چند تا مشکل مثل Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock حرف زدیم. امروز میخوایم ببینیم چطوری میتونیم اینا رو توی برنامهمون هندل کنیم. اینا مشکلاتیه که میتونن عملکرد دیتابیس و اپلیکیشن رو خراب کنن، ولی با استفاده از تکنیکهای کنترل همزمانی و ایزولیشن میشه جلوی اینا رو گرفت.
1⃣ Dirty Read 💾
برای جلوگیری از Dirty Read، باید از سطح ایزولیشن مناسبی استفاده کنیم. یکی از بهترین سطوح ایزولیشن برای این کار Read Committed هست. این سطح تضمین میکنه که فقط دادههای commit شده قابل خوندن هستن.
مثال:
فرض کن توی دیتابیستون از سطح ایزولیشن Read Committed استفاده میکنی. اگه تراکنش A داره دادههایی رو آپدیت میکنه، تراکنش B تا وقتی که A کارش تموم نشده و دادهها رو commit نکرده، نمیتونه اون دادهها رو ببینه. پس از Dirty Read جلوگیری میشه.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
2⃣ Non-Repeatable Read 🔄
برای جلوگیری از Non-Repeatable Read، باید سطح ایزولیشن رو به Repeatable Read تغییر بدیم. این سطح ایزولیشن تضمین میکنه که اگر یک بار دادهای رو توی تراکنش خوندیم، تا پایان تراکنش دیگه تغییر نمیکنه.
مثال:
فرض کن توی یه فروشگاه آنلاین، وقتی یه کاربر قیمت یه محصول رو چک میکنه، باید مطمئن بشی که اون قیمت تا پایان تراکنش تغییر نمیکنه. با استفاده از Repeatable Read، هر چی کاربر دید، همون میمونه.
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
3⃣ Phantom Read 👻
برای حل مشکل Phantom Read باید از سطح ایزولیشن Serializable استفاده کنیم. این سطح از ایزولیشن باعث میشه که نه تنها دادههای موجود، بلکه هر داده جدیدی هم تا پایان تراکنش دیده نشه.
مثال:
فرض کن یه مدیر داره گزارش تعداد کارمندای یه بخش رو چک میکنه. با سطح ایزولیشن Serializable، اگر کارمند جدیدی در طول تراکنش اضافه بشه، مدیر اون رو تا پایان تراکنش نمیبینه و از Phantom Read جلوگیری میشه.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
4⃣ Deadlock 🔐
برای هندل کردن Deadlock، چند راه وجود داره:
1⃣ اجتناب از قفلهای طولانی:
تراکنشها رو سبک و سریع نگه دار تا قفلهای طولانی ایجاد نشن.
2⃣ ترتیب دسترسی یکسان:
مطمئن شو که تراکنشها به منابع به یه ترتیب دسترسی پیدا میکنن. یعنی اگر A و B هر دو به رکوردهای ۱ و ۲ نیاز دارن، هر دو اول رکورد ۱ رو قفل کنن و بعد برن سراغ رکورد ۲.
3⃣ زمانبندی دوباره تراکنشها:
میتونی از دیتابیس بخوای که اگه Deadlock تشخیص داد، یکی از تراکنشها رو ریست کنه و دوباره اجرا کنه.
مثال:
فرض کن توی اپلیکیشن مالیات دو تراکنش همزمان دارن از منابع یکسان استفاده میکنن. یکی از راههای جلوگیری از Deadlock اینه که مطمئن بشی تراکنشها به یه ترتیب مشخص به منابع دسترسی دارن، مثلاً اول رکورد ۱ رو قفل میگیرن و بعد رکورد ۲.
BEGIN TRANSACTION;
-- Lock resources in the same order
جمعبندی 🎯
با استفاده از سطوح ایزولیشن و یه سری تکنیکهای مدیریت تراکنش، میتونیم مشکلاتی مثل Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock رو توی دیتابیسهامون حل کنیم. اگر این نکات رو توی اپلیکیشنهاتون رعایت کنید، کارتون خیلی راحتتر و پایدارتر میشه.
#sql #dead_lock #programing
🔥12❤4👍1
Ninja Learn | نینجا لرن
💎 چطوری مشکلات Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock رو هندل کنیم؟ 💎 توی پست قبلی درباره چند تا مشکل مثل Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock حرف زدیم. امروز میخوایم ببینیم چطوری میتونیم اینا رو توی برنامهمون هندل…
دوستان اگه سوالی درمورد پستا دارید یا مطلبی رو خوب متوجه نشدید و براتون جانیفتاده حتما تو کامنتا بپرسید تا براتپن توضیح بدیم 😊
1❤6
آیا لازمه بهعنوان یه بکاند دولوپر، DevOps بلد باشیم؟ 🤔
این سوال خیلی از بچههایی که تو زمینه بکاند کار میکنن هست که "آیا لازمه DevOps هم یاد بگیریم یا نه؟".
خب جواب سادهاش اینه:
بله، ولی بستگی داره چقدر! بیایید یه نگاه دقیقتر بندازیم.
چرا DevOps؟
خب DevOps یه فرایند برای اینه که فاصله بین توسعهدهندهها (مثل ما که کد میزنیم) و تیمهای عملیات (کسایی که کد رو روی سرورها اجرا میکنن) کمتر بشه.
اگه شما بهعنوان یه بکاند دولوپر، کمی از DevOps سر دربیاری، این به معنیه که میتونی توی مراحل دیپلویمنت و مدیریت پروژه نقش فعالتری داشته باشی و کدت رو با خیال راحتتری بیاری بالا. این یعنی کمتر وابسته به تیمهای دیگهای و سریعتر مشکلات رو هندل میکنی.
چقدر باید بلد باشیم؟ 📚
حالا سوال مهم اینه: چقدر باید DevOps بلد باشیم؟
نمیخواد یه متخصص کامل DevOps باشی، ولی دونستن چند تا موضوع پایهای کمک زیادی بهت میکنه:
1⃣ کار با Git و CI/CD: دونستن نحوه کار با ابزارهای CI/CD (مثل Jenkins یا GitLab CI) خیلی ضروریه. چون کدایی که مینویسی باید خودکار تست و دیپلوی بشن.
مثال: فرض کن شما کدت رو نوشتی و از طریق یه لوله CI/CD خودکار تست میشه و اگر همه چی اوکی باشه، روی سرور دیپلوی میشه. با این کار خیالت راحتتره که چیزی خراب نشده.
2⃣ آشنایی با Docker: دیگه این روزا کار کردن بدون Docker سخته. بهتره بدونی چطور اپت رو داخل کانتینرهای Docker ببری و اجرا کنی.
مثال: اگه بخوای برنامهات رو سریع روی چندتا سیستم مختلف بدون مشکل اجرا کنی، Docker میتونه مثل یه قهرمان کمکت کنه.
3⃣ کار با سرورها: حداقل باید با محیطهای Linux و مدیریت سرورهای ساده آشنا باشی. مثلاً بدونی چطور سرویسها رو استارت کنی، لاگها رو بخونی و یه سری دستورات پایهای رو بزنی.
مثال: فرض کن اپت روی یه سرور مشکل پیدا کرده و لاگ ارورها رو میخونی تا سریع تر مشکل رو پیدا کنی. اگر اصولی بلد نباشی، باید منتظر بمونی تا یکی دیگه بیاد کمکت کنه.
4⃣ مدیریت کانفیگها: ابزارهایی مثل Ansible یا Terraform برای مدیریت و اتوماسیون کانفیگ سرورها کمک بزرگی هستن. ولی اگه تو محیطهای کوچیک کار میکنی، حتی آشنایی با دستورای ساده Bash هم کافیه.
جمع بندی 🎯
در نهایت، اگه بکاند دولوپری هستی، دونستن مباحث DevOps بهت کمک میکنه مستقلتر و قویتر عمل کنی. لازم نیست همهچیز رو فول باشی، اما آشنایی با اصول و ابزارهای پایهای مثل Docker، Git، CI/CD و مدیریت سرورهای لینوکسی کارتو راحتتر میکنه.
هر چی بیشتر بلد باشی، هم برای خودت بهتره، هم توی تیم میدرخشی. 😎
امید وارم مفید بوده باشه :)
@ninja_learn_ir
این سوال خیلی از بچههایی که تو زمینه بکاند کار میکنن هست که "آیا لازمه DevOps هم یاد بگیریم یا نه؟".
خب جواب سادهاش اینه:
بله، ولی بستگی داره چقدر! بیایید یه نگاه دقیقتر بندازیم.
چرا DevOps؟
خب DevOps یه فرایند برای اینه که فاصله بین توسعهدهندهها (مثل ما که کد میزنیم) و تیمهای عملیات (کسایی که کد رو روی سرورها اجرا میکنن) کمتر بشه.
اگه شما بهعنوان یه بکاند دولوپر، کمی از DevOps سر دربیاری، این به معنیه که میتونی توی مراحل دیپلویمنت و مدیریت پروژه نقش فعالتری داشته باشی و کدت رو با خیال راحتتری بیاری بالا. این یعنی کمتر وابسته به تیمهای دیگهای و سریعتر مشکلات رو هندل میکنی.
چقدر باید بلد باشیم؟ 📚
حالا سوال مهم اینه: چقدر باید DevOps بلد باشیم؟
نمیخواد یه متخصص کامل DevOps باشی، ولی دونستن چند تا موضوع پایهای کمک زیادی بهت میکنه:
1⃣ کار با Git و CI/CD: دونستن نحوه کار با ابزارهای CI/CD (مثل Jenkins یا GitLab CI) خیلی ضروریه. چون کدایی که مینویسی باید خودکار تست و دیپلوی بشن.
مثال: فرض کن شما کدت رو نوشتی و از طریق یه لوله CI/CD خودکار تست میشه و اگر همه چی اوکی باشه، روی سرور دیپلوی میشه. با این کار خیالت راحتتره که چیزی خراب نشده.
2⃣ آشنایی با Docker: دیگه این روزا کار کردن بدون Docker سخته. بهتره بدونی چطور اپت رو داخل کانتینرهای Docker ببری و اجرا کنی.
مثال: اگه بخوای برنامهات رو سریع روی چندتا سیستم مختلف بدون مشکل اجرا کنی، Docker میتونه مثل یه قهرمان کمکت کنه.
3⃣ کار با سرورها: حداقل باید با محیطهای Linux و مدیریت سرورهای ساده آشنا باشی. مثلاً بدونی چطور سرویسها رو استارت کنی، لاگها رو بخونی و یه سری دستورات پایهای رو بزنی.
مثال: فرض کن اپت روی یه سرور مشکل پیدا کرده و لاگ ارورها رو میخونی تا سریع تر مشکل رو پیدا کنی. اگر اصولی بلد نباشی، باید منتظر بمونی تا یکی دیگه بیاد کمکت کنه.
4⃣ مدیریت کانفیگها: ابزارهایی مثل Ansible یا Terraform برای مدیریت و اتوماسیون کانفیگ سرورها کمک بزرگی هستن. ولی اگه تو محیطهای کوچیک کار میکنی، حتی آشنایی با دستورای ساده Bash هم کافیه.
جمع بندی 🎯
در نهایت، اگه بکاند دولوپری هستی، دونستن مباحث DevOps بهت کمک میکنه مستقلتر و قویتر عمل کنی. لازم نیست همهچیز رو فول باشی، اما آشنایی با اصول و ابزارهای پایهای مثل Docker، Git، CI/CD و مدیریت سرورهای لینوکسی کارتو راحتتر میکنه.
هر چی بیشتر بلد باشی، هم برای خودت بهتره، هم توی تیم میدرخشی. 😎
#backend #devops
1👍24❤5
پست پیشنهادی دارید؟ 🌚 (لطف چیزی باشه که بشه درقالب پست اراعه داد)
❤7
ـ Dependency Injection چیه؟ 🤔
امروز میخوایم بررسی کنیم Dependency Injection یا همون تزریق وابستگی چیه
خب Dependency injection یه مفهومی توی برنامهنویسی شیگراست که به سادهترین شکل میشه گفت برای جداسازی وابستگیها بین کلاسها استفاده میشه. یعنی چی؟ یعنی به جای اینکه هر کلاس خودش مستقلاً وابستگیهای مورد نیازش رو بسازه، این وابستگیها از بیرون بهش تزریق میشه. این کار باعث میشه کد ما تمیزتر، انعطافپذیرتر و قابل تستتر بشه.
چرا مهمه؟ 🤨
فرض کن یه کلاس داری که برای کارکردش نیاز به یه سری سرویسهای دیگه داره. مثلاً کلاسی که مسئول لاگین کاربره، نیاز به سرویس دیتابیس داره. حالا اگه این سرویس رو خود کلاس بسازه، دیگه وابستگی محکمی بین این دو تا وجود داره. یعنی هر وقت بخوای دیتابیس رو عوض کنی، باید بری توی این کلاس دست ببری. اما اگه از Dependency Injection استفاده کنی، میتونی هر وقت خواستی به این کلاس هر دیتابیسی که دوست داری تزریق کنی، بدون اینکه نیاز باشه توی کدش تغییری بدی.
یه مثال ساده 🤓
فرض کن کلاس زیر رو داری که برای ارسال پیام نیاز به یه سرویس پیامرسان داره:
اینجا کلاس
حالا با استفاده از Dependency Injection اینجوری مینویسیمش:
تو این حالت،
مزایای Dependency Injection 📈
1⃣ قابلیت تست بیشتر: چون وابستگیها از بیرون تزریق میشن، میتونی راحتتر mock کنی و تست بنویسی.
2⃣ انعطافپذیری بیشتر: راحت میتونی وابستگیهای مختلف رو جایگزین کنی بدون اینکه توی کلاس تغییر بدی.
3⃣ کاهش coupling: وابستگی بین کلاسها کمتر میشه و این باعث میشه کدات مستقلتر باشن.
جمعبندی 🎯
فهمیدیم که Dependency Injection بهت کمک میکنه که کدهای تمیزتری داشته باشی که راحتتر تست و اپدیت میشن. خیلی وقتا که بخوای یه اپلیکیشن بزرگ و مقیاسپذیر بنویسی، این الگو میتونه کارتو خیلی راحتتر کنه. پس دفعه بعد که داشتی کد میزدی و حس کردی یه کلاس داره زیادی به کلاسهای دیگه وابسته میشه، به فکر استفاده از این روش باش 😉
ممنون میشم با ریکشن و شیر از ما حمایت کنید :) ❤️🔥
@ninja_learn_ir
امروز میخوایم بررسی کنیم Dependency Injection یا همون تزریق وابستگی چیه
خب Dependency injection یه مفهومی توی برنامهنویسی شیگراست که به سادهترین شکل میشه گفت برای جداسازی وابستگیها بین کلاسها استفاده میشه. یعنی چی؟ یعنی به جای اینکه هر کلاس خودش مستقلاً وابستگیهای مورد نیازش رو بسازه، این وابستگیها از بیرون بهش تزریق میشه. این کار باعث میشه کد ما تمیزتر، انعطافپذیرتر و قابل تستتر بشه.
چرا مهمه؟ 🤨
فرض کن یه کلاس داری که برای کارکردش نیاز به یه سری سرویسهای دیگه داره. مثلاً کلاسی که مسئول لاگین کاربره، نیاز به سرویس دیتابیس داره. حالا اگه این سرویس رو خود کلاس بسازه، دیگه وابستگی محکمی بین این دو تا وجود داره. یعنی هر وقت بخوای دیتابیس رو عوض کنی، باید بری توی این کلاس دست ببری. اما اگه از Dependency Injection استفاده کنی، میتونی هر وقت خواستی به این کلاس هر دیتابیسی که دوست داری تزریق کنی، بدون اینکه نیاز باشه توی کدش تغییری بدی.
یه مثال ساده 🤓
فرض کن کلاس زیر رو داری که برای ارسال پیام نیاز به یه سرویس پیامرسان داره:
class NotificationService:
def __init__(self):
self.sender = EmailSender()
def send(self, message):
self.sender.send(message)
اینجا کلاس
NotificationService
مستقیم وابسته به EmailSender
هست، یعنی اگه بعداً بخوای از یه روش دیگه برای ارسال پیام (مثلاً SMSSender
) استفاده کنی، باید بری کد این کلاس رو تغییر بدی. این باعث میشه کدات به هم گره بخورن و انعطافپذیری کم بشه.حالا با استفاده از Dependency Injection اینجوری مینویسیمش:
class NotificationService:
def __init__(self, sender):
self.sender = sender
def send(self, message):
self.sender.send(message)
تو این حالت،
sender
(که میتونه EmailSender
، SMSSender
یا هر چیز دیگهای باشه) از بیرون به NotificationService
تزریق میشه. حالا اگه بخوای نوع ارسال پیام رو تغییر بدی، فقط کافیه یه شیء جدید بهش تزریق کنی:email_sender = EmailSender()
sms_sender = SMSSender()
notification = NotificationService(email_sender) # استفاده از ایمیل
notification.send("Hello via Email!")
notification_sms = NotificationService(sms_sender) # استفاده از SMS
notification_sms.send("Hello via SMS!")
مزایای Dependency Injection 📈
1⃣ قابلیت تست بیشتر: چون وابستگیها از بیرون تزریق میشن، میتونی راحتتر mock کنی و تست بنویسی.
2⃣ انعطافپذیری بیشتر: راحت میتونی وابستگیهای مختلف رو جایگزین کنی بدون اینکه توی کلاس تغییر بدی.
3⃣ کاهش coupling: وابستگی بین کلاسها کمتر میشه و این باعث میشه کدات مستقلتر باشن.
جمعبندی 🎯
فهمیدیم که Dependency Injection بهت کمک میکنه که کدهای تمیزتری داشته باشی که راحتتر تست و اپدیت میشن. خیلی وقتا که بخوای یه اپلیکیشن بزرگ و مقیاسپذیر بنویسی، این الگو میتونه کارتو خیلی راحتتر کنه. پس دفعه بعد که داشتی کد میزدی و حس کردی یه کلاس داره زیادی به کلاسهای دیگه وابسته میشه، به فکر استفاده از این روش باش 😉
#programing #backend
❤23
💎 مدل MVCC در دیتابیس Postgres 💎
postgres یه سری ابزارای قوی داره برای اینکه توسعهدهندهها بتونن دسترسی همزمان به دادهها رو مدیریت کنن. این سیستم به صورت داخلی از یه مدل به اسم MVCC استفاده میکنه (که مخفف Multiversion Concurrency Control هست) تا سازگاری دادهها رو حفظ کنه. به این معنی که هر دستور SQL یه نمای کلی از دادهها رو میبینه (مثل یه نسخه از دیتابیس)، انگار که دادهها مال یه زمان قبلی هستن و ربطی به حالت فعلی دادهها ندارن. اینطوری باعث میشه که تو یه شرایط همزمانی، وقتی چند دستور دارن رو دادهها کار میکنن، نسخههای مختلفی از داده دیده بشه و تضادی بینشون پیش نیاد و هر سشن تو دیتابیس مستقل بمونه. MVCC با نداشتن قفلهای پیچیده، پرفورمنس سیستم رو برای محیطهایی که چندین کاربر همزمان دارن استفاده میکنن بالا میبره و جلوی ازدحام قفلها رو میگیره.
مزیت اصلی MVCC نسبت به روشهای قفلگذاری اینه که وقتی دادهها برای خوندن قفل میشن، این قفلها با قفلهایی که برای نوشتن دادهها لازمه تداخل ندارن. یعنی وقتی یه کاربر داره داده رو میخونه، جلوی نوشتن داده توسط کاربر دیگه رو نمیگیره و برعکس. پستگرس حتی وقتی شدیدترین حالت ایزولهسازی تراکنش رو فعال میکنه، باز هم این تضمین رو با یه روش به اسم SSI (Serializable Snapshot Isolation) نگه میداره.
پستگرس ابزارهای قفلگذاری در سطح جدول و سطر هم داره که برای اپلیکیشنهایی مناسبه که لزوماً نیاز به ایزولهسازی کامل ندارن و ترجیح میدن خودشون نقاط حساس رو کنترل کنن. البته استفاده درست از MVCC معمولاً از قفلگذاری بهتر جواب میده و سرعت بیشتری داره. به علاوه، قفلهای مشورتی هم هستن که برنامهها میتونن برای مدیریت قفلها استفاده کنن و این قفلها محدود به یه تراکنش خاص نیستن.
postgres یه سری ابزارای قوی داره برای اینکه توسعهدهندهها بتونن دسترسی همزمان به دادهها رو مدیریت کنن. این سیستم به صورت داخلی از یه مدل به اسم MVCC استفاده میکنه (که مخفف Multiversion Concurrency Control هست) تا سازگاری دادهها رو حفظ کنه. به این معنی که هر دستور SQL یه نمای کلی از دادهها رو میبینه (مثل یه نسخه از دیتابیس)، انگار که دادهها مال یه زمان قبلی هستن و ربطی به حالت فعلی دادهها ندارن. اینطوری باعث میشه که تو یه شرایط همزمانی، وقتی چند دستور دارن رو دادهها کار میکنن، نسخههای مختلفی از داده دیده بشه و تضادی بینشون پیش نیاد و هر سشن تو دیتابیس مستقل بمونه. MVCC با نداشتن قفلهای پیچیده، پرفورمنس سیستم رو برای محیطهایی که چندین کاربر همزمان دارن استفاده میکنن بالا میبره و جلوی ازدحام قفلها رو میگیره.
مزیت اصلی MVCC نسبت به روشهای قفلگذاری اینه که وقتی دادهها برای خوندن قفل میشن، این قفلها با قفلهایی که برای نوشتن دادهها لازمه تداخل ندارن. یعنی وقتی یه کاربر داره داده رو میخونه، جلوی نوشتن داده توسط کاربر دیگه رو نمیگیره و برعکس. پستگرس حتی وقتی شدیدترین حالت ایزولهسازی تراکنش رو فعال میکنه، باز هم این تضمین رو با یه روش به اسم SSI (Serializable Snapshot Isolation) نگه میداره.
پستگرس ابزارهای قفلگذاری در سطح جدول و سطر هم داره که برای اپلیکیشنهایی مناسبه که لزوماً نیاز به ایزولهسازی کامل ندارن و ترجیح میدن خودشون نقاط حساس رو کنترل کنن. البته استفاده درست از MVCC معمولاً از قفلگذاری بهتر جواب میده و سرعت بیشتری داره. به علاوه، قفلهای مشورتی هم هستن که برنامهها میتونن برای مدیریت قفلها استفاده کنن و این قفلها محدود به یه تراکنش خاص نیستن.
🔥7❤1
احتمالا همتون توی پروژه هاتون که نیاز به درگاه پرداخت داشتید کلی سرش ازیت شدید (مخصوصا سر merchant_id) و میخواستید دیگه سرتون رو بزنید به دیوار
حالا چرا اینارو میگم؟
من یه پکیج توسعه دادم برای حل همین مشکل 😁
توی این پکیج پایتونی من از درگاه پرداخت zibal استفاده کردم که استفاده ازش فوق سادست
حالا من اومدم ساده ترشم کردم
فیچرهایی که برای درگاه پرداخت نیاز دارید پیاده شده و همچین یه ارور هندلینگ قوی هم داره
و همینجوری لاگینگ قوی
براتون مثال هم گذاشتم که ازش راحت استفاده کنید
توی هر فریم ورک پایتونی هم که بخواید قابل استفاده هستش و مشکل نمیخورید باهاش
اگه دوست داشته باشید میتونید روی پروژه کانتربیوتر بشید و فیچرجدیدی یا درگاه جدیدی خواستید اضافه کنید دستتون بازه
لینک ریپو
لینک پکیج
@ninja_learn_ir
حالا چرا اینارو میگم؟
من یه پکیج توسعه دادم برای حل همین مشکل 😁
توی این پکیج پایتونی من از درگاه پرداخت zibal استفاده کردم که استفاده ازش فوق سادست
حالا من اومدم ساده ترشم کردم
فیچرهایی که برای درگاه پرداخت نیاز دارید پیاده شده و همچین یه ارور هندلینگ قوی هم داره
و همینجوری لاگینگ قوی
براتون مثال هم گذاشتم که ازش راحت استفاده کنید
توی هر فریم ورک پایتونی هم که بخواید قابل استفاده هستش و مشکل نمیخورید باهاش
اگه دوست داشته باشید میتونید روی پروژه کانتربیوتر بشید و فیچرجدیدی یا درگاه جدیدی خواستید اضافه کنید دستتون بازه
لینک ریپو
لینک پکیج
2⚡11🔥6❤5
Ninja Learn | نینجا لرن
احتمالا همتون توی پروژه هاتون که نیاز به درگاه پرداخت داشتید کلی سرش ازیت شدید (مخصوصا سر merchant_id) و میخواستید دیگه سرتون رو بزنید به دیوار حالا چرا اینارو میگم؟ من یه پکیج توسعه دادم برای حل همین مشکل 😁 توی این پکیج پایتونی من از درگاه پرداخت zibal…
ممنون میشم اگه روی این رپو استار بزنید 🙂❤️
❤14
🎢 برنامهنویسی Async
شاید زیاد به گوشت خورده باشه: Async Programming، ولی خب، دقیقاً یعنی چی؟ 🤔 بیایید با هم ببینیم چجوری میشه باهاش پروژههامونو بهتر و سریعتر توسعه بدیم.
حالا Async چیه؟ 🤔
تصور کن یه کافه پر سر و صدا داری؛ مشتریها میان، سفارش میدن، میشینن و منتظر آماده شدن سفارش میمونن. حالا فرض کن فقط یه کارمند داری که باید یکییکی سفارش بگیره و هرکدوم آماده شد، بده دست مشتری. 😴 اما اگه از Async کمک بگیری، این کارمند میتونه همه سفارشها رو پشت سر هم بگیره و هربار که یه سفارش آماده شد، همونو تحویل بده. بدون اینکه لازم باشه به مشتری بگه "منتظر بمون"
حالا Async چجوری کار میکنه؟
برنامهنویسی Async بهت اجازه میده که تسکها رو همزمان اجرا کنی. مثلا موقع درخواست به یه سرور خارجی (API)، میتونی به برنامه بگی به جای منتظر موندن، همزمان یه کار دیگه هم انجام بده.
کجا به درد میخوره؟
▶️ API Calling:
وقتی داری اطلاعات میگیری، منتظر نمیمونی، یه تسک دیگه اجرا میکنی. 🚀
▶️ File Handling:
خوندن و نوشتن فایلهای بزرگ بدون توقف کد. 📂
▶️ Web Scraping:
همزمان چندین صفحه رو بررسی میکنی.
یه مثال ساده از Async با Python و Js🐍
فرض کن یه فانکشن میخوایم بنویسیم که ۲ ثانیه بخوابه و بعد یه متن چاپ کنه. حالا ببین فرق sync و async چیه:
حالا Js :
امید وارم مفید بوده باشه :)
@ninja_learn_ir
شاید زیاد به گوشت خورده باشه: Async Programming، ولی خب، دقیقاً یعنی چی؟ 🤔 بیایید با هم ببینیم چجوری میشه باهاش پروژههامونو بهتر و سریعتر توسعه بدیم.
حالا Async چیه؟ 🤔
تصور کن یه کافه پر سر و صدا داری؛ مشتریها میان، سفارش میدن، میشینن و منتظر آماده شدن سفارش میمونن. حالا فرض کن فقط یه کارمند داری که باید یکییکی سفارش بگیره و هرکدوم آماده شد، بده دست مشتری. 😴 اما اگه از Async کمک بگیری، این کارمند میتونه همه سفارشها رو پشت سر هم بگیره و هربار که یه سفارش آماده شد، همونو تحویل بده. بدون اینکه لازم باشه به مشتری بگه "منتظر بمون"
حالا Async چجوری کار میکنه؟
برنامهنویسی Async بهت اجازه میده که تسکها رو همزمان اجرا کنی. مثلا موقع درخواست به یه سرور خارجی (API)، میتونی به برنامه بگی به جای منتظر موندن، همزمان یه کار دیگه هم انجام بده.
کجا به درد میخوره؟
▶️ API Calling:
وقتی داری اطلاعات میگیری، منتظر نمیمونی، یه تسک دیگه اجرا میکنی. 🚀
▶️ File Handling:
خوندن و نوشتن فایلهای بزرگ بدون توقف کد. 📂
▶️ Web Scraping:
همزمان چندین صفحه رو بررسی میکنی.
یه مثال ساده از Async با Python و Js🐍
فرض کن یه فانکشن میخوایم بنویسیم که ۲ ثانیه بخوابه و بعد یه متن چاپ کنه. حالا ببین فرق sync و async چیه:
import asyncio
# Sync
def print_sync():
print("Starting Sync...")
time.sleep(2)
print("Done Sync!")
# Async
async def print_async():
print("Starting Async...")
await asyncio.sleep(2)
print("Done Async!")
# اجرا
asyncio.run(print_async())
حالا Js :
// Sync
function printSync() {
console.log("Starting Sync...");
sleep(2000); // این تابع sleep فقط برای شبیهسازیه
console.log("Done Sync!");
}
function sleep(ms) {
const start = Date.now();
while (Date.now() - start < ms) {}
}
// Async
async function printAsync() {
console.log("Starting Async...");
await new Promise(resolve => setTimeout(resolve, 2000));
console.log("Done Async!");
}
// اجرا
printAsync();
#async #sync #backend
🔥16👍2🍾1