Meitix

لاگ روتیشن

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

اlog rotation یعنی به طور خودکار این فایل‌های لاگ رو تقسیم کنیم. مثلاً روزانه یا هفتگی یه فایل جدید درست می‌کنیم و قدیمیا رو آرشیو می‌کنی. چرا؟ چون:

سرعت کم میشه و پیدا کردن لاگی که میخوای سخت میشه

توی کانفیگ فایل های داکر میشه dns هم ست کرد. برای دانلود پکیج ها تحریم شده کار رو در میره. فایلشم اینجاست(نبود، باید ساخت)

Sudo vim /etc/docker/daemon.json

اندر فلسفه گو بخوایم بازم بگیم.

قضیهerrorه. گو میگه ارور ها هم value هستن و باید programmed بشن و این وسط یه درس زندگی هم میده😢 میگه

Dont panic

(پنیک فقط برای موقع کرش کردن مناسبه)

مثلا لایه سرویس ما ممکنه یه خطای حساس بده ما باید چک کنیم که اگه خطای که برگشته فلان خطا بود یه چیز دیگه برگردون تا پیام حساس سمت کاربر نرود

جالبه گو به هر pkg ها به چشم layer نگاه میکنه و نه گروه پکیج ها؛ و دقیقا به همین mindsetه که جلوی cyclic dependencies رو میگیره.

فرق هندلر و سرویس چیه؟

هندلر: کاری که مستقیم با درخواست و پاسخ سر و کار داره. مثلاً از کلاینت درخواست می‌گیره (مثلاً یه کاربر جدید رو ثبت کن)، اطلاعات ورودی رو چک می‌کنه و بعد می‌ده به سرویس.

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


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

سرویس: دیتا رو میگیره و چک میکنه کسی با این ایمیل ثبت نام نکرده باشه قبلا. دیتا رو تو دیتابیس ذخیره می‌کنه و اگه مشکلی باشه برمی‌گردونه.



چرا جداسازیشون مهمه؟
1. مرتب‌تر می‌شه کدتون: هر چیزی سر جای خودش قرار می‌گیره، هندلر با درخواست‌ها و سرویس با منطق.

2. تست کردن راحت‌تره: می‌تونید سرویس رو مستقل از هندلر تست کنید

البته درسته consistency رو بصورت یکپارچه نمیتونیم داشته باشیم ولی Eventual Consistency یه جور رویکرد توی سیستم‌های توزیع‌شده‌ست که سعی می‌کنه بین ویژگی‌های تئوری CAP یه تعادل برقرار کنه، مخصوصاً وقتی بخوایم Availability و Partition Tolerance رو حفظ کنیم.

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

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

کجاها استفاده می‌شه؟
اپلیکیشن‌هایی مثل شبکه‌های اجتماعی، پیام‌رسان‌ها یا سیستم‌های فروشگاهی آنلاین، مهم‌تره که سیستم همیشه در دسترس باشه و سریع جواب بده، حتی اگه گاهی داده‌ها با تأخیر هماهنگ بشن.

فرض کن توی یه پیام‌رسان، یه پیام می‌فرستی:
تو سرور اول (نزدیک‌ترین سرور به فرستنده)، پیام ذخیره می‌شه.
همون موقع دوستت پیام رو می‌بینه اما سرورهای دیگه هنوز پیام رو دریافت نکردن. بعد از چند ثانیه یا دقیقه، سرورهای دیگه هم پیام رو می‌گیرن و هماهنگ می‌شن.

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

خوب یا بد؟
🟢 خوبی: سرعت و دسترس‌پذیری سیستم بالاست.
🔴 بدی: اگه بخوای مطمئن بشی داده‌ها بلافاصله هماهنگن (مثل بانک‌ها)، این روش خیلی مناسب نیست.


خلاصه، Eventual Consistency یعنی "بالاخره درست می‌شه، ولی یه کم صبر کن😅"

📚 تئوری CAP به زبان ساده

یه تئوری معروف تو دنیای مهندسی نرم‌افزار هست به اسم CAP یا «تئوری بروئر». این تئوری می‌گه سیستم‌های توزیع‌شده (مثل دیتابیس‌هایی که روی چند تا سرور کار می‌کنن) نمی‌تونن هم‌زمان این سه ویژگی رو با هم داشته باشن:

1. اConsistency (یکپارچگی): یعنی همه سرورها همیشه یه داده‌ی یکسان نشون بدن.


2. اAvailability (دسترس‌پذیری): یعنی همیشه سیستم آماده پاسخ‌گویی باشه، حتی اگه یه بخشیش خراب بشه.


3. اPartition Tolerance (تحمل پارتیشن): یعنی وقتی شبکه قطع می‌شه یا یه بخشی از سیستم به بقیه دسترسی نداره، باز هم کار کنه.



حالا مشکل کجاست؟
تئوری CAP می‌گه شما توی یه سیستم توزیع‌شده نمی‌تونین هر سه اینا رو با هم داشته باشین. باید بینشون یکی رو قربونی کنین. مثلا:

اگه یکپارچگی و تحمل پارتیشن رو انتخاب کنین، ممکنه دسترس‌پذیری قربانی بشه.

اگه دسترس‌پذیری و تحمل پارتیشن رو بخواین، ممکنه داده‌ها یکپارچه نباشن.

اگه یکپارچگی و دسترس‌پذیری براتون مهمه، سیستم نمی‌تونه پارتیشن شبکه رو تحمل کنه.


مثال عملی:
فرض کن تو یه پیام‌رسان هستی. می‌خوای پیام‌هایی که می‌فرستی سریع برسه (دسترس‌پذیری)، اما هم‌زمان مطمئن باشی همه گیرنده‌ها پیام یکسانی می‌گیرن (یکپارچگی). اگه اینترنت یکی از سرورها قطع بشه، دیگه باید انتخاب کنی: یا پیام سریع برسه(ولی شاید یکی درست دریافت نکنه)، یا صبر کنی تا اتصال سرور درست بشه تا همه پیام درست دریافت کنن.

خلاصه، CAP می‌گه توی سیستم‌های توزیع‌شده همیشه باید یه‌جایی کوتاه بیای مثل اینکه 😅

مزایا:
🔹مقیاس‌پذیری: وقتی تعداد سرور‌ها زیاد میشه، Consistent Hashing به راحتی می‌تونه بار رو بین سرور‌ها تقسیم کنه بدون اینکه مجبور باشیم همه داده‌ها رو دوباره جابجا کنیم.

🔹 ساده‌تر کردن مدیریت سرورها: وقتی یه سرور جدید میاد، فقط یه قسمت کوچکی از داده‌ها جابجا میشه و این باعث میشه که سرورها به طور خیلی بهتر و متوازن‌تر کار کنن.

هشینگ و مصائب

فرض کنیم یه شبکه از سرور داریم که برای ذخیره‌سازی داده‌ها از Redis استفاده می‌کنه. حالا برای تقسیم داده‌ها بین سرور‌ها، به طور معمول ممکنه از یه الگوریتم ساده‌ای مثل "مدولوس" استفاده کنیم. در این روش، داده‌ها رو بر اساس یه مقدار مثل ID یا شماره کلید هاش می‌کنیم و با استفاده از تقسیم باقی‌مانده (mod) اون رو به یکی از سرور‌ها تخصیص می‌دیم.

مشکل با این روش:

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

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


به عنوان مثال:

فرض کن ۳ سرور داریم و کلیدهای داده‌ها به این شکل به سرور‌ها تخصیص داده میشن:

سرور ۱: کلیدهایی که باقی‌مانده تقسیمشون بر ۳، ۰ میشه.

سرور ۲: کلیدهایی که باقی‌مانده تقسیمشون بر ۳، ۱ میشه.

سرور ۳: کلیدهایی که باقی‌مانده تقسیمشون بر ۳، ۲ میشه.


حالا اگر بخواهیم سرور ۴ اضافه کنیم، باید تمام داده‌ها رو دوباره تقسیم کنیم. مثلا اگر کلیدی که قبلاً به سرور ۳ می‌رفته، حالا باید به سرور ۴ بره. یا داده‌هایی که قبلاً به سرور ۲ می‌رفتن، باید حالا بین سرور ۲ و ۴ تقسیم بشن. این باعث میشه که انتقال داده‌ها خیلی پیچیده و زمان‌بر بشه.

راه‌حل: Consistent Hashing....