https://virgool.io/feed/@hosein.rezaei من حسین هستم یک برنامه نویس. fa 2026-06-15 21:18:26 https://files.virgool.io/upload/users/3284937/avatar/0xWL5M.jpg?height=120&width=120 https://virgool.io/@hosein.rezaei https://virgool.io/@hosein.rezaei/%D8%B3%D8%A7%D8%AF%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%A8%D8%A7-%D9%BE%D8%B1%D9%87%DB%8C%D8%B2-%D8%A7%D8%B2-%D8%B4%D8%A7%DB%8C%D8%AF-%D8%A8%D9%87-%D8%AF%D8%B1%D8%AF-%D8%A8%D8%AE%D9%88%D8%B1%D9%87-yagni-%D8%AF%D8%B1-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%DA%86%DB%8C%D8%B3%D8%AA-vdokxh8jukzk یگنی یا YAGNI مخفف "You Aren't Gonna Need It" است، به معنی "بهش نیاز پیدا نمی‌کنی". این اصل در برنامه‌نویسی به ما یاد می‌دهد که فقط کدی را بنویسیم که در حال حاضر به آن نیاز داریم و از نوشتن کدهایی که احتمالاً در آینده ممکن است به کارمان بیایند، خودداری کنیم.چرا YAGNI مهم است؟کاهش پیچیدگی: نوشتن کدهای اضافی، برنامه را پیچیده‌تر می‌کند و خوانایی، نگهداری و توسعه آن را دشوارتر می‌سازد.صرفه‌جویی در زمان: نوشتن کدهایی که به آنها نیاز نداریم، اتلاف وقت و انرژی است.افزایش انعطاف‌پذیری: با تمرکز بر نیازهای فعلی، می‌توانیم کد را به گونه‌ای طراحی کنیم که به راحتی در آینده قابل تغییر و گسترش باشد.کاهش خطا: کدهای کمتر، به معنای اشکالات کمتر است.مثالی از YAGNI در عمل:فرض کنید در حال ساخت یک وبسایت برای فروش کتاب هستید. در حال حاضر، به سیستمی برای ارسال نظر برای کتاب‌ها نیازی ندارید.طبق YAGNI، شما نباید کدی برای این سیستم بنویسید تا زمانی که نیاز واقعی به آن احساس شود.در عوض، می‌توانید روی قابلیت‌های اصلی مانند نمایش لیست کتاب‌ها، سبد خرید و پردازش پرداخت تمرکز کنید.مزایای عدم نوشتن کد YAGNI:سادگی: کد شما تمیزتر و خواناتر خواهد بود.نگهداری آسان: به‌روزرسانی و اصلاح کد آسان‌تر خواهد بود.قابلیت تست: تست کد شما آسان‌تر خواهد بود.انعطاف‌پذیری: می‌توانید به راحتی در آینده ویژگی‌های جدید را اضافه کنید.نکاتی برای رعایت YAGNI:بر نیازهای فعلی تمرکز کنید: فقط کدی را بنویسید که برای حل مشکلات موجود ضروری است.از حدس و گمان پرهیز کنید: اگر مطمئن نیستید که در آینده به یک ویژگی نیاز خواهید داشت، آن را ننویسید.طراحی برای تغییر: کدی بنویسید که به راحتی قابل گسترش و تغییر باشد.از تست به عنوان راهنما استفاده کنید: فقط کدهایی را تست کنید که واقعاً به آنها نیاز دارید.یگنی YAGNI یک اصل ساده اما قدرتمند است که می‌تواند به شما کمک کند تا کدهای تمیزتر، قابل نگهداری‌تر و انعطاف‌پذیرتر بنویسید. با تمرکز بر نیازهای فعلی و پرهیز از نوشتن کدهای "شاید به درد بخوره"، می‌توانید در زمان و انرژی خود صرفه‌جویی کنید و از پیچیدگی‌های غیرضروری جلوگیری کنید. حسین رضائی حسین رضائی Sat, 29 Jun 2024 16:45:02 +0330 https://virgool.io/@hosein.rezaei/system-design-%D8%A7%D8%B2-%D8%B5%D9%81%D8%B1-%D8%AA%D8%A7-%D9%85%DB%8C%D9%84%DB%8C%D9%88%D9%86%D9%87%D8%A7-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-%D8%A8%D8%AE%D8%B4-%D8%A2%D8%AE%D8%B1-kobukh27uqmy بخش سوم و آخر سیستم دیزاین درمورد کش و سی دی ان و صف نوشتم، مطالب قبلی رو هم میتونید از لینک های زیر بخونید:پست اول:https://vrgl.ir/S0YQ1پست دوم:https://vrgl.ir/wDJE5تو دوتا بخش قبلی درموردموارد زیر صحبت کردم:-راه اندازی با یک سرور (Single server setup)-انتخاب پایگاه داده مناسب-توزیع کننده بار (Load balancer)-ارتقاء یا اسکیل (scale) عمودی در مقابل افقی-پایگاه داده تکثیر پذیر Database replicationوب‌سایت پر سرعت با کش (Cache) ، راز پشت لود سریع صفحات:کش، یک فضای ذخیره‌سازی موقته که نتایج خروجی‌های پرهزینه یا داده‌های پرکاربرد رو در حافظه نگه می‌داره تا درخواست‌های بعدی سریع‌تر پاسخ داده بشن.همینطور که تو شکل بالا می‌بینید، هر بار که یک صفحه وب جدید بارگذاری می‌شه، برای دریافت داده، یک یا چند دستور به بانک اطلاعاتی ارسال میشه. فراخوانی مکرر بانک اطلاعاتی، عملکرد کلی برنامه روتحت تاثیر قرار میده. کش می‌تونه این مشکل رو تا حد زیادی برطرف کنه.لایه کشکش، یک لایه ذخیره‌سازی موقت دادست که بسیار سریع‌تر از بانک اطلاعاتی عمل می‌کنه. مزایای داشتن یک لایه کش مجزا :عملکرد بهتر سیستم: با کاهش بار روی بانک اطلاعاتی، سرعت کلی سیستم بهبود پیدا میکنه.کاهش حجم کاری بانک اطلاعاتی: فراخوانی‌های مکرر به بانک اطلاعاتی کاهش پیدا میکنه.مقیاس‌پذیری مستقل: امکان افزایش ظرفیت کش به صورت مجزا از سایر اجزای سیستم وجود داره.نکاتی برای استفاده از کش:در نظر گرفتن نکات زیر برای استفاده از یه سیستم کش ضروریه:زمان مناسب برای استفاده از کش: زمانی از کش استفاده کنید که داده‌ها به طور مکرر خوانده می‌شن اما به ندرت تغییر میکنن. حافظه کش، فرّاره (فرار میکنه 😅 )؛ بنابراین برای ذخیره‌سازی دائمی داده‌ها مناسب نیست. به عنوان مثال، با راه‌اندازی مجدد (reset) سرور کش، تمام داده‌های موجود در حافظه از بین میره یا همون پاک میشه خودمون. پس داده‌های مهم رو باید در مخازن داده دائمی (Database) ذخیره کرد.پ.ن: "عجم زنده کردم بدین پارسی ... ، چه اصطلاحی "پس داده‌های مهم رو باید در مخازن داده دائمی ذخیره کرد" خودم کفم بریده، یکی از سخترین کارا ترجمه متنای تخصصیه و سعی میکنم فارسی و انگلیسی مفهوم رو برسونم ولی اگه مشکلی بود حتما بهم گوشزد کنید.سیاست انقضا (Expiration Policy): ایجاد یک سیاست انقضا برای داده‌های کش‌شده، امری ضروریه. بعد از منقضی شدن داده‌های کش‌شده، اونها از کش حذف میشن. نبودِ سیاست انقضا باعث می‌شه داده‌ها برای همیشه در حافظه باقی بمونن. تنظیم زمان انقضای خیلی کوتاه، باعث بارگذاری مجدد و مکرر داده‌ها از بانک اطلاعاتی می‌شه. از طرف دیگه، زمان انقضای خیلی طولانی نیز باعث قدیمی یا کهنه شدن داده‌ها میشه که باید بالانس مناسب بین این دوتارو پیدا کرد.سازگاری (Consistency): این مورد به همگام یا یکپارچه (sync) نگهداشتن بانک اطلاعات و کش اشاره داره. ناسازگاری می‌تونه به دلیل عدم انجام عملیات تغییر داده روی بانک اطلاعاتی و کش در یک تراکنش واحد رخ داده باشه. حفظ سازگاری بین بانک اطلاعاتی و کش در هنگام اسکیل کردن در چندین منطقه، چالش‌برانگیزه.انتخاب روش مناسب برای حفظ یکپارچگی در لایه کش بستگی به نیازهای خاص برنامه، میزان خواندن و نوشتن داده‌ها، و تحمل‌پذیری برنامه برای تأخیر داره. روش‌های مختلفی برای پیاده‌سازی این یکپارچگی وجود داره که هر کدام مزایا و معایب خاص خودشون رو دارن. مهمه که با توجه به نیازهای خاص سیستم، روش مناسب انتخاب و پیاده‌سازی بشه تا بهترین عملکرد و اطمینان از یکپارچگی داده‌ها حاصل بشه. درمورد consistency خودتون حتما تحقیق کنید و مطلب بخونید خیلی مبحث بزرگیه خودش.کاهش اثرات خرابی: یک سرور کش به تنهایی می‌تونه یک نقطه شکست بالقوه (SPOF) باشه. SPOF به وضعیتی گفته می‌شود که خرابی یک جزء از سیستم، کل سیستم را از کار می‌اندازد. برای جلوگیری از SPOF، استفاده از چندین سرور کش در مراکز داده مختلف توصیه می‌شه. همچنین، اختصاص مازاد حافظه نیز رویکرد مفیدیه؛ چون با افزایش مصرف حافظه، بافری برای سیستم در نظر گرفته میشه.مانیتورینگ مداوم سرورها برای تشخیص خرابی‌ها و انجام اقدامات بازیابی خودکار می‌تونه به کاهش اثرات خرابی کمک کنه.*(Single Point of Failure - SPOF)وب‌سایت پر سرعت با CDN و توزیع محتوا: تحویل سریع‌تر فایل‌های حجیم!در بخش قبلی با مفهوم کش (Cache) آشنا شدیم. در این بخش به سراغ مفهوم دیگه‌ای به نام شبکه توزیع محتوا (Content Delivery Network - CDN) میریم.توی این کتاب در مورد نحوه استفاده از CDN برای کش کردن محتوای استاتیک تمرکز داره و کش کردن محتوای پویا (دینامیک) رو پوشش نمیده.به صورت کلی، نحوه عملکرد CDN به این شکله که وقتی کاربری از وب‌سایت بازدید می‌کنه، نزدیک‌ترین سرور CDN به کاربر، محتوای استاتیک رو تحویل میده. به طور شهودی، هرچه کاربران از سرورهای CDN دورتر باشن، وب‌سایت با سرعت کمتری بارگذاری می‌شه. برای مثال، اگر سرورهای CDN در سان‌فرانسیسکو باشن، کاربران لس‌آنجلس محتوای وب‌سایت رو سریع‌تر از کاربران اروپا دریافت می‌کنن. شکل زیر خیلی خوب نشون میده که CDN چطور زمان بارگذاری رو بهبود می‌بخشه.گردش کار (ورک فلو workflow) در CDN :1- کاربر A با استفاده از یک URL تصویر سعی میکنه به image.png دسترسی پیدا کنه. دامنه‌ی URL توسط ارائه‌دهنده‌ی CDN تأمین میشه.2- اگر سرور CDN تصویر image.png رو تو کش نداشته باشه، سرور CDN فایل رو از مبدا (Origin) درخواست می‌کنه که می‌تونه یک وب‌سرور یا فضای ذخیره‌سازی آنلاین مانند Amazon S3 باشه.3- مبدا، image.png رو به سرور CDN برمی‌گردونه که شامل هدر اختیاری HTTP به نام Time-to-Live (TTL) که مدت زمان کش شدن تصویر رو مشخص می‌کنه.4- سی دی ان (CDN) تصویر رو کش می‌کنه و اون رو به کاربر A برمی‌گردونه. این تصویر تا وقتی که TTL منقضی نشه، تو CDN که کش شده نگه میداره.5- کاربر B درخواستی برای دریافت همون تصویر ارسال می‌کنه.6- تا وقتی که TTL منقضی نشده باشه، تصویر از کش برای کاربر ارسال میشه.نکاتی برای استفاده از CDNهزینه: CDNها توسط ارائه‌دهندگان شخص ثالث (third-party providers) اداره میشن و شما برای انتقال داده‌ها به داخل و خارج از CDN هزینه پرداخت می‌کنید. کش کردن دیتاهایی که به ندرت استفاده‌شده، مزایای قابل توجهی نداره، بنابراین باید از انتقال آن‌ها به CDN صرف نظر کنید.تنظیم زمان انقضای کش مناسب: برای محتوای حساس به زمان، تعیین زمان انقضای کش بسیار مهمه. زمان انقضای کش نباید خیلی طولانی و نه خیلی کوتاه باشه. اگر خیلی طولانی باشه، ممکنه محتوا دیگه به‌روز نباشه. اگر خیلی کوتاه باشه، می‌تونه باعث بارگذاری مجدد مکرر محتوا از سرورهای اصلی به CDN باشه.پشتیبان‌گیری CDN: باید در نظر بگیرید که وب‌سایت یا اپلیکیشن شما چطور با خرابی CDN مقابله می‌کنه. اگر قطعی موقت CDN رخ بده، کاربران باید بتونن مشکل رو تشخیص بدن و منابع را از مبدا یا سرور درخواست کنن.ابطال کردن فایل‌ها: می‌تونید با انجام یکی از عملیات زیر، یه فایل رو قبل از انقضا از CDN حذف کنید، برای ابطال کردن شیء CDN میتونید از APIهایی که توسط فروشندگان CND ارائه میشه استفاده کنید.استفاده از نسخه‌بندی شیء برای ارائه نسخه متفاوتی از شیء: برای نسخه‌بندی یک شیء، می‌تونید پارامتری رو به URL اضافه کنید، مثل شماره‌ی نسخه. برای مثال، شماره‌ی نسخه‌ی ۲ به رشته‌ی کوئری اضافه می‌شه: image.png?v=2.شکل زیر طرحی رو نشون میده که CDN و کش به اون اضافه شده .صف پیام، قهرمان پشت صحنه وبسایت‌های پرطرفدار!فرض کنید دارید یه وبسایت خیلی پرطرفدار رو اجرا می‌کنین. کلی کاربر داره ازش استفاده می‌کنه و هر کدوم درخواست‌های مختلفی دارن. خب، چطوری میشه با این حجم از درخواست‌ها به طور روان و بدون مشکل برخورد کرد؟ اینجا یه قهرمان پنهانی به اسم “صف پیام” (Message Queue) به دادمون می‌رسه.صف یه بافره که درخواست‌های کاربرها رو به ترتیب توی خودش نگه می‌داره و بعد به قسمت‌های مختلف وبسایت که مسئول رسیدگی به اون درخواست‌ها هستن، ارسال می‌کنه. اینطوری، هیچکدوم از قسمت‌ها زیر بار درخواست‌ها له نمی‌شن و همه چیز آروم و روان پیش می‌ره.مثال: فرض کنید یه اپلیکیشن برای ادیت عکس دارین که می‌تونه عکس‌ها رو برش بزنه، نورشون رو تنظیم کنه و خلاصه کلی کارای دیگه روش انجام بده. خب، این کارا زمان‌بر هستن. با صف، وقتی کاربر درخواست ادیت عکس می‌ده، اون درخواست توی صف پیام قرار می‌گیره. یه قسمت دیگه که مسئول ادیت عکسه، کم‌کم سراغ صف پیام می‌ره و درخواست‌ها رو برمی‌داره و ادیت می‌کنه. حتی اگه سرور کاربر برای مدتی قطع بشه، اشکالی نداره چون درخواستش توی صف مونده و بعدا رسیدگی می‌شه.خداحافظ ارور، سلام سرحال بودن!هر سایتی که بزرگ می‌شه، با یه سری دردسرهای جدید روبرو می‌شه. لازمه که حواسمون باشه وبسایت همیشه سرپا و سرحال باشه. چند تا ابزار بهمون در این زمینه کمک می‌کنن:لاگ‌گیری (Logging): با این کار می‌تونیم بفهمیم چه خطاهایی توی سایت افتاده و سریع‌تر رفعشون کنیم.مانیتورینگ (Monitoring): یعنی اینکه حواسمون باشه همه چی داره خوب کار می‌کنه. مثلا اینکه چقدر فضا روی سرور مونده، چقدر حافظه داره استفاده می‌شه و… .اتوماسیون (Automation): بعضی کارها رو می‌تونیم به صورت اتوماتیک انجام بدیم. مثلا هر وقت یه نفر کد جدید می‌نویسه، اتوماتیک چک بشه که مشکلی نداشته باشه. اینطوری خیالمون راحت‌تره و دیگه لازم نیست همه چی رو دستی چک کنیم . برای این مورد ci/cd رو هم پیشنهاد میدم که درموردش بخونید.زیرساخت برای میلیون‌ها کاربر!تبریک! تا اینجا تونستی یه وب‌سایت حسابی راه بندازی و کلی کاربر جذب کنی. ولی حالا می‌خوای اون رو تبدیل به یه ابرقدرت کنی، درسته؟ خب، برای اینکه بتونی از پس میلیون‌ها کاربر بربیای باید زیرساخت‌شو تقویت کنی.تقویت کردن یه سیستم یه پروسه مرحله به مرحله‌ست. همه‌ی اون چیزایی که تو این سه تا پست یاد گرفتی می‌تونه تا یه جایی کارتو راه بندازه، ولی اگه می‌خوای با جمعیت میلیونی کاربرا کنار بیای، باید یه کم ظریف‌کاری کنی و از استراتژی‌های جدیدتری استفاده کنی. مثلا شاید لازم باشه کل سیستم رو بهینه کنی و اون رو به بخش‌های کوچیک‌تر و مستقل‌تری تقسیم کنی.اما نگران نباش! همه‌ی اینایی که یاد گرفتی یه زیربنای محکم بهت میدن تا با چالش‌های جدید مقابله کنی. حالا بریم سراغ یه خلاصه از کارهایی که باید انجام بدی تا بتونی از پس میلیون‌ها کاربر بربیای:خداحافظ پیچیدگی، سلام سادگی! لایه وب رو بدون حالت (stateless) نگه دار. یعنی اطلاعات مربوط به کاربرها رو اونجا ذخیره نکن. اینطوری همه چیز ساده‌تر و سریع‌تر میشه.همه جا رو پشتیبان‌گیری کن! تو هر بخش از وبسایتت، یه سیستم پشتیبان (redundancy) داشته باش. اینطوری اگه یه قسمتی از کار افتاد، کل سایت از کار نمی‌افته.هر چی می‌تونی رو کش کن! یه فضای ذخیره‌سازی موقت (cache) داشته باش تا نتایج پرکاربرد رو ذخیره کنی. اینطوری دیگه لازم نیست هر بار دوباره همون کارا رو انجام بدی و همه چیز سریع‌تر پیش می‌ره.بذار دیتاسنترهای بیشتری واست کار کنن! از چند تا مرکز داده (data center) تو نقاط مختلف دنیا استفاده کن. اینطوری اگه یه مرکز با مشکل روبرو بشه، بقیه میتونن کار رو انجام بدن و کاربرها اذیت نمی‌شن.فایل‌های ثابت رو بسپار به CDN! از یه شبکه توزیع محتوا (CDN) برای تحویل سریع‌تر فایل‌های حجیم و بدون تغییر به کاربرها استفاده کن.بانک اطلاعاتی رو تیکه تیکه کن! بانک اطلاعاتی رو به بخش‌های کوچیک‌تر و قابل مدیریت‌تری به اسم Shard تقسیم کن. اینطوری دیگه همه چی روی یه سرور سنگینی نمی‌کنه.سیستم رو خرد کن تا قوی‌تر بشه! لایه‌های مختلف سیستم رو به سرویس‌های مجزا تقسیم کن. اینطوری هر کدوم رو می‌تونی جداگانه ارتقا بدی و نگهداریشون هم راحت‌تره. حواست به همه چی باشه! سیستم رو زیر نظر داشته باش (monitor) و از ابزارهای اتوماسیون استفاده کن تا کارها به صورت خودکار انجام بشه. اینطوری خیالت راحت‌تره و می‌تونی تمرکزت رو روی چیزای مهم‌تر بذاری.آفرین! این یه قدم بزرگ بود. به خودت افتخار کن! حسین رضائی حسین رضائی Sat, 01 Jun 2024 14:32:55 +0330 https://virgool.io/@hosein.rezaei/system-design-%D8%A7%D8%B2-%D8%B5%D9%81%D8%B1-%D8%AA%D8%A7-%D9%85%DB%8C%D9%84%DB%8C%D9%88%D9%86%D9%87%D8%A7-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-iq0yr4u6nifg سلام!من توی چندین پست قراره کتاب system design interview رو که خوندم رو با شما به اشتراک بذارم و به طور خلاصه مطالبش رو بهتون بگم.بخش اول این پس رو میتونید از این لینک بخونید. https://vrgl.ir/S0YQ1 توی این پست هم درمورد لود بالانسر ، دیتابیس رپلیکیشن یا تکرار دیتابیس و دو نوع اسکیل عمودی و افقی صحبت میکنم.توزیع کننده بار (Load balancer)برای متوجه شدن اینکه یک لود بالانسر چطور کار میکنه با مثال زیر همراه باشید:تصور کنید که در یک فست فود خیلی شلوغ فقط یک صندوق دار وجود داره و یه صف خیلی طولانی تا وسط خیابون ادامه پیدا میکنه و مشتری ها ناراضی میشن. راه حل چیه ؟ میشه یک یا چند صندوق دار دیگر هم اضافه کرد تا بجای یک صف، مشتری ها در چند صف خدمات بگیرن.در دنیای وبسایت ها و اپلیکیشن ها هم چنین چیزی وجود داره که ترافیک رو بین سرور ها توزیع میکنه. همون طور که در شکل بالا مشاهده میکنید شما دیگه مستقیما به سرور ها متصل نمیشید بلکه ابتدا با لود بالانسر ارتباط برقرار میکنید و اون شمارو به بهترین سرور هدایت میکنه، بدین طریق اگر یک سرور شلوغ باشه ، شمارو به سروری که قادر به سرویس دادنه هدایت میکنه.یه نکته درمورد Private IP که توی عکس بالا مشاهده میکنید: استفاده از private ip برای ارتباط بین لودبالانسر و سرورها امنیت رو هم بالاتر میبره. ip خصوصی یک آدرس داخلیه که فقط از همون شبکه محلی قابل دسترسیه و از اینترنت قابل دسترسی نیست.استفاده از لود بالانسر 2 مزیت مهم دارد:1) دیگر از قطع شدن خبری نیست ، چون درصورتی که یک سرور از کاربیافتد لود بالانسر ترافیک را با سرور های دیگر منتقل میکند.2) مقایس پذیری ساده تر میشود، با زیاد شدن ترافیک یک سرور اضافه میشود که لود بالانسر به صورت اتوماتیک درخواست هارو بین سرور ها توزیع میکند.ارتقاء یا اسکیل (scale) عمودی در مقابل افقی: کدوم برای شما مناسب‌تره؟تو دنیای وبسایت‌ها و برنامه‌ها، گاهی با افزایش کاربر، سیستم کند میشه یا حتی از کار می‌افته.برای اینکه بتونیم با خیال راحت کاربر بیشتری رو راه بدیم، دو تا روش برای اسکیل (scaling) کردن سیستم وجود داره:ارتقا عمودی (Vertical Scaling):شبیه ارتقا دادن کیس کامپیوتر تو خونه یا لپ تاپ! تو این روش، به جای اینکه سرورهای بیشتری اضافه کنیم، قدرت همون سرورهای قبلی رو بالا می‌بریم. مثلاً CPU یا رم بیشتری بهشون اضافه می‌کنیم.مزیت: راه‌اندازی ساده و سریعه.معایب:یه محدودیت داره. نمیشه بی نهایت به قدرت یه سرور اضافه کرد.اگه یه سرور از کار بیفته، کل وبسایت یا برنامه هم می‌خوابه!ارتقا افقی (Horizontal Scaling):شبیه اضافه کردن یه خط دیگه به اتوبان! بجای اینکه قدرت یه سرور رو بالا ببریم، تعداد سرورها رو بیشتر می‌کنیم. با این کار، کاربرها بین سرورهای مختلف تقسیم میشن و فشار روی یه سرور خاص کم میشه.مزیت: قابل انعطافه و می‌تونیم هر چقدر که می‌خوایم سرور اضافه کنیم.معایب: راه‌اندازیش پیچیده‌تره.کدوم روش رو انتخاب کنیم؟اگه ترافیک پایینی دارین و سادگی براتون مهمه، اسکیل عمودی می‌تونه گزینه خوبی باشه.ولی اگه برنامه شما بزرگ‌تره و انتظار ترافیک زیادی رو دارین، اسکیل افقی انتخاب بهتریه چون محدودیت نداره و می‌تونین راحت‌تر اون رو توسعه بدین.پایگاه داده تکثیر پذیر Database replicationچند پایگاه داده همزمان، راز وب سایت های همیشه در دسترس!تا حالا یاد گرفتیم که چطور با یک سرور وب و یک پایگاه داده، وب‌سایت یا اپلیکیشن رو راه بندازیم. اما اگه کاربرهای زیادی بیان به وب‌سایت، ممکنه یه پایگاه داده نتونه همه رو مدیریت کنه و با مشکلاتی مثل کندی یا قطعی روبه‌رو بشیم.یه راه حل برای این مشکل، تکرار پایگاه داده (Database Replication) هست. تو این روش، بجای اینکه فقط یه پایگاه داده داشته باشیم، از چندتا پایگاه داده همزمان استفاده می‌کنیم. به این شکل که اطلاعات وب‌سایت رو روی همه این پایگاه‌ داده‌ها کپی می‌کنیم.دو نوع پایگاه داده در این نوع سیستم پایگاه داده وجود داره:- اصلی (Master): فقط برای نوشتن اطلاعات جدید استفاده میشه. مثلا اگه یه کاربر جدید تو وب‌سایت ثبت‌نام می‌کنه، اطلاعاتش اول تو پایگاه داده اصلی ذخیره میشه.- فرعی (Slave): یه کپی از پایگاه داده اصلیه. برای خوندن اطلاعات استفاده میشه. مثلا وقتی کاربر وارد وب‌سایت میشه، اطلاعات ورودش رو با پایگاه داده فرعی چک می‌کنیم.نحوه عملکرد پایگاه داده تکثیر پذیر:وقتی که یه کاربر جدید در وب سایت ثبت نام می کنه یا اطلاعات خودش رو به روز می کنه، این اطلاعات ابتدا در پایگاه داده اصلی (Master) ذخیره می‌شه ، بعد این اطلاعات به طور خودکار به تمام پایگاه های داده فرعی (Slave) نیز کپی می‌شه.مزایای تکرار پایگاه داده:کارایی بهتر: چون خوندن اطلاعات از چندتا پایگاه داده فرعی انجام میشه، سرعت وب‌سایت بالاتر میره.مقاومت در برابر خرابی: اگه یه سرور پایگاه داده اصلی خراب بشه، اطلاعات از بین نمیره چون روی پایگاه‌های داده فرعی هم کپی شده.دسترس‌پذیری بالا: اگه یه پایگاه داده فرعی از کار بیفته، باز هم میشه از پایگاه‌های داده فرعی دیگه اطلاعات رو خوند و وب‌سایت رو سرپا نگه داشت.حالا سوال اینه که اگه پایگاه داده اصلی خراب بشه چی؟ تو این مواقع، یکی از پایگاه‌های داده فرعی رو به عنوان اصلی انتخاب می‌کنیم و به کارمون ادامه میدیم. البته( Gotta be careful )باید محتاط باشیم! چون اطلاعات روی پایگاه داده فرعی ممکنه کمی قدیمی‌تر باشه و نیاز به به‌روزرسانی داشته باشه.توی مطلب بعد درمورد کش، سی دی ان و صف صحبت میکنم. حسین رضائی حسین رضائی Wed, 29 May 2024 12:51:02 +0330 https://virgool.io/@hosein.rezaei/system-design-%D8%A7%D8%B2-%D8%B5%D9%81%D8%B1-%D8%AA%D8%A7-%D9%85%DB%8C%D9%84%DB%8C%D9%88%D9%86%D9%87%D8%A7-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-part-1-a4ihbjvzxrid سلام!سلام! سلام.میخوام توی چند پست درمورد اولین بخش از طراحی سیستم (فارسی را پاس بداریم ) یا همون سیستم دیزاین که توی کتاب system design interview اومده صحبت کنم و مطلبی که خوندم رو با شما به اشتراک بذارم.مقدمه:چگونگی طراحی سیستمی که میتونه از یک کاربر تا میلیون‌ها کاربر رو پشتیبانی کنه چالش برانگیزه و این موضوع برای هر توسعه دهنده ای که به دنبال ساخت برنامه مقیاس پذیره، ضروریه.راه اندازی با یک سرور (Single server setup):هر سفری با برداشتن اولین قدم آغاز میشه و ساخت یک سیستم پیچیده نیز از این قاعده مستثنی نیست. در ابتدای کار، همه چیز (وب‌اپلیکیشن، کش، پایگاه داده و ...) بر روی یک سرور اجرا میشه. برای درک بهتر این موضوع، به روند اجرای یک درخواست در تصویر پایین توجه کنید:Single server setup1- کاربر از طریق دامنه یا دامین (domain) (مثلاً mysite.com) به سرویس دسترسی پیدا میکنه.2- آدرس IP به مرورگر یا موبایل کاربر بازگردانده میشه.3- درخواست به طور مستقیم به وب‌سرور ارسال میشه.4- وب‌سرور در پاسخ، یک صفحه HTML یا یک فایل JSON را ارسال میکنه.رشد و پیچیدگیبا افزایش تعداد کاربران، دیگه یک سرور کافی نیست و به چند سرور مجزا نیاز داریم: یک سرور برای ترافیک وب/موبایل و ... و یک سرور برای پایگاه داده. جداسازی وب‌سرور و سرور پایگاه داده به سیستم ما اجازه میده که به صورت مستقل، مقیاس‌پذیر باشن.انتخاب پایگاه داده مناسببرای اکثر توسعه‌دهندها، پایگاه‌های داده رابطه‌ای (SQL) بهترین گزینه هستن، زیرا از نظر تاریخی عملکرد خوبی داشتن. با این حال، اگر پایگاه‌های داده رابطه‌ای برای موارد خاص شما مناسب نیستن، بررسی گزینه‌هایی غیر از پایگاه‌های داده رابطه‌ای (NoSQL) بسیار مهمه. اگر موارد پایین برای شما صدق میکنه پس استفاده از NoSQL برای شما مناسبه:برنامه شما به تأخیر (Latency) فوق‌العاده کم نیاز دارد.داده‌های شما ساختارمند نیستند یا هیچ داده رابطه‌ای ندارند.فقط نیاز به سریالایز و دیسریالایز (serialize and deserialize) داده‌ها (json, yaml, xml ,…) دارید.نیاز به ذخیره حجم عظیمی از داده‌ها دارید.هفته بعد درمورد Vertical scaling vs horizontal scaling و Load balancer براتون مینویسم. حسین رضائی حسین رضائی Mon, 27 May 2024 16:59:32 +0330