یه چند وقتی هست علاقه‌م به زبان راست بیشتر شده و بیشتر دارم درموردش یاد می‌گیرم
اگر قطع نشدم، مثل قدیم پست می‌نویسم و کنار یکم راست یاد می‌گیریم

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

توی این اوضاع چیزی که رو مخم میره یه سری از این استادهای دانشگاه‌ها هستن

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

خب که چی استاد عزیز؟
خب که چی؟
کلاسی که مجازی هست، و داره ضبط میشه برای تو چه فرقی داره من الان حاضر باشم یا بعدا ضبط شده‌ش رو ببینم؟

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

خیلی‌ها سر کار میرن تا خرج خونواده بدن، در عین حال تحصیل هم بکنن، بعد یه عده بی‌سواد که معلوم نیست چطور استاد دانشگاه شدن اینطور می‌کنن.

چند جا رزومه دادم، ولی نمی‌دونم اگر استخدام بشم با این استادها چه کنم

مطمئنا ایران برای این طور آدما با ایرانی که ما توش زندگی می‌کنیم فرق می‌کنه.

واقعا زیباست

یادش بخیر یه زمانی نگران بودیم AI شغلمونو ازمون بگیره...

@DevTwitter

در انتظار حمایت‌های بیشتر از simula هستم...

یکی دیگه از کارای احمقانه ای که توی نبود اینترنت انجام دادم این Lexer/Parser Generator بود که توسعه ش دادم
تجربه جالبی نبود ولی خب بهتر از هیچ کار نکردن بود

با دوستم رفته بودم بیرون مثلا حالمون خوب بشه

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

یهو به خودم اومد و به دوستم گفتم عجب نسل عجیبی هستیم
همسن و سالای ما توی کل دنیا الان توی پارتی‌ان، یا پی خوش‌گذرونی
ما چی شدیم، چه بلایی سرمون اومده که یه اهنگ غمگین پلی می‌کنیم و توی سکوت فرو میریم

اینم از تفریح ما

📈 Confirmed: Live metrics show a partial restoration to internet connectivity in #Iran on day 88, after 2093 hours of near-total isolation from international networks, the longest nationwide internet shutdown in modern history. It is unclear if the restoration will be sustained.

بعد این همه بدبختی داریم بر می‌گردیم سر خونه اول

خوشبختانه برگشتیم سر کار، و این روزا یکم شلوغ شدم

در اولین فرصت که سرم خلوت بشه LaraGram 4 رو تکمیل می‌کنم و ریلیز می‌کنم
این ورژن شامل 9 پکیج جدید(تا این لحظه) هست که قراره انقلابی باشه(طبق معمول هیچکس اهمیت نمیده)

تا اون موقع لطفا از سیمولا حمایت کنید، به گیت‌هابش استار بدید و به بقیه معرفی کنید خیلی خیلی خوشحالم میشم🤝

https://github.com/laraXgram/Simula
.

بیاید بیکار نباشیم، هر از گاهی یک سوال چالشی میفرستم که یکم ذهنمون درگیر بشه و یاد بگیریم.
از آسون شروع کنیم😁

فرض کنید یک API داریم که داده‌هاش رو از Redis می‌خونه.

داده مورد نظر هر ۱۰ دقیقه یک بار Expire میشه و بعد از Expire شدن، اولین درخواست میره دیتابیس رو می‌خونه و مجدد مقدار رو داخل Redis ذخیره می‌کنه.

حالا این API حدود ۱۰۰۰ درخواست در ثانیه داره.

سوال اینجاست:

اگر دقیقاً در لحظه‌ای که Cache Expire شده، ۱۰۰۰ درخواست همزمان به API برسه، چه اتفاقی میفته؟

چه مشکلاتی ممکنه برای Redis، Application و Database ایجاد بشه؟
ایا ۱۰۰۰ درخواست باید به دیتابیس کوئری بزنن؟

شما برای جلوگیری از این مشکل چه راهکارهایی پیشنهاد میدید؟

در پاسخ فقط اسم بردن از راهکارها کافی نیست؛ در مورد نحوه پیاده‌سازی، مزایا، معایب و Trade-off هر راهکار هم توضیح بدید.

بریم یک توضیح کامل در این مورد با جمع‌بندی نظرات دوستانی که همراهی کردند داشته باشیم.

اول از همه مشکلی که اینجا داریم به Cache Stampede (هجوم همزمان درخواست‌ها به دیتابیس بعد از منقضی شدن کش) معروف هست.

یعنی تا وقتی کش وجود داره همه چیز خوبه، ولی به محض اینکه TTL تموم بشه، ممکنه ۱۰۰۰ درخواست همزمان Cache Miss بخورن و به جای یک Query، هزار Query به دیتابیس ارسال بشه.

این سناریو معمولا زمانی خطرناک‌تر میشه که با یک Hot Key (کلیدی که تعداد بسیار زیادی درخواست به آن ارسال می‌شود) طرف باشیم. خیلی از راهکارها برای کلیدهای معمولی جواب میدن، اما برای Hot Keyها باید بیشتر مراقب بود چون یک اشتباه کوچک می‌تونه فشار زیادی روی دیتابیس ایجاد کنه.

اولین راه‌حلی که معمولا به ذهن می‌رسه استفاده از Mutex یا Distributed Lock (قفل سراسری بین چند سرور) هست. یعنی وقتی Cache Miss اتفاق افتاد فقط اولین درخواست اجازه داشته باشه از دیتابیس بخونه و کش رو مجدد پر کنه. بقیه درخواست‌ها یا منتظر بمونن یا چند لحظه بعد دوباره کش رو بررسی کنن.

البته Lock به تنهایی مشکل رو کامل حل نمی‌کنه. فشار روی دیتابیس کم میشه اما ممکنه Latency کاربران افزایش پیدا کنه.

همچنین در پیاده‌سازی Lock باید به Failure Scenarioها هم فکر کرد. مثلا اگر سرویسی که Lock رو گرفته قبل از آزاد کردنش Crash کنه چه اتفاقی میفته؟ به همین دلیل معمولا Lockها خودشون TTL دارن تا سیستم در وضعیت Deadlock باقی نمونه.

برای همین معمولا از Request Coalescing (تجمیع درخواست‌های مشابه) هم استفاده میشه. یعنی اگر ۱۰۰۰ درخواست همزمان برای یک داده وارد بشن، فقط یک درخواست واقعا به دیتابیس بره و بقیه منتظر نتیجه همون درخواست بمونن.

اگر تازگی داده خیلی حیاتی نباشه، Stale-While-Revalidate گزینه جذاب‌تریه. در این حالت وقتی TTL تموم میشه، همچنان آخرین مقدار کش به کاربر برگردونده میشه و همزمان یک فرآیند در پس‌زمینه کش رو Refresh می‌کنه. اینطوری کاربر افزایش Latency رو حس نمی‌کنه.

راهکار دیگه Cache Warming یا Background Refresh هست. یعنی اصلا منتظر اولین درخواست نمی‌مونیم. قبل از اینکه TTL تموم بشه یک Job در پس‌زمینه کش رو مجدد می‌سازه و جایگزین می‌کنه. در این حالت عملا Cache Miss برای کاربران رخ نمیده.

برای کاهش احتمال بروز این مشکل هم میشه از Randomized TTL یا Jitter استفاده کرد. مثلا به جای اینکه همه کلیدها دقیقا ۱۰ دقیقه عمر داشته باشن، بعضی ۹ دقیقه و بعضی ۱۱ دقیقه عمر داشته باشن. این کار باعث میشه تعداد زیادی کلید دقیقا در یک لحظه منقضی نشن.

حالا یک سوال مهم اینجاست که اصلا چرا TTL داریم؟

معمولا TTL زمانی استفاده میشه که:

- داده ممکنه در دیتابیس تغییر کنه و نمی‌خوایم کش برای همیشه مقدار قدیمی نگه داره.
- نمی‌دونیم چه زمانی داده تغییر می‌کنه.
- می‌خوایم در نهایت کش خودش به‌روز بشه حتی اگر فراموش کنیم آن را Invalidate کنیم.

اما اگر کنترل کامل روی مسیر آپدیت داده داشته باشیم، شاید اصلا نیازی به TTL نباشه.

مثلاً میشه از معماری Event-Driven استفاده کرد. یعنی هر زمان داده در دیتابیس تغییر کرد، یک Event منتشر بشه و همون لحظه کش هم آپدیت یا حذف بشه. در این مدل عملا کش همیشه تازه است و دیگر منتظر منقضی شدن TTL نمی‌مونیم.

البته این راهکار هم هزینه خودش رو داره. اگر Event از دست بره یا آپدیت کش با خطا مواجه بشه، ممکنه دیتابیس و کش با هم ناسازگار بشن. به همین دلیل خیلی از سیستم‌ها حتی در کنار Event-Driven بودن، یک TTL بلندمدت هم قرار میدن تا اگر جایی مشکلی پیش اومد، کش نهایتا خودش اصلاح بشه.

اگر حجم داده خیلی زیاد نباشه میشه یک Hybrid Cache (کش چندلایه) هم داشت. مثلا:

- حافظه خود اپلیکیشن به عنوان L1 Cache
- و Redis به عنوان L2 Cache

در این حالت بسیاری از درخواست‌ها حتی به Redis هم نمی‌رسن و مستقیما از حافظه سرویس پاسخ می‌گیرن. البته در این مدل باید به موضوع Cache Invalidation (هماهنگ نگه داشتن چند کش مختلف) هم فکر کرد.

در نهایت انتخاب راهکار تا حد زیادی به Trade-off بین Consistency (تازگی و صحت داده) و Availability (سرعت پاسخگویی و در دسترس بودن سرویس) بستگی داره. اگر داده بسیار حساس باشه شاید ترجیح بدیم درخواست منتظر Refresh شدن کش بمونه، اما اگر تجربه کاربری مهم‌تر باشه معمولا برگردوندن داده‌ای که چند ثانیه یا چند دقیقه از عمرش گذشته قابل قبوله.

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