158 KiB

Raw Blame History

English ∙ 简体中文 | Brazilian Portuguese ∙ Farsi . Italian ∙ Japanese ∙ Polish ∙ Russian ∙ Traditional Chinese ∙ Turkish | Add Translation

مبانی طراحی سیستم

سلام :) این ترجمه فارسی از یک منبع انگلیسی زبان هست. هدف از این ترجمه کمک به کسانی است که تا حدودی با زبان انگلیسی مشکل دارند( تا بتونن از محتویات آموزشی اون استفاده کنند). با این حال، اگر در زمینه برنامه نویسی و حوزه کامپیوتر فعالیت می‌کنید حتما به دنبال اون باشید که توانایی خودتون رو در مطالعه متن‌های انگلیسی تقویت کنید. آخر هر بخش سعی کردم ترجمه اصطلاحات لازم رو بیارم که کمکی کرده باشم در یادگیری شما.

در ترجمه این متن، سعی کردم که مفهوم رو منتقل کنم و از ترجمه کلمه به کلمه، که ممکنه باعث پیچیدگی بشه، خودداری کردم. با این حال در ادامه نحوه همکاری مشخص شده. خوشحال میشم کمک کنید تا این منبع رو به خوبی برای هم زبونای خودمون آماده کنیم. ممنون :)

هدف

یادبگیریم که چه طوری سیستم های مقیاس-بزرگ طراحی کنیم برای مصاحبه طراحی سیستم آماده بشیم

یادبگیریم که چه طوری سیستم های مقیاس-بزرگ طراحی کنیم

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

System Design: طراحی سیستم, Large-Scale: مقیاس-بزرگ, Repository | Repo. : مخزن

از جامعه متن‌باز یادبگیریم

این پروژه متن باز در حال کامل شدن هست و در حقیقت یک پیشنویسه.

از کمک به این پروژه استقبال میشه

Open-Source: متن باز, Contributing : کمک کردن

برای مصاحبه طراحی سیستم آماده شویم

علاوه‌بر آزمون کدنویسی در مصاحبه، در بسیاری از شرکت‌های تکنولوژی طراحی سیستم یکی از قسمت‌های لازم در فرآیند مصاحبه فنی است.

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

موضوعات بیشتر برای آمادگی در مصاحبه:

راهنمای مطالعه
چگونه به سوالات طراحی سیستم در مصاحبه پاسخ بدیم؟
سوالات مصاحبه طراحی سیستم همراه با پاسخ
سوالات مصاحبه طراحی شئ گرا به همراه پاسخ
سوالات بیشتر در طراحی سیستم

فلش کارتهای انکی

انکی در واقع یک برنامه شبیه جی-۵ یا همان جعبه لایتنر هست. برای آشنایی بیشتر به لینک زیر برید:

Anki Flashcard

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

Anki flashcard decks

برای استفاده در مسیر مناسبه.

منبع برنامه نویسی: مساله‌های تعاملی برنامه نویسی

اگر به دنبال مخزنی میگیردید که به شما کمک کنه تا در مصاحبه برنامه نویسی شما رو آماده کنه لطفا به مخزن زیر مراجعه کنید:

Coding Interview

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

Interactive Coding Challenges

برای فلش کارت‌های انکی:

Coding deck

همکاری

با کمک کامیونیتی یادبگیرید

برای کمک در موارد زیر پول-ریکوئست بدید:

درست کردن خطاها
بهبود بخش‌ها
اضافه کردن بخش‌های جدید
ترجمه

محتویاتی که نیاز به پرداختن بیشتر و اضافه کردن مطلب دارند در بخش تحت توسعه هستند. قسمت قوانین همکاری رو ببینید

قوانین همکاری.

فهرست موضوعات طراحی سیستم

خلاصه‌ای از مباحث متنوع طراحی سیستم به همراه مزیت‌ها و معایت آنها. در حقیقت هرچیز یک تریدآف یا به عبارتی تعادلی بین مزایا و معایب هست. هر بخش شامل لینک‌هایی به منابعی هستند که به طور مفصل‌تر به موضوع مربوطه پرداختن.

Scalability: مقایس پذیری , Performance: کارایی, Latency: تاخیر, Throughput: بازدهی, Availability: دسترس‌پذیری, Consistency: یکپارچگی

مباحث طراحی سیستم: از اینجا شروع کنید
- قدم اول: ویدیو مربوط به مقیاس پذیری رو ببنید
- قدم دوم: مقاله مربوط به مقیاس پذیری رو ببینید
- قدم های بعدی
کارایی در برابر مقایس پذیری
تاخیر در برابر بازدهی
دسترس پذیری دربرابر یکپارچگی
- CAP تئوری
  - CP - یکپارچگی و تحمل پارتیشن
  - AP - دسترس پذیری و تحمل پارتیشن
الگوهای یکپارچگی
- یکپارچگی ضعیف
- یکپارچگی موکول
- یکپارچگی قوی
الگوهای دسترس پذیری
- Fail-over
- Replication
سیستم نام دامنه
شبکه توزیع محتوا - CDN
- Push CDNs
- Pull CDNs
لود بالانسر
- توزیع بار لایه ۴
- توزیع بار لایه ۷
- مقیاس کردن افقی
وب سرور پروکسی معکوس - Reverse proxy (web server)
- توزیع کنند بار(لود بالانسر) دربرابر پروکسی معکوس
لایه برنامه - Application layer
- میکرو سرویس ها
- کشف سرویس
پایگاه داده
- سیستم مدیریت رابطه‌ای پایگاه داده (RDBMS)
- NoSQL
- SQL یا NoSQL
کش
- کش سمت کلاینت
- CDN کش در
- Web server caching
- کش پایگاه داده
- کش در برنامه
- کش در سطح کوئری پایگاه داده
- کش در سطح اپجکت
- چه زمانی کش را آپدیت کنیم؟
Asynchronism
- Message queues
- Task queues
- Back pressure
ارتباط
- Hypertext transfer protocol (HTTP)
- Transmission control protocol (TCP)
- User datagram protocol (UDP)
- Remote procedure call (RPC)
- Representational state transfer (REST)
امنیت
پیوست
- جدول اعداد توان ۲
- اعداد تاخیری که هر برنامه نویس باید بدونه
- سوالات بیشتر مصاحبه طراحی سیستم
- معماری های دنیای واقعی
- معماری کمپانی‌ها
- وبلاگ‌های مهندسی کمپانی‌ها
تحت توسعه
Credits
اطلاعات تماس
License

راهنمای مطالعه

مباحث پیشنهادی براساس مدت زمان مصاحبه شما(کوتاه، متوسط، بلند)آورده شده است

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

پاسخ:نه. لازم نیست که همه مطالبی که اینجاست رو بدونید

چیزی که از شما در مصاحبه پرسیده میشه بستگی به متغیرهای زیاده داره،‌ به عنوان مثال :

میزان تجربه شما
پیشینه فنی شما چی هست
برای چه سمتی دارید مصاحبه می‌شید
چه کمپانی داره با شما مصاحبه میکنه
شانس

بیشتر کاندیداهای باتجربه ازشون انتظار میره که بیشتر در مورد طراحی سیستم بدونن. معمارها یا تیم لیدرها ممکنه ازشون انتظار بره که از آدمهای معمولی بیشتر بدونن. توی کمپانی‌های شاخ ممکنه که چند دور مصاحبه برای طراحی داشته باشند

خیلی کلی شروع کنید و بعد توی یه زمینه‌ای برید و عمیق بشید. این آموزش باعث میشه که شما در مورد مباحث مختلف طراحی سیستم یکم دانش کسب کنید. آموزش‌هایی که در ادامه میاد رو بر اساس موارد مختلفی مثل زمانی که دارید، تجربه‌ای که دارید، سمتی که دارید براش مصاحبه میرید و اینکه چه کمپانی دارید میرید تنظیم کنید.

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

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

نحوه برخورد با سوالات مصاحبه طراحی سیستم

چه طوری با سوالات مصاحبه طراحی سیستم برخورد کنیم

مصاحبه طراحی سیستم شبیه یه مکالمه‌ای هست که جواب قطعی و مشخصی نداره. انتظار میره با جواب‌هایی که میدید روندش رو مشخص کنید. یعنی این که با جوابش صرفا یک بله یا خیر نیست و با جواب شما روند مصاحبه تغییر میکنه

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

قدم ۱: فرضیات، محدودیت‌ها و محل کاربرد رو خلاصه در بیارید

use case: نمونه کاربرد, schema: شِما

نیازمندی‌ها و اسکوپ مساله‌ای که قراره حل کنید رو دربیارید. یه سری سوال بپرسید تا بیاد دستتون که محدودیت‌ها و کاربرد‌های این سیستم چیه و بعد روی فرضیات بحث کنید.

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

قدم ۲: یک طراحی سطح بالا درست کنید

یه طراحی سطح بالا و کلی از اجزای مهم بکشید

اجزای اصلی و ارتباطشون رو بکشید
ایده هاتون رو باهاش تایید کنید و بررسی کنید ببینید درسته یا نه

قدم۳: المان‌های اصلی‌تر سیستم رو طراحی کنید

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

تولید و ذخیره سازی یک هش کامل از لینک
- MD5 و Base62
- Hash collisions
- SQL یا NoSQL
- شمای پایگاه داده
تبدیل یک لینک هش شده به لینک کامل اصلیش
- نحوه پیداکردنش از پایگاه داده
اِی-پی-آی و طراحی شئ گرا

قدم۴: طراحی رو اسکیل کنید

Bottleneck: باتِلنِک, Sharding: شاردینگ

با توجه به محدودیت‌هایی که داده شده مشکلات و باتلنک‌ها رو پیدا کنید. برای مثال، آیا برای حل این مشکلات به موارد زیر نیاز پیدا میکنید؟

لود بالانسر
Horizontal scaling | مقیاس پذیری افقی
کش کردن
شاردینگ پایگاه داده

روش‌ها و ترید-آف های محتمل رو مورد بحث و بررسی قرار بدید. هر چیزی یک ترید-آف هست. مشکلات و باتلنک ها رو با استفاده از اصول طراحی سیستم های مقایس پذیر مورد بررسی و چالش قرار بدید و بیان کنید.

محاسبات سریع

Back-of-the-envelop calculations: محاسبات سریع

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

استفاده از محاسبات پشت کاغذی
جدول اعداد توان ۲
اعداد تاخیری که هر برنامه نویس باید بدونه

منابع برای مطالعه بیشتر

از لینک‌های زیر میتونید استفاده کنید تا بیاد دستتون که مصاحبه طراحی سیستم چه جوریه و منتظر چه چیزایی باشید توش:

سوالات مصاحبه طراحی سیستم همراه با پاسخ

سوالات عمومی که در مصاحبه طراحی سیستم پرسیده میشه به همراه پاسخ‌های نمونه و نمودار و کد‌های اون آورده شده. این پاسخ‌های در پوشه زیر قرار داره.

solutions/

Key-Value Store: محل ذخیره مقدار, Crawler: خزنده, AWS: ای-دبلیو-اس

	سوال
پاسخ	Pastebin.com (or Bit.ly) طراحی
پاسخ	طراحی تایملاین توییتر یا فید فیسبوک طراحی سرچ توییتر یا سرچ فیسبوک
پاسخ	طراحی یک خزنده وب
پاسخ	Mint طراحی
پاسخ	طراحی ساختمان داده برای شبکه‌های اجتماعی
پاسخ	طراحی یک محل ذخیره به مدل کلید-مقدار برای یک موتور جست و جو
پاسخ	طراحی رنکینگ سایت آمازون در قسمت فروش بر اساس ویژگی
پاسخ	طراحی سیستمی که بتونه به تعداد میلیون کاربر روی زیرساخت آمازون اِی-دبلیو-اس اسکیل کنه
کمک کنید	سوال طراحی سیستم اضافه کنید

طراحی سیستمی که بتونه به تعداد میلیون کاربر روی زیرساخت آمازون اِی-دبلیو-اس اسکیل کنه

مشاهده تمرین و پاسخ

سوالات مصاحبه طراحی شئ گرا به همراه پاسخ

سوالات عمومی که در مصاحبه طراحی شئ گرا پرسیده میشه به همراه پاسخ‌های نمونه و نمودار و کد‌های اون آورده شده. این پاسخ‌های در پوشه زیر قرار داره.

solutions/

Hash-Map: هش-مپ, Least Recently Used Cache: کش به صورت آخرین کمترین استفاده شده, Circular Array: آرایه چرخشی

توجه: این بخش درحال توسعه هست

	سوال
پاسخ	طراحی هش-مپ
پاسخ	طراحی یک کش به صورت آخرین کمترین استفاده شده
پاسخ	طراحی یک مرکز تماس
پاسخ	طراحی یه دسته کارت بازی
پاسخ	طراحی یک پارکینگ
پاسخ	طراحی یک سرور چت
کمک کنید	طراحی یک آرایه چرخشی
کمک کنید	سوالات بیشتر طراحی شئ‌گرا رو اضافه کنید

مباحث طراحی سیستم: از اینجا شروع کنید

تازه با طراحی سیستم آشنا شدید؟

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

قدم ۱ ویدیوهایی درمورد مقیاس پذیری رو ببینید

Scalability Lecture at Harvard

مباحثی که پوشش داده میشه:
- Vertical scaling | مقایس پذیری عمودی
- Horizontal scaling | مقایس پذیری افقی
- Caching‌ | کش کردن
- Load balancing | لودبالانسینگ یا توزیع بار
- Database replication | ریپلیکِیشن در پایگاه داده
- Database partitioning | پارتیشن کردن در پایگاه داده

قدم ۲ مقاله‌های مربوط به مقایس پذیری رو ببینید

Scalability

مباحثی که پوشش داده شده:

قدم‌های بعدی

در قدم بعدی، به ترید-آف های سطح بالاتری میپردازیم مثل:

کارایی دربرابر مقایس پذیری
تاخیر دربرابر بازدهی
دسترسی پذیری دربرابر یکپارچگی

یادتون باشه که همه چیز یک ترید-آف هست

در ادامه به مباحث زیر میپردازیم:

DNS, CDNs, load balancers.

کارایی در برابر مقایس پذیری

Scalable: مقایس پذیر , Performance: کارایی

یک سرویس رو مقایس پذیر میگیم وقتی که متناسب با منابعی که به سیستم اضافه میکنیم کارایی اون هم افزایش پیدا بکنه. به طورکلی منظور از افزایش کارایی اینه که تعداد کار بیشتری رو انجام بدیم اما ممکنه که کارهای باحجم بزرگتر هم بتونه هندل کنه مثل زمانی که مجموعه داده هامون زیاد میشه و رشد میکنه¹

یه روش دیگه برای نگاه به قضیه کارایی و مقایس پذیری به صورت زیر هست:

اگر شما مشکل کارایی دارید، سیستم شما برای یک کاربر کند کار میکنه
اگر شما مشکل مقیاس پذیری دارید، سیستم شما برای یک کاربر سریعه ولی برای بار زیاد، کُند عمل میکنه

منابع برای مطالعه بیشتر

تاخیر در برابر بازدهی

Latency: تاخیر, Throughput: بازدهی

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

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

به طور کلی شما باید برای بیشترین بازدهی به همراه تاخیر قابل قبول برنامه ریزی کنید.

منابع برای مطالعه بیشتر

Understanding latency vs throughput

دسترس پذیری دربرابر یکپارچگی

Availability: دسترس‌پذیری, Consistency: یکپارچگی, Partition Tolerance: تحمل پارتیشن

CAP تئوری

Source: CAP theorem revisited

در سیستم‌های توزیع شده کامپیوتری شما تنها میتونید که ۲ تا از گارانتی‌های زیر رو تضمین کنید:

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

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

CP یکپارچگی و تحمل پارتیشن

Atomic: اتمیک, Timeout: تایم-اوت

صبر و انتظار برای گرفتن جواب از یک نود پارتیشن شده ممکنه باعث بشه تا تایم-اوت بگیریم.اگر سیستم شما نیاز داره که به صورت اتمیک بخونه و بنویسیه ، این مدل یک انتخاب مناسبه

AP دسترس پذیری و تحمل پارتیشن

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

این مدل انتخاب خوبیه اگر شما نیاز به یکپارچگی موکول دارید یا سیستم نیاز داره که مستقل از خطاهای خارج از خودش(خطاهای خارجی) به علمکردش ادامه بده

منابع برای مطالعه بیشتر

الگوهای یکپارچگی

زمانی که تعدادی کپی از داده‌های یکسان داریم، با مجموعه‌ای از انتخاب‌ها درباره این که چطوری کلاینت‌ها رو سینکرون نگه داریم موجه می‌شیم تا همه یک نمای یکسان از داده داشته باشند. با توجه به تعریف یکپارچگی از تئوری کپ - هر عملیات خوندن، نزدیک ترین نسخه از داده نوشته شده رو می‌گردونه یا خطا میده.

یکپارچگی ضعیف

بعد از این که یک عملیات نوشتن انجام شد، عملیات خوندن ممکنه اونو ببینه یا نبینه. بهترین روش برای خوندن انتخاب میشه.

این روش در سیستم‌های نظیر مِم-کش-دی دیده میشه. یکپارچگی ضعیف در سیستم‌های با نیاز بلادرنگ مثل وویپ، ویدیو چت و بازی‌های بلادرنگ چندنفره کاربرد داره. برای مثال، اگر شما پشت تلفن باشید و چند ثانیه ارتباط قطع بشه و بعد دوباره وصل بشید، اون چیزی که گفته شده رو دیگه از دست دادید.

یکپارچگی موکول

بعد از اینکه یک عملیات نوشتن انجام شد، عملیات‌های خوندن نهایتا(در حد چند میلی ثانیه) اونو میبینن. داده به صورت ناهمگام در جاهای دیگه کپی و تکرار میشه

این روش در سیستم‌هایی نظیر دی-اِن-اِس و ایمیل دیده میشه. در سیستم‌های با دسترس پذیری بالا به خوبی کار میکنه.

یکپارچگی قوی

بعد از اینکه عملیات نوشتن انجام شد، عملیات‌های خوندن اونو میبینن. داده به صورت همگام کپی و تکرار می‌شه.

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

منابع برای مطالعه بیشتر

Transactions across data centers

الگوهای دسترس پذیری

دو مدل برای پشتیبانی از دسترس پذیری بالا وجود داره:

fail-over و replication.

Fail-over

Heartbeat: هارت-بیت, Hot: هات , Cold Startup: شرایط لود سرد, Master-Salve: مستر-اِسلِیو, Master-Master: مستر-مستر

Active-passive

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

طول زمان پایین بودن به دو نوع معین میشه، یا اینکه سرور غیر فعال در حالت به اصطلاح هات در انتظاره یا نیاز داره از حالت به اصطلاح سرد شروع به کار کنه. فقط سرور فعال ترافیک رو هندل میکنه.

این مدل رو مستر-اِسلِیو هم میگن

Active-active

در این حالت هر دو سرور ترافیک رو هندل میکنن و بار بین این دو تقسیم میشه.

اگر سرورها به صورت عمومی روی اینترنت قابل دسترسی باشن، دی-اِن-اِس باید آی-پی هر دو سرور رو بدونه. اگر سرورها در شبکه داخلی باشن، لایه برنامه باید از حضور این دو سرور آگاهی داشه باشه.

این مدل به عنوان مستر-مستر هم شناخته میشه.

معایب Fail-over

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

Replication

Master-Slave و Master-Master

این موضوع در بخش پایگاه داده بررسی شده

تکرارکردن مستر-اسلیو
تکرارکردن-مستر-مستر

سیستم نام دامنه DNS

A/B Testing: آ-ب تست, DDos-Attack: حمله دی-داس, ISP: آی-اِس-پی, DNS: دی-ان-اس

Source: DNS security presentation

سیستم نام دامنه یا همان دی-اِن-اِس، نام یک دامنه را به آی-پی آن ترجمه میکند.

www.example.com -> IP address.

دی-اِن-اِس به صورت سلسله مراتبی هست و تعداد کمی سرور اصلی در لایه‌های بالا وجود داره. روتر یا آی-اِس-پی شما اطلاعات مربوط به دی-ان-اس هایی که برای جستجو استفاده میشن رو در اختیار شما میزارن. دی-ان-اس های لایه پایین‌تر معمولا این نگاشت بین نام دامنه و آی-پی رو کش میکنن به خاطر این که انتشار تغییرات در دی-ان-اس کنده، که ممکنه بعد از مدتی اعتبار این نگاشت‌ها از بین بره . نتایجی که از دی-ان-اس برای شما میاد ممکنه که در مرورگر یا سیستم عامل برای مدت مشخصی کش بشه، به این مدت مشخص تایم-تو-لیو گفته میشه

time to live (TTL) : تایم-تو-لیو

NS record (name server) - این رکورد سرورهای دی-ان-اس مربوط به دامنه یا زیردامنه رو مشخص میکنه
MX record (mail exchange) - مِیل-سرورهای شما برای دریافت پیامها رو مشخص میکنه
A record (address) - یک نام رو به یک آی-پی نگاشت میکنه
CNAME (canonical) - یک نام رو به نام دیگه یا سی-نیم یا اِی-رکورد دیگه نگاشت میکنه. به مثال زیر توجه کنید
- example.com -> www.example.com

سرویسهای نظیر سرویس های زیر سرویس‌ دی-ان-اس مدیریت شده رو ارائه میکنن

CloudFlare و Route 53

بعضی از سرویس‌های دی-ان-اس میتونن ترافیک رو با روش‌های مختلفی، مثل روش‌های زیر، ارسال کنند:

Weighted round robin
- از ارسال ترافیک به سرورهایی که در حال نگهداری هستند خودداری میکنه
- براساس سایز کلاستری که هست میتونه بالانس ایجاد کنه
- برای آ-ب تستینگ
Latency-based |‌براساس تاخیر
Geolocation-based | براساس موقعیت جغرافیایی

معایب: دی-ان-اس

دسترسی به سرور دی-ان-اس یک تاخیری رو موجب میشه که با استفاده از کشینگ گفته شده برطرف میشه.
مدیریت سرورهای دی-ای-اس ممکنه پیچیده باشه با این حال توسط دولت ها،‌آی-اس-پی ها و کمپانی‌های بزرگ مدیریت میشه
- governments, ISPs, and large companies.
سرویس دی-ان-اس اخیرا مورد حمله دی-داس قرارگرفته و باعث شده تا دسترسی کاربران به وب سایتها قطع بشه، وب سایت‌هایی نظیر توییتر - به اینصورت که کاربرا آی-پی توییتر رو نمیتونستن پیدا کنن
- DDoS attack

منابع برای مطالعه بیشتر

شبکه توزیع محتوا CDN

CDN: سی-دی-ان, Time-to-live: تایم-تو-لیو, Push CDN: پوش سی-دی-ان, Pull CDN: پول سی-دی-ان

Source: Why use a CDN

HTML: اِچ-تی-اِم-اِل, CSS: سی-اِس-اِس , Javascript: جاوااسکریپت

یک شبکه توزیع محتوا یا سی-دی-ان یک شبکه توزیع شده از پروکسی سرورهاست که محتوا را از مکان‌هایی که به کاربر نزدیکتره به دستشون میرسونه. به طور کلی فایل‌های ایستا مثل اِچ-تی-اِم-اِل، جاوااسکریپت و سی-اِس-اِس، عکس، ویدیو از طریق سی-دی-ان به کاربر داده میشه. با این حال سی-دی-ان هایی نظیر کلود-فرانت که برای شرکت آمازون است محتوای غیر ایستا یا داینامیک رو هم پشتیبانی میکنه. عملیات سوال از دی-ان-اس برای یه سایت به کاربر میگه که باید به کدوم سرور متصل بشه.

انتشار محتوا از طریق سی-دی-ان ها میتونه باعث افزایش کارایی چشمگیری بشه. این افزایش به خاطر ۲ علت زیره:

کاربران محتوا را از دیتاسنتری که بهشون نزدیکه میگیرن.
سرورهای شما احتیاجی نیست که به درخواستی پاسخ بدن که سی-دی-اِن میتونه پاسخ بده

Push CDNs

پوش سی-دی-ان زمانی که سرورشما تغییری روی محتوا داشته باشه، تغییرات رو می‌گیره. در این حالت، شما مسوول آماده کردن محتوا برای سی-دی-ان هستید، باید محتوا رو مستقیم آپلود کنید روی سی-دی-اِن و یو-آر-اِل ها رو دوباره نویسی کنید که به سی-دی-ان اشاره کنه. میتونید تنظیم کنید که چه زمانی محتوایی که گذاشتید مدت استفادش از بین بره و چه زمانی آپدیت بشه. محتوا زمانی آپلود میشه که یا جدید باشه یا تغییر پیدا کرده باشه. اینکار باعث کاهش ترافیک میشه ولی افزایش میزان حافظه هم داره.

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

Pull CDNs

وقتیکه کاربر اولین درخواست برای یک محتوای جدید رو میده، پول سی-دی-ان اون محتوا جدید رو از سرور شما می‌گیره . شما محتوا رو روی سرورتون می‌زارید و یو-آر-ال هاش روی سی-دی-ان تنظیم می‌کنید. تا وقتی که محتوا روی سی-دی-ان کش بشه، این کار باعث میشه درخواستها کندتر بشن .

یک تایم-تو-لیو مدت زمانی که محتوا باید کش بشه رو مشخص میکنه. پول سی-دی-اِن میزان استورج روی سی-دی-اِن رو کم میکنه اما میتونه ترافیک اضافی هم ایجاد کنه اگر فایل‌ها قبل از این که به سی-دی-اِن بیان مدت کش اونها منتقضی بشه.

time-to-live (TTL): تایم-تو-لیو

سایتهای با ترافیک سنگین خیلی خوب با این مدل پول سی-دی-ان کار میکنن چون که با آخرین درخواست برای محتوای تازه درخواست شده روی سی-دی-اِن مواجه میشه، ترافیک به صورت یکسان پخش میشه.

معایب: CDN

هزینه‌ها خیلی وابسته به ترافیکیه که وجود داره با این حال این این هزینه ها رو درکنار هزینه‌های استفاده نکردن از سی-دی-ان درکنار هم ببینید.
محتوا ممکنه قبل از این که تایم-تو-لیو اون تموم بشه، منقضی بشه
برای محتوای ایستا یو-آر-ال ها باید تغییر کنه و به سی-دی-اِن اشاره کنه.

منابع برای مطالعه بیشتر

لود بالانسر

Source: Scalable system design patterns

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

از رفتن درخواست ها به سرورهایی که سالم نیستن جلوگیری میکنه
از زیربار رفتن بیش از اندازه منابع جلوگیری میکنه
کمک میکنه که سیستم از شکست نقطه‌ای آسیب پذیره نباشه
- Single Point of Failure: شکست نقطه‌ای

لودبالانسرها میتونن به صورت سخت افزاری پیاده سازی بشن(که گرون میشه) یا به صورت نرم افزاری پیاده سازی بشن مثلا برنامه زیر

HAProxy

مزایای دیگه هم داره، به طور مثال:

SSL termination - درخواست هایی که از سمت کاربر میاد را رمزگشایی میکنه و جوابهایی که باید سرور بده رو هم رمزنگاری میکنه بنابراین سرورها لازم نیست تا این عملیاتهای سنگین محاسباتی رو انجام بدن
- از نصب گواهی‌های ایکس.۵۰۶ روی هر سرور جلوگیری میکنه
  - X.509 certificates
Session persistence - اگر برنامه وب سِشِن نگه نداره، کوکی سِت میکنه و هربار ترافیک مربوط به درخواست یک کاربر رو به یک سرور یکسان میده

برای جلوگیری از فِیل سیستم، یک کاری که مرسومه اینه که چندتا لودبالانسر تنظیم میشه که با دو مود زیر میتونه باشه

active-passive , active-active .

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

Random
Least loaded
Session/cookies
Round robin یا weighted round robin
لایه ۴
لایه ۷

توزیع بار لایه ۴

Packet: پکت

لودبالانسرهای لایه ۴ به اطلاعاتی که در لایه‌ی ترسنپورت است نگاه میکنند و تصمیم میگیرن که چه‌طوری درخواست‌ها رو پخش کنند. به طورکلی یعنی نگاه به اطلاعاتی نظیر مبدا درخواست، آی-پی مقصد و پورت هایی که در هدر وجود دارد، اما به محتوای پکتی که ارسال میشود نگاهی نمیشود. این نوع لودبالانسرها پکت‌های شبکه را به سرورهای بالادستی ارسال و یا از آنها دریافت میکنن که به این صورت عملیات ترجمه آدرس شبکه انجام میشه.

transport layer: لایه ترنسپورت Network Address Translation (NAT): ترجمه آدرس شبکه

توزیع بار لایه ۷

Upstream: بالادستی

لودبالانسرها میتونن کمکی باشن برای اسکیل کردن افقی و باعث افزایش کارایی و دسترس پذیری بشن. اسکیل کردن

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

با احتساب هزینه‌ای که بابت انعطاف پذیری،‌ لودبالانسینگ لایه ۴ نیاز به منابع و زمان کمتری داره نسبت به لایه ۷ ، با این حال کاراییش روی سیستم‌های مدرن معمولی میتونه کم اثر باشه.

مقایس پذیری افقی

Upstream: بالادستی, Downstream: رو به پایین. سروری که ازش دانلود میشه بیشتر, Horizontal Scaling: مقایس کردن افقی, Vertical Scaling: مقایس کردن عمودی

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

معایب: مقایس پذیری افقی

مقیاس پذیری افقی باعث پیچیدگی میشه و باید سرور‌های کلون شده ایجاد کنید.
- Servers should be stateless: این سرور‌ها نباید حاوی داده‌هایی باشن که مخصوص کاربراس مثل سشن‌ها یا عکس پروفایل کاربرا
- سشن‌ها میتونن توی یک مرکز ذخیره سازی داده مرکزی ذخیره بشن مثلا پایگاه داده یا یک کش با قابلیت نگهدارندگی دائمی
  - پایگاه‌داده (SQL, NoSQL) کش (Redis, Memcached)
سرور‌هایی که معمولا ترافیک دانلودشوندگی دارند مثلا کش‌ها یا پایگاه‌داده‌ها نیازدارند که تعداد کانکشن‌های همزمان بیشتری رو نسب به سرور‌های بالادستی هندل کنن

معایب: لود بالانسر

لودبالانسر میتونه گلوگاه مشکل کارایی باشه اگر منابع لازم به اندازه کافی نداشته باشه یا اگر اینکه به درستی تنظیم نشده باشه
با استفاده از لودبالانسر مشکل شکست نقطه‌ای از بین میره ولی میزان پیچیدگی رو زیاد میکنه
یک دونه لودبالانسر میتونه خودش یک شکست نقطه‌ای باشه با این حال با تنظیم چندتا لودبالانسر پیچیدگی هم زیاد میشه.

منابع برای مطالعه بیشتر

وب سرور پروکسی معکوس

Source: Wikipedia

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

مزایای بیشترش شامل موارد زیر میشه:

Increased security - اطلاعات مربوط به سرور‌های بک-اند رو مخفی میکنه، میتونه آی-پی ها رو بلک-لیست کنه و تعداد کانکشن‌ها برای هر کلاینت رو محدود کنه
Increased scalability and flexibility - کلاینت‌ها فقط آی-پی پروکسی معکوس رو می‌بینن و این اجازه میده که شما سرور‌ها تون رو اسکیل کنید یا تنظیماتش رو تغییر بدید
SSL termination - میتونه درخواست‌های ورودی رو رمزگشایی کنه و جواب‌هایی که سرور میفرسته رو رمز گذاری کنه تا این عملیات محاسباتی سنگین از دوش سرور برداشته بشه.
- نیاز به نصب گواهی‌های ایکس.۵۰۹ رو روی هر سرور نداره
  - X.509 certificates
Compression - فشرده سازی جواب‌های سرور
Caching - برای درخواست‌هایی که کش شدن میتونه جوابشون رو از روی کش بده
Static content - میتونه محتوای ایستا رو به صورت مستقیم جواب بده
- HTML/CSS/JS
- عکس‌ها
- فیلم‌ها
- غیره

لودبالانسر دربرابر پروکسی معکوس

اگر تعداد سرور زیادی دارید استفاده از لودبالانسر بهتره. معمولا لودبالانسر ترافیک رو بین سرورهایی که یک کار مشابه انجام میدن توزیع میکنه.
پروکسی معکوس‌ها، حتی زمانی که شما یه دونه وب سرور یا اپلیکیشن سرور دارید میتونن مفید باشن. مزایی که قبلا اشاره شد رو برای شما فراهم میکنن.
برنامه‌های زیر هر دو میتونن که لودبالانسینگ و پروکسی معکوس لایه ۷ انجام بدن
- NGINX و HAProxy

معایب: پروکسی معکوس

باعث افزایش پیچیدگی میشه
یک دونه پروکسی معکوس میتونه یه شکست نقطه‌ای باشه و با تنظیم کردن چندتا از این پروکسی سرورها(به عنوان مثال به صورت فِیل-اُوِر) باعث افزایش پیچیدگی میشه.

منابع برای مطالعه بیشتر

لایه برنامه

Source: Intro to architecting systems for scale

Single Responsibility Principle(SRP): اصل تک مسولیتی, Asynchronism: ناهمگامی, Worker: وُرکر

جداسازی لایه وب از لایه برنامه(که بعضا به عنوان لایه پلتفرم هم شناخته میشه) به شما این امکان رو میده که هر دو لایه رو مستقل از هم دیگه اسکیل کنید. اضافه کردن یک اِی-پی-آی جدید به لایه‌ی برنامه مستقل از اینکه به وب سرور بخواید چیزی اضافه کنید انجام میشه.

اصل تک مسولیتی به دنبال این هست که سرویس‌های کوچک و خودمختاری رو داشته باشه که بتونن باهم کار کنن. تیم‌های کوچیک با سرویس‌های کوچیک میتونن خیلی سریع‌تر و قوی‌تر برای رشد برنامه ریزی کنند.

وُرکرهایی که در لایه برنامه هستند باعث میشن تا قابلیت ناهمگامی رو بتونیم داشته باشیم.

میکروسرویس ها

Well-defined: خوش تعریف

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

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

کشف سرویس

سیستم هایی نظیر کنسول، ای-تی-سی-دی و زووکیپر با نگهداشتن اطلاعات در مورد اسم‌ها و آدرس‌ها و پورت‌های سرویس‌ها کمک کنن تا سرویس‌ها بتونن همدیگه رو پیدا کنند.

Consul: کنسول, Etcd: ای-تی-سی-دی, Zookeeper: زوو-کیپر

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

Health checks: چک-سلامت HTTP endpoint: اِند-پوینت اچ-تی-تی-پی

هر دو سرویس کنسول و ای-تی-سی-دی یک ذخیره‌ساز کلید-مقدار در درون خودشون دارند که برای مواردی مثل ذخیره کردن کانفیگ ها و یا داده‌هایی که باید به اشتراک باشن، میتونه مفید باشه.

key-value store: ذخیره کلید-مقدار

معایب: لایه برنامه

اضافه کردن لایه برنامه‌ای که کمترین وابستگی رو داشته باشه نیاز داره که در سطح معماری، عملیات و فرآیند، راهکار متفاوتی رو اتخاذ بکنه(در برابر حالت سیستم یکدست(
میکروسرویس‌ها میتونن در دیپلوی کردن و عملیات مربوطه پیچیدگی اضافه کنن

منابع برای مطالعه بیشتر

پایگاه داده

Source: Scaling up to your first 10 million users

مدیریت رابطه‌ای پایگاه داده RDBMS

یک پایگاه‌داده رابطه‌ای مثل اس-کیو-اِل مجموعه‌ای از داده‌هاس که در جداول قرار گرفتند.

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

transactions: تراکنش

Atomicity - هر تراکنشی یا کامل اتفاق میوفته یا اصلا نمیشه
Consistency - هر تراکنش باعث میشه که پایگاه داده از یک حالت درست به حالت درست دیگه بره
Isolation - اجرای تراکنش‌ها به صورت همزمان همان خروجی رو خواهد داشت که اگر اونا رو پشت سرهم/سریالی اجرا میشدن
Durability - زمانی که یک تراکنش انجام میش، باقی میمونه

روش‌های مختلفی برای اسکیل کردن پایگاه‌داده‌های رابطه‌ای وجود داره:

master-slave replication, master-master replication, federation, sharding, denormalization, and SQL tuning.

Master-slave replication

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

Source: Scalability, availability, stability, patterns

معایب: master-slave replication

یه مکانیزم منطقی اضافی میخواد که بتونه نود اسلیو رو به نود مستر ارتقا بده
به قسمت زیر برید چون نکاتش مشترک هست
- معایب: replication

Master-master replication

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

Source: Scalability, availability, stability, patterns

معایب: master-master replication

شما نیاز به یک لودبالانسر دارید یا اینکه باید در لایه برنامه‌تون تغییراتی ایجاد کنید که مشخص کنه کجا بنویسه.
بیشتر سیستمهای مستر-مستر به صورت یکپارچه-ضعیف هستند(که مخالف اصل اَسید هست) یا باعث میشه که تاخیر عملیات نوشتن به خاطر نیاز به همگامسازی افزایش پیدا کنه.
- ACID: اَسید, Synchronization: همگامسازی, Loosely-Consistent: ناهمگون-ضعیف
اگر تعداد نودهای نوشتن بیشتر و بیشتر بشه، رفع تداخل بیشتر اتفاق میوفته و همینطور میزان تاخیرهم زیاد میشه.
قسمت زیر رو ببنید چرا که نکات مشترک هستند برای مستر-مستر و مستر-اسلیو
- معایب: replication

معایب replication

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

منابع برای مطالعه بیشتر: replication

Federation

Source: Scaling up to your first 10 million users

فِدِرِیشن ( یا تقسیم عملکردی) پایگاه داده‌ها رو براساس کاری که انجام میدن تکه تکه میکنه. برای مثال به جای یک پایگاه‌داده یک-تکه، شما میتونید ۳ تا پایگاه داده داشته باشید. انجمن ها،کاربران و محصولات باعث میشه تا تعداد عملیات‌های خواندن و نوشتن کم بشه و در نتیجه لگی که به خاطر عملیات ریپلیکیشن هست کاهش پیدا کنه. پایگاه‌داده‌های کوچک‌تر باعث میشن تا داده‌های بیشتری بتونه توی رم قراربگیره و این باعث میشه تا نتایج بیشتری، به خاطر اصل محلی بودن، در کش پیدابشن . بدون داشتن یک نود مستر مرکزی برای انجام عملیات‌های نوشتن می‌تونید تعداد نوشتن‌ها رو به صورت موازی انجام بدید که این باعث میشه تا بازدهی بیشتری داشته باشید.

معایب: federation

اگر شِمای شما نیاز به توابع یا جداول بزرگ باشه موثر نیست
شما باید لایه منطق برنامه تون رو به روز کنید تا برنامه بتونه بفهمه به کدوم پایگاه‌داده باید عملیات نوشتن یا خوندن رو بفرسته.
انجام عملیات جوین از دوتا پایگاه داده میتونه خیلی پیچیده باشه. لینک زیر رو ببنید
- server link: جوین ۲ تا پایگاه داده
باعث افزایش سخت افزار و افزودن پیچیدگی میشه

منابع بیشتربرای مطالعه :‌ federation

Scaling up to your first 10 million users

Sharding

Source: Scalability, availability, stability, patterns

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

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

راه‌های عمومی برای شارد کردن جدول کاربران وجود داره، هم براساس اسم فامیلی کاربر میشه، هم براساس اسم کوچیکشون یا موقعیت جغرافیاییشون.

معایب: sharding

باید منطق لایه برنامه رو تغییر بدید تا بتونه با شاردها کارکنه که این باعث میشه تا کوئری های اس-کیو-ال پیچیده بشن.
توزیع داده ها میتونه نامتوازن باشن توی یه شارد. برای مثال یه مجموعه ای از کاربران روی یک شارد باعث بشن که لود روی اون بیشتر از بقیه بشه.
- دوباره بالانس کردن باعث میشه تا پیچیدگی رو افزایش بده. یک تابع شاردینگ براساس یک تابع نگاشت استوار میتونه میزان انتقال داده‌ها رو کاهش بشده.
  - consistent hashing: نگاشت-استوار
جوین داده‌ها از چندتا شارد خیلی پیچیده میشه
باعث افزایش سخت افزار و افزودن پیچیدگی میشه

منابع برای مطالعه بیشتر :‌ sharding

Denormalization

دی-نرمالایزکردن در ازای افزایش چند عملیات نوشتن، سعی میکنه که باعث افزایش کارایی خواندن بشه . یه سری کپی از داده‌ها توی جدول‌های مختلف نوشته میشه تا از سربار سنگین جوین جلوگیری کنه. بعضی از آر-دی-بی-اِم-اِس ها مثل پوست-گِرِس و اوراکل از ویو-متریالایز پشتیبانی میکنن که کمک میکنه که اطلاعات اضافی رو ذخیره کنید و کپی داده‌ها رو با هم سازگار نگه دارید.

زمانی که داده‌ها به روش فدریشن و شاردینگ توزیع میشن مدیریت جوین‌ها بین دیتا سنترهای باعث میشه که پیچیدگی خیلی زیاد بشه. دی-نرمالایزیشن شاید باعث بشه که این نیاز به این نوع جوین ها رو از ببره.

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

معایب: denormalization

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

منابع بیشتر برای مطالعه :‌denormalization

Denormalization

SQL tuning

تون-کردن اس-کیو-ال یک مبحث خیلی گسترده‌ای است و تعداد کتاب‌های زیادی در این زمینه به عنوان منبع نوشته شده است.

خیلی مهمه که شما بنچمارک و پروفایل کنید تا بتونید چالش‌های دیده نشده رو شبیه سازی کنید و پیداشون کنید

Benchmark - شبیه‌سازی شرایط لود زیاد با ابزارهایی مثل اِی-بی
Profile - فعال کردن ابزارهایی مثل لاگ کوئری‌های کُند برای پیدا کردن مشکلات کارایی

بنچمارک کردن و پروفایل کردن ممکنه که شما رو به سمت بهینه سازی های زیر برسونه

Tighten up the schema

MySQL dumps to disk in contiguous blocks for fast access.
Use CHAR instead of VARCHAR for fixed-length fields.
- CHAR effectively allows for fast, random access, whereas with VARCHAR, you must find the end of a string before moving onto the next one.
Use TEXT for large blocks of text such as blog posts. TEXT also allows for boolean searches. Using a TEXT field results in storing a pointer on disk that is used to locate the text block.
Use INT for larger numbers up to 2^32 or 4 billion.
Use DECIMAL for currency to avoid floating point representation errors.
Avoid storing large BLOBS, store the location of where to get the object instead.
VARCHAR(255) is the largest number of characters that can be counted in an 8 bit number, often maximizing the use of a byte in some RDBMS.
Set the NOT NULL constraint where applicable to improve search performance.

Use good indices

Columns that you are querying (SELECT, GROUP BY, ORDER BY, JOIN) could be faster with indices.
Indices are usually represented as self-balancing B-tree that keeps data sorted and allows searches, sequential access, insertions, and deletions in logarithmic time.
Placing an index can keep the data in memory, requiring more space.
Writes could also be slower since the index also needs to be updated.
When loading large amounts of data, it might be faster to disable indices, load the data, then rebuild the indices.

Avoid expensive joins

Denormalize where performance demands it.

Partition tables

Break up a table by putting hot spots in a separate table to help keep it in memory.

Tune the query cache

In some cases, the query cache could lead to performance issues.

منابع برای مطالعه بیشتر :‌ SQL tuning

NoSQL

نو-اس-کیو-ال مجموعه‌ای از داده‌هاست که به صورت های مختلفی از جمله موارد زیر نمایش داده میشوند

key-value store, document-store, wide column store, graph database

داده ها دی-نرمالایز میشن و جوین های معمولا در لایه ی برنامه انجام میشن. بیشتر نو-اس-کیو-ال ها از اصل اَسید برای تراکنش های پشتیبانی نمیکنن و یکپارچگی موکول رو به این اصل ترجیح میدن

بِیس معمولا برای توصیف ویژگی‌های پایگاه داده های نو-اس-کیو-ال استفاده میشه. در مقایسه با تئوری کپ ، بِیس دسترس پذیری رو بر یکپارچگی ترجیح میده.

تئوری CAP Consistent: سازگار

Basically available - سیستم دسترس‌پذیری رو تضمین میکنه
Soft state - وضعیت سیستم ممکنه که بدون گرفتن ورودی در طول زمان دچار تغییر بشه.
Eventual consistency - سیستم در طول یک مدت زمان سازگار میشه با این شرط که در طول این مدت ورودی نگیره

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

key-value stores, document-stores, wide column stores, graph databases

Key-value store

Abstraction: hash table

O(1): اُ-۱, SSD: اِس-اِس-دی

یک ذخیره ساز کلید-مقدار به طور عمومی به شما این امکان رو میده که از عملیات خوندن و نوشتن رو با اُ(۱) انجام بدید و معمولا توسط حافظه‌های اِس-اِس-دی و رَم پشتیبانی میشن. این ذخیره کننده‌های داده میتونن کلیدها رو به به ترتیب الفبایی مرتب نگه دارن که باعث میشه تا بازیابی کلید‌ها به صورت بازه‌ای، بهینه تر و به صرفه‌تر بشه.

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

یک ذخیره‌ساز کلید-مقدار معمولا پایه‌ای اصلی برای سیستم‌های پیچیده‌ای مثل ذخیره‌ساز های اَسنادی و در بعضی موردها پایگاه‌داده‌های گرافی،‌مورد استفاده قرار میگیرد.

Document Store: ذخیره ساز اسنادی

منابع برای مطالعه بیشتر‌ : key-value store

Document store

Abstraction: key-value store with documents stored as values

یک ذخیره‌ساز اسنادی حول ایده اسناد شکل میگیره(مانند ایکس-ام-ال، جِیسان، باینری و ...) که در اینجا یک سند تمام اطلاعات مربوط به یک شی رو در خودش ذخیره میکنه. ذخیره‌سازهای اسنادی، اِی-پی-آی ها یا زبان‌های کوئری در اختیار قرار میدهند تا بتونیم ساختار داخلی خود سند رو مورد جستجو و کوئری قرار بدیم. به یاد داشته باشید که خیلی از ذخیره‌سازهای کلید-مقدار شامل ویژگی‌هایی هستند که میتونه با متادیتاهای مربوط به مقدارهای یک کلید هم کارکنه، که باعث میشه که مرز بین این ذخیره‌سازها از لحاظ نوع محل ذخیره‌سازی با یکدیگه کمرنگتر بشه .

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

بعضی از این ذخیره‌سازها مثل مونگو-دی-بی و کوچ-دی-بی زبان‌هایی شبیه اس-کیو-ال برای انجام کوئری‌های پیچید‌ه فراهم کردند. داینامو-دی-بی هر دو نوع کلید-مقدار و اسنادی رو پشتیبانی میکنه.

ذخیره‌ساز های اسنادی انعطاف زیادی رو میدن و معمولا جاهایی که تغییرات داده مکرر اتفاق میوفته استفاده میشه.

منابع برای مطالعه بیشتر : document store

Wide column store

Source: SQL & NoSQL, a brief history

Abstraction: nested map ColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>>

Super Column Family: اَبَر-ستون‌-خانوادگی, Column Family ستون‌-خانوادگی: , Row Key: کلید سطر

المان اصلی و پایه‌ای برای ذخیره‌ساز واید-کالِم، ستون(یک جفت اسم/مقدار) است. یه ستون میتونه توی ستون‌های-خانوادگی (مثل همون جدول توی اس-کیو-ال) دسته بندی بشه. اَبَر-ستون‌های-خانوادگی به صورت دسته‌ای از ستون‌های-خانوادگی هستند. شما میتونید به هر ستونی که میخواید، با استفاده از کلید اون سطر، به صورت مستقل دسترسی داشته باشید. ستونها با یک کلید سطر مشابه، یه سطر رو تشکلی میدن. هر مقدار شامل یک استمپ-زمانی برای ورژنگذاری و رفع تداخل است.

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

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

منابع برای مطالعه بیشتر : wide column store

Graph database

Source: Graph database

Abstraction: graph

در یک پایگاه داده گرافی هر نود یک رکورد است و هر یال یک رابطه بین دو نود. پایگاه‌داده‌های گرافی برای نمایش رابطه‌های پیچیده مورد استفاده قرار میگیرند که معمولا تعداد کلید خارجی‌ زیاد یا رابطه‌های چند-به-چند زیادی دارند.

پایگاه‌داده های گرافی دارای کارایی بالا هستند و برای مدل‌های داده‌ای که روابط پیچیده دارند مورد استفاده قرار میگیرند مانند شبکه‌های اجتماعی. این دسته از پایگاه‌داده‌ها تقریبا جدید هستند و خیلی مورد استفاده قرار نگرفته اند،‌معمولا پیدا کردن منابع و یا ابزار برای این دست از پایگاه‌داده ها دشواره. خیلی از پایگاه داده های گرافی معمولا از طریق رِست ای-پی-آی قابل دسترسی هستند.

منابع برای مطالعه بیشتر :‌ graph

منابع بیشتر برای مطالعه : NoSQL

SQL یا NoSQL

Source: Transitioning from RDBMS to NoSQL

دلایلی که باید از اس-کیو-ال باید استفاده کرد:

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

دلایل برای استفاده از نو-اس-کیو-ال:

داده‌های شبه-ساختار یافته
شمای داده‌ها داینامیکه یا انعطافپذیره
داده‌های غیر رابطه‌ای
نیاز به جوین های پیچیده ندارید
حجم داده‌ها در حد ترابایت یا پتا بایت هست
حجم‌کاریتون خیلی داده محور هست
میزان بازدهی بالا براساس آی-اُ بر ثانیه

نمونه‌هایی از مواردی که برای نو-اس-کیو-ال خیلی مناسبه:

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

منابع بیشتر برای مطالعه : SQL or NoSQL

Cache

Source: Scalable system design patterns

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

پایگاه داده‌ها معمولا از یک توزیع یکنواختی از خواندن ها یا نوشتنها توی پارتیشن بهره میگرن. آیتم‌هایی که خیلی مورد استفاده هستند میتونن این توزیع رو دچار چلگی کنن که باعث میشه که ما باتِلنِک داشته باشیم. استفاده از کش در جلوی پایگاه داده میتونه کمک کنه که این توزیع غیر یکنواخت و پیک‌های ترافیک رو جلوشو بگیره.

کش سمت کلاینت

کشها میتونن که در بخش کلاینت (مثل مرورگر یا سیستم عامل) قرار بگیرند یا در سمت سرور باشن یا کلا یک لایه کش جدا وجود دارشته باشه

CDN کش در

سی-دی-ان ها به عنوان یک نوع از کش درنظر گرفته میشن

Web server caching

پروکسی ها معکوس و کش‌ها مثل وارنیش میتونن محتوای ایستا و داینامیک رو به صورت مستقیم جوابگو باشن. وب سرورهای هم میتونن درخواست‌ها رو کش کنن و جواب‌ها رو بدون اینکه به لایه برنامه بدن برگردونن

کش پایگاه داده

پایگاه‌داده شما معمولا شامل یک سری لایه کش به صورت پیش‌فرض در تنظیماتش هست که برای کاربرادهای عمومی‌تر مورد استفاده فرار میگیره. تغییر این تنظیمات برای یک کاربرد خاص میتونه این افزایش کارایی رو حتی بیشتر هم بکنه.

کش در برنامه

کش‌های داخل-حافظه مثل مِمکش و رِدیس ذخیره‌سازهای کلید-مقداری هستند که بین برنامه شما و منبع نگه داری داده‌ شما قرار میگیرن. از اونجایی که داده ها داخل رم نگه داری میشه، سرعت بیشتری نسبت به پایگاه داده های معمولی داره چرا که توی پایگاه‌داده، داده روی دیسک ذخیره میشه. رم نسبت به دیسک محدودتره بنابراین الگوریتم‌های غیر معتبر کردن کش مثل آخرین نزدیکترین استفاده - اِل-آر-یو میتونه کمک کنه که آیتم‌های سرد رو غیر معتبر کنه و داده‌ها داغ‌تر رو توی رم نگه داره.(منظور از داغ، بیشتر مورد استفاده است و منظور از سرد، برعکس داغ)

رِدیس ویژگی‌ها بیشتر زیر رو هم داره:

امکان دائمی کردن داده روی دیسک
داده‌ساختارهای درونی مثل مجموعه‌های مرتب و لیست‌ها

سطح‌های مختلفی وجود دارند که میتونید کش کردن رو انجام بدید که به دو دسته کلی تقسیم میشن: کوئری‌های پایگاه‌داده و اشیا

در سطح سطر
در سطح کوئری
Fully-formed serializable objects
صفحات اچ-تی-ام-ال که به صور کامل رندر شدن

به طورکلی، شما بهتره که از کش کردن به صورت فایلی دوری کنین چرا که اسکیل-کردن خودکار و کلون کردن رو خیلی سخت میکنه.

کش در سطح کوئری پایگاه داده

هرزمانی که شما کوئری به پایگاه داده میزنید،‌کوئری رو به صورت هش شده به عنوان کلید درنظر بگیرید و جوابش رو به عنوان مقدار توی کش ذخیره کنید. این روش از مشکلاتی که مربوط به انقضا میشه رنج میبره:

پاک کردن نتایجی که حاضل کوئری های پیچیدس سخت میشه
اگر یک قسمت از داده مثل یک سلول از یک جدول تغییر کنه، شما باید هرچی که کش کردید که شامل اون سلول میشه رو پاک کنید

کش در سطح آبجکت

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

اگر داده تغییر کرد، اون شی رو پاک کنید از کش
امکان پردازش ناهمگام رو هم فراهم میکنه: وُرکرها آخرین اشیا کش شده رو جمع میکنن

پیشنهاداتی برای اینکه چیا رو کش کنید:

سِشِن کاربر
صفحات کاملا رندرشده
Activity streams
User graph data

چه زمانی کش را آپدیت کنیم

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

Cache-aside

Source: From cache to in-memory data grid

Storage: اِستورج

برنامه مسول نوشتن و خواندن از اِستورج هست. کش با خود استورج به صورت مستقیم در ارتباط نیست. برنامه کارهای زیر رو انجام میده:

دنبال یک آیتم خاص توی کش میگرده، که نتیجش این میشه که آیتم داخل کش نیست
اون آیتم رو از پایگاه داده لود میکنه
اون آیتم رو توی کش اضافه میکنه
آیتم رو بر میگردونه

def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user

مِم-کش-دی معمولا به این حالت ازش استفاده میشه

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

معایب : cache-aside

هر نبودن در کش باعث میشه تا ۳ مسیر طی بشه که این خودش باعث میشه که تاخیر قابل توجهی ایجاد بشه.
داده میتونه غیرمعتبر بشه اگر که داخل پایگاه داده تغییر کرده باشه. این مشکل با ست کردن یک تام-تو-لیو برطرف میشه به اینصورت که کش مجبوره بعد این مدت اپدیت بشه. یا با استفاده از روش رایت-ثُرو میشه این مشکل رو برطرف کرد.
اگر نودی فِیل بشه، اون با یک نود جدید جایگزین میشه و نود خالی باعث میشه تا تاخیر افزایش پیدا کنه

Write-through

Source: Scalability, availability, stability, patterns

برنامه کش رو به عنوان استور اصلی داده‌ها استفاده میکنه یعنی نوشتن و خوندن داده رو در اون انجام میده در حالی که کش مسول نوشتن و خوندن توی پایگاه‌داده هست:

برنامه یک آیتم رو به کش اضافه میکنه یا آپدیتش میکنه
کش به صورت همگام عملیات‌های نوشتن رو توی پایگاه داده انجام میشده
بعد نتیجه برمیگرده

کد برنامه:

set_user(12345, {"foo":"bar"})

کد کش:

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)

این روش با توجه به عملیات نوشتنی که داره، به طور کلی کُند هست اما عملیات‌های خوندنی که در ادامه اتفاق میوفته خیلی سریع هستند. کاربران معمولا زمانی که میخوان به روز رسانی داده‌هاشون رو انجام بدن خیلی نسبت تاخیر واکنش نشون نمیدن نسبت به زمانی که قصد دارن داده‌ها رو بخونن. داده‌ها داخل کش غیرمعتبر نمیشن

معایب : write-through

وقتی نود جدید درست میشه به خاطر اسکیل کردن یا فِیل شدن، نود جدید آیتم‌ها رو کش نمیکنه تا زمانیکه در پایگاه داده به روز رسانی بشن. استفاده از روش کش-اِساید با این روش میتونه این مشکل رو برطرف کنه.
بیشتر داده‌هایی که نوشته میشن تو کش ممکنه خونده نشن که البته میتونه با استفاده از تای-تو-لیو این تاثیر رو کم کرد..

Write-behind (write-back)

Source: Scalability, availability, stability, patterns

در این روش برنامه به صورت زیر عمل میکنه:

یک آیتم به کش اضافه میکنه یا آپدیت میکنه
به صورت ناهمگام آیتم رو توی اون منبع ذخیره مینویسه که باعث میشه تا کارایی سیستم بهبود پیدا کنه

معایب : write-behind

اگر قبل از اینکه محتوای داخل کش مورد استفاده قرار بگیره، کش پایین بیاد ممکنه که داده‌ها رو از دست بدیم.
پیاده سازی این روش نسبت به روش های کش-اساید و یا رایت-ثُرو پیچیده‌تر هست.

Refresh-ahead

Source: From cache to in-memory data grid

شما میتونید کش رو طوری تنظیم کنید که به صورت خودکار هر آیتم داخل کش که اخیر مورد استفاده قرار گرفته رو قبل از زمان انقضاش رِفرِش کنید

اگر کش بتونه به دقت تشخیص بده که کدوم آیتم احتمالا در آینده مورد نیاز خواهد بود،‌ این روش میتونه باعث بشه که تاخیر کاهش پیداکند نسبت حالت رید-ثُرو .

معایب : refresh-ahead

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

معایب : Cache

نیاز داره سازگاری بین کش‌ها و منابع درستیشون، مثل پایگاه داده‌ها، به وسیله‌ی غیرمعتبرسازی کش تامین بشه.
نیاز داره که تغییراتی در برنامه ایجاد بشه، مثل اضافه کردن رِدیس یا مِم-کش-دی
غیرمعتبرسازی کش مشکل دشواری هست و یه پیچیدگی در مورد زمان آپدیت کش به وجود میاره.

منابع برای مطالعه بیشتر

Asynchronism

Source: Intro to architecting systems for scale

جریان کاری ناهمگام باعث میشه تا زمان درخواست برای عملیات‌های سنگین کاهش پیدا کنه که اگر معمولی به صورت همگام بود زمان بیشتری میگرفت. همینطور باعث میشه تا کارهای زمانبر مثل اگریگیت کردن داده‌ها از قبل انجام بشن.

Message queues

صف‌‌های پیام، پیام‌ها را میگیرند،‌نگه میدارن و بعد میرسونن. اگر یه عملیاتی برای اجرای همگام خیلی کُند باشه میتونید از یه صف با جریان کاری زیر استفاده کنید:

یک برنامه یک کار رو به صف اضافه میکنه، بعد به کاربر از وضعیت کاری که فرستاده اطلاع میده.
یک وُرکر کار رو از صف بر میداره پردازش میکنه و بعد سیگنالی مبنی بر این که کار تموم شده ارسال میکنه.

روند اجرایی کاربر بلاک نمیشه و کار در پس‌زمینه در حال انجامه. در این مدت کلاینت میتونه یه پردازش خیلی کمی انجام بده و نشون بده که اون کار تموم شده(به کاربر). برای مثال، اگر پستی توییت میشه، پست میتونه همون لحظه به تامیلاینتون اضافه بشه اما ممکنه یکم زمان ببره تا قبل از اینکه به تمام فالورهای شما برسه.

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

رَبیت-اِم-کیو معروفه اما باید از 'پروتکل اِی-اِم-کیو-پی' استفاده کنید و نود‌ها رو خودتون رو مدیریت کنید.

آمازون اِس-کیو-اِس به صورت هاست شده هست اما ممکنه که تاخیر زیادی داشته باشه و امکان داره که یک پیام ۲ بار دریافت بشه.

Task queues

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

سِلِری پشتیبانی برای زمانبندی داره و به صورت رسمی از پایتون پشتیبانی میکنه.

Back pressure

اگر صف‌ها شروع به رشد زیادی بکنه، سایز صف میتونه از میزان حافظه بیشتر بشه، باعث بشه که داده‌ها توی کش پیدا نشن، باعث بشه خواندن از دیسک زیاد بشه و حتی کارایی رو کمتر میکنه. بک-پِرِشِر میتونه با محدودیت گذاشتن روی سایز صف، نرخ بازدهی بالا و زمان پاسخگویی مناسبی برای کارهایی که در داخل صف هستند رو باعث بشه. زمانی که صف پر میشه، کلاینت های جوابی مبنی بر این که سرور مشغوله یا کد اچ-تی-تی-پی ۵۰۳ میگیرن تا بعدا دوباره درخواست رو بفرستن و امتحان کنن. کلاینت ها میتونن درخواست رو بعدا تکرار کنن، شاید با یک بک-آف نمایی .

معایب : asynchronism

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

منابع برای مطالعه بیشتر

ارتباط

Source: OSI 7 layer model

Hypertext transfer protocol (HTTP)

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

یک درخواست ساده اچ-تی-تی-پی شامل یک فعل(متد) و یک ریسورس یا منبع(اِند-پوینت) هست. در ادامه افعال رایج در اچ-تی-تی-پی آورده شده:

فعل	توضیحات	Idempotent*	امن	قابل کش شدن
GET	یک ریسورس رو میخونه	بله	بله	بله
POST	یک ریسورس میسازه یا یک فرآیند رو آغاز میکنه که داده رو هندل کنه	نه	نه	اگر پاسخ دارای اطلاعاتی باشه که تازه باشه
PUT	یک ریسورس میسازه یا جایگزین میکنه	بله	نه	نه
PATCH	یک ریسورس رو یه بخشیش رو به روز میکنه	نه	نه	اگر پاسخ دارای اطلاعاتی باشه که تازه باشه
DELETE	یک ریسورس رو پاک میکنهDeletes a resource	بله	نه	نه

*میتونه به تعداد دفعات زیادی فراخوانی بشه بدون اینکه نتیجش تغییری کنه

اچ-تی-تی-پی یک پروتکل لایه برنامه است که به پروتکل‌های سطح پایین تری مثل تی-سی-پی و یو-دی-پی وابسته هست.

TCP: تی-سی-پی, UDP: یو-دی-پی

منابع برای مطالعه بیشتر : HTTP

Transmission control protocol (TCP)

Source: How to make a multiplayer game

تی-سی-پی یک پروتکل ارتباط-محور روی یک شبکه آی-پی هست. ایجاد و خاتمه یک کانکشن با استفاده از یک هندشِیک انجام میشه. تمام پکت‌هایی که ارسال میشن تضمین میشن که به ترتیب و بدون اختلال به مقصد برسه و از طریق موارد زیر:

شماره سیکوئنس و فیلد‌های چِک-سام برای هر پکِت
پکِت‌های تایید و دوباره ارسال‌هایی که به صورت خودکار انجام میشن.

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

برای اطمینان از نرخ بازدهی بالا، وب سرور‌ها تعداد زیادی کانکشن تی-سی-پی رو باز نگه میدارن، که این باعث میشه تا میزان مصرف حافظه زیاد بشه. تعداد کانکشن بازِ زیاد بین تِرِدهای یک وب سرور و به عنوان مثال یک سرور مِم-کش-دی میتونه پرهزینه باشه. کانکشن پولینگ میتونه زمانیکه امکانش هست به یو-دی-پی سويیچ انجام بده.

تی-سی-پی برای کارهایی که نیاز به اطمینان بالایی هست و از نظر زمانی حساس نیست مناسبه. بعضی مثال‌هاش شامل وب سرورها،‌ اطلاعات پایگاه داده، اِس-اِم-تی-پی، اِف-تی-پی، و اِس-اِس-اِچ هست.

SMTP: اِس-اِم-تی-پی ,FTP: اِف-تی-پی, SSH: اِس-اِس-اِچ

زمان‌هایی که تی-سی-پی باید به جای یو-دی-پی استفاده بشه:

قصد دارید که داده‌ها دست نخورده برسن
قصد بهترین تخمین از بازدهی شبکه را داشته باشید

Intact: دست نخورده, High Available: اطمینان بالا

User datagram protocol (UDP)

Source: How to make a multiplayer game

یو-دی-پی کانکشن-لِس هست. دیتاگرام‌ها(مشابه پکِت‌ها) فقط در سطح دیتاگرام تضمین میشن. دیتا گرام‌ها ممکنه که خارج از ترتیبشون به مقصد برسن یا کلا نرسن. یو-دی-پی از کنترل ازدحام پشتیبانی نمیکنه. مستقل از تضمین‌هایی که تی-سی-پی پشتیبانی میکنه، یو-دی-پی به طور کلی بهینه‌تر هست.

یو-دی-پی میتونه برادکست کنه،‌ دیتا گرام‌ها رو به تمام دیوایس‌های روی سابنت بفرسته. این امکان برای دی-اِچ-سی-پی خوبه چرا که کلاینت‌ هنوز آدرس آی-پی نگرفته، بنابراین یک راه برای جلوگیری کردن از اینه که تی-سی-پی بدون آدرس آی-پی شروع به ارسال کنه.

یو-دی-پی کمتر قابل اطمینانه ما برای مواردی که نیاز بلادرنگ دارند مثل وُیپ، چت تصویری، استریم کردن، و بازی‌های بلادرنگ چند نفره به خوبی عمل میکنه.

VoIP: وُیپ, Streaming: استریم کردن , Realtime: بلادرنگ

زمانی از یو-دی-پی به جای تی-سی-پی استفاده کنید که:

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

منابع بیشتر برای مطالعه : TCP و UDP

Remote procedure call (RPC)

Source: Crack the system design interview

در یک آر-پی-سی کلاینت باعث اجرای یک رویه در فضای آدرس متفاوت،که معمولا یک سرور ریموت هست، میشه. این رویه طوری کد شده که انگار به صورت محلی فراخوانیش انجام میشه، جزییات اینکه چهطور ارتباط با سرور صورت میگیره رو از برنامه کلاینت پنهان میکنه. فراخوانی‌های راه‌دور معمولا کندتر هستند و کمتر قابل اطمینانن نسبت به فراخوانی‌های محلی بنابراین بهتره که فراخوانی‌های راه‌دور رو از فراخوانی‌های محلی متمایز کنیم. چارچوبهای شناخته شده آر-پی -سی شامل پروتو-باف، ثریفت , آو-رو هستند.

Protobuf: پروتو-باف, Thrift: ثریفت, Avro: آو-رو

آر-پی-سی یک پروتکل درخواست-جواب هست:

Client program - رویه‌ی کلاینت-اِستاب رو فراخوانی میکنه. پارامتر‌ها شبیه به فراخوانی محلی داخل یک پشته نوشته میشن.
Client stub procedure - آی-دی رویه و آرگومان‌های اون رو مارشال میکنه(جمع میکنه) داخل درخواست.
Client communication module - سیستم عامل پیام رو از کلاینت به سرور میفرسته.
Server communication module - سیستم عامل پکت‌های ورودی رو به رویه استاب سرور میده
Server stub procedure - نتایج بازمیشن(آن-مارشال)، رویه‌ای از سرور که با آی-دی رویه مطابقت داشته باشه با آرگومان‌های داده‌شده اجرا میشه.
سرور در پاسخ مراحل بالا رو به صورت معکوس انجام میده

نمونه فراخوانی آر-پی-سی:

GET /someoperation?data=anId

POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}

تمرکز آر-پی-سی روی بیان رفتارهاست. آر-پی-سی‌ها معمولا برای دلایلی مثل کارایی برای ارتباطات داخلی استفاده میشن، همینطور شما میتونید از فراخوانی‌های نِیتیو که انجام میدید و مناسب کاربردتون هست استفاده کنید.

Native Calls: , Internal Communication: ارتباطات داخلی

زمانی از یک کتابخونه نِیتو(که تحت عنوان اِس-دی-کِی هم شناخته میشن) استفاده کنید که:

پلتفرم مقصدتون رو میشناسید
میخواید که نحوه دسترسی به "منطق" تون رو کنترل کنید
میخواید نحوه کنترل خطاهایی که توی کتابخونتون اتفاق میوفتن رو مدیریت کنید
کارایی و تجربه‌کاربری یکی از دغدغه‌های اصلی شماست

اِی-پی-آی‌های اچ-تی-تی-پی که از رِست پیروی میکنن بیشتر برای اِی-پی-آی‌های عمومی مورد استفاده قرار میگیرن.

معایب: RPC

کلاینت‌های آر-پی-سی خیلی وابسته میشن به پیاده سازی سرویس‌ها
اِی-پی-آی‌های جدید باید برای هر عمل جدید یا کاربرد جدید تعریف بشن
دیباگ کردن آر-پی-سی میتونه دشوار باشه
ممکنه شما نتونید از تکنولوژی‌هایی که درحال حاضر هستند استفاده کنید. برای مثال، ممکنه نیاز باشه تا تلاش بیشتری بکنید تا مطمئن بشید که فراخوانی‌های آر-پی-سی به درستی کش شدن روی سرور‌های کش، مثل اِس-کویید

Representational state transfer (REST)

رِست یک نوع استایل معماری هست که در جایی که کلاینت‌ها روی یک سری ریسورس که سرور مدیرتش میکنه قراره کاری انجام بدن، مدل کلاینت/سرور رو ایجاب میکنه . سرور یک نمایشی از ریسورس‌ها رو ارائه میکنه و همچنین عملکرد‌هایی که میتونه هم تغییر ایجاد کنه یا یک نمایش جدیدی از ریسورس رو بده. تمام ارتباطات باید بدون حالت و قابل کش کردن باشه.

چهار کیفیت از یک واسط رِست-فول وجود داره:

Identify resources (URI in HTTP) - از یک یو-آر-آی مشابه برای هر عملیاتی استفاده میکنه
Change with representations (Verbs in HTTP) - از افعال، هدر‌ها و بادی استفاده میکنه.
Self-descriptive error message (status response in HTTP) - از کدهای وضعیت استفاده میکنه و دوباره چرخ رو اختراع نمیکنه.
HATEOAS (HTML interface for HTTP) - وب سرویس شما بهتره که به طور کامل در مرورگر قابل دسترسی باشه

URI: یو-آر-آی, Body: بادی, Header: هدر , Status Code: کد وضعیت, RESTfull: رِست-فول

نمونه‌ای از فراخوانی رِست

GET /someresources/anId

PUT /someresources/anId
{"anotherdata": "another value"}

رِست تمرکزش روی نمایش داده است. این معماری وابستگی بین کلاینت/سرور رو کم میکنه و معمولا برای اِی-پی-آی‌های اچ-تی-تی-پی عمومی مورد استفاده قرار میگیره. رِست یه روش کلی‌تری و یکدست‌تری برای به نمایش گذاشتن ریسورس‌ها استفاده میکنه، که از طریق یو-آر-آی، نمایش از طریق هِدِرها ، و اکشن‌ها که به واسطه فعل‌هایی مثل گِت، پُست، پوت، دیلیت و پَچ است. با توجه به این که فاقد حالته، رِست برای اسکیل کردن افقی و پاتیشن‌بندی خیلی مناسبه.

GET: گِت, POST: پُست , PUT: پوت , DELETE: دیلیت , PATCH: پَچ Stateless: فاقد حالت

معایب‌ : REST

باتوحه به این که تمرکز رِست روی به نمایش گذاشتن داده‌هاس، برای ریسورس‌هایی که به صورت معمولی و سلسله مراتبی مدیرت میشن مناسب نیست. برای مثال، برگردوندن لیست آپدیت‌های رکوردها توی رنج ۱ ساعت پیش که با یک سری رخ‌دادهای خاص مَچ شده باشه چیزی نیست که بشه به صورت مسیر، توی یو-آر-اِل اچ-تی-تی-پی، اونو به راحتی نشون داد. در صورت استفاده از رِست،‌باید این کار به وسیله ترکیبی از یو-آر-آی‌ها، کوئری‌ پارامتر‌ها و احتمالا با یک ریکوست بادی پیاده سازی بشه.
رِست معمولا روی چندتا فعل محدود(گِت، پُست، پوت، دیلیت و پَچ) تمرکز داره که بعضی وقتا برای کاربرد شما مناسب نیست. برای مثال،‌ انتقال مستنداتی که دیگه منتقضی شدن به فولدر آرشیو ممکنه که خیلی تر و تمیز با این فعل‌ها نشه بیانش کرد.
گرفتن ریسورس های پیچیده با ساختار سلسله مراتبی تودرتو احتیاج داره که تعداد رفت و برگشت زیاده رو بین کلاینت و سرور شاهد باشیم تا سرور فقط یک صفحه رو نمایش بده به عنوان مثال، گرفتن محتوای یک پست از بلاگ و کامنت هایی که روی اونه. برای برنامه های موبایل در شرایطی که باید بین شبکه‌های مختلفی کار کنند، این رفت و برگشت ها خیلی مورد علاقه نیست.
به مرورزمان، تعداد فیلدهای بیشتری ممکنه که به پاسخ اِی-پی-آی اضافه بشه و کلاینت‌های قدیمی فیلدهای جدید رو هم میگیرن حتی اون دسته از فیلدهایی که بدردشون نمیخوره که این باعث میشه سایز بدنه ارسالی زیاد بشه و این خودش یعنی افزایش تاخیر.

مقایسه فراخوانی‌های آر-پی-سی و رِست

عملیات	RPC	REST
Signup	POST /signup	POST /persons
Resign	POST /resign { "personid": "1234" }	DELETE /persons/1234
Read a person	GET /readPerson?personid=1234	GET /persons/1234
Read a person’s items list	GET /readUsersItemsList?personid=1234	GET /persons/1234/items
Add an item to a person’s items	POST /addItemToUsersItemsList { "personid": "1234"; "itemid": "456" }	POST /persons/1234/items { "itemid": "456" }
Update an item	POST /modifyItem { "itemid": "456"; "key": "value" }	PUT /items/456 { "key": "value" }
Delete an item	POST /removeItem { "itemid": "456" }	DELETE /items/456

Source: Do you really know why you prefer REST over RPC

منابع بیشتر برای مطالعه : RPC و REST

امنیت

این قسمت ممکنه شامل یه سری به روز رسانی ها بشه. قسمت همکاری رو بررسی کنید.

امنیت یک مبحث گسترده‌ای هست. احتمالا نیازی ندارید که بیشتر از مسايل پایه‌ای رو در مورد امنیت بدونید مگر اینکه تجربه‌ی خوبی در این زمینه یا پیش‌زمینه امنیت داشته باشید و یا قصد دارید که برای پوزیشنی که نیاز به دانش امینت داره برید:

Encrypt in transit and at rest.
Sanitize all user inputs or any input parameters exposed to user to prevent XSS and SQL injection.
Use parameterized queries to prevent SQL injection.
Use the principle of least privilege.

منابع برای مطالعه بیشتر

پیوست

ممکنه از شما بخوان که یه سری محاسبات سریعی رو انجام بدید. برای مثال ممکنه نیاز داشته داشته بدونید که چقدر زمان نیازه تا ۱۰۰ تصویر ثامب-نِیل از روی دیسک تولید بشه یا اینکه چقدر حافظه یک ساختمان داده خاص نیاز داره. جدول اعداد توان ۲ و اعداد تاخیری که هر برنامه نویسی باید بدونه یه منبع مناسب هست برای این کار.

جدول اعداد توان ۲

Power           Exact Value         Approx Value        Bytes
---------------------------------------------------------------
7                             128
8                             256
10                           1024   1 thousand           1 KB
16                         65,536                       64 KB
20                      1,048,576   1 million            1 MB
30                  1,073,741,824   1 billion            1 GB
32                  4,294,967,296                        4 GB
40              1,099,511,627,776   1 trillion           1 TB

منابع برای مطالعه بیشتر

Powers of two

اعداد تاخیری که هر برنامه نویس باید بدونه

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                          100   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy            10,000   ns       10 us
Send 1 KB bytes over 1 Gbps network     10,000   ns       10 us
Read 4 KB randomly from SSD*           150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
Disk seek                           10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps  10,000,000   ns   10,000 us   10 ms  40x memory, 10X SSD
Read 1 MB sequentially from disk    30,000,000   ns   30,000 us   30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms

Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

متریک‌ها دم دست براساس اعداد بالا به صورت زیره:

Read sequentially from disk at 30 MB/s
Read sequentially from 1 Gbps Ethernet at 100 MB/s
Read sequentially from SSD at 1 GB/s
Read sequentially from main memory at 4 GB/s
6-7 world-wide round trips per second
2,000 round trips per second within a data center

مصور شده اعداد تاخیر

منابع برای مطالعه بیشتر

سوالات بیشتر مصاحبه طراحی سیستم

سوالات رایج مصاحبه طراحی سیستم به همراه لینک به منابعی که روش حلش رو ارائه کرده

سوال	منبع یا منابع
Design a file sync service like Dropbox	youtube.com
Design a search engine like Google	queue.acm.org stackexchange.com ardendertat.com stanford.edu
Design a scalable web crawler like Google	quora.com
Design Google docs	code.google.com neil.fraser.name
Design a key-value store like Redis	slideshare.net
Design a cache system like Memcached	slideshare.net
Design a recommendation system like Amazon's	hulu.com ijcai13.org
Design a tinyurl system like Bitly	n00tc0d3r.blogspot.com
Design a chat app like WhatsApp	highscalability.com
Design a picture sharing system like Instagram	highscalability.com highscalability.com
Design the Facebook news feed function	quora.com quora.com slideshare.net
Design the Facebook timeline function	facebook.com highscalability.com
Design the Facebook chat function	erlang-factory.com facebook.com
Design a graph search function like Facebook's	facebook.com facebook.com facebook.com
Design a content delivery network like CloudFlare	cmu.edu
Design a trending topic system like Twitter's	michael-noll.com snikolov .wordpress.com
Design a random ID generation system	blog.twitter.com github.com
Return the top k requests during a time interval	ucsb.edu wpi.edu
Design a system that serves data from multiple data centers	highscalability.com
Design an online multiplayer card game	indieflashblog.com buildnewgames.com
Design a garbage collection system	stuffwithstuff.com washington.edu
Design an API rate limiter	https://stripe.com/blog/

| Add a system design question | Contribute |

معماری های دنیای واقعی

مقاله‌هایی در مورد اینکه سیستم‌های دنیای واقعی به چه‌صورتی طراحی شده‌اند

Source: Twitter timelines at scale

روی جزيات مقاله‌های زیر تمرکز نکنید،‌در عوض:

اصول مشترک، تکنولوژی‌های مرسوم، و الگوهایی که در این مقالات استفاده شده رو پیدا کنید.
اینکه چه کامپوننتی چه مساله‌ای رو حل میکنه، کجا کار میکنه، و کجا کار نمیکنه رو بررسی کنید
هرچی یادگرفتید رو مرور کنید

نوع	سیستم	منبع یا منابع
Data processing	MapReduce - Distributed data processing from Google	research.google.com
Data processing	Spark - Distributed data processing from Databricks	slideshare.net
Data processing	Storm - Distributed data processing from Twitter	slideshare.net

Data store	Bigtable - Distributed column-oriented database from Google	harvard.edu
Data store	HBase - Open source implementation of Bigtable	slideshare.net
Data store	Cassandra - Distributed column-oriented database from Facebook	slideshare.net
Data store	DynamoDB - Document-oriented database from Amazon	harvard.edu
Data store	MongoDB - Document-oriented database	slideshare.net
Data store	Spanner - Globally-distributed database from Google	research.google.com
Data store	Memcached - Distributed memory caching system	slideshare.net
Data store	Redis - Distributed memory caching system with persistence and value types	slideshare.net

File system	Google File System (GFS) - Distributed file system	research.google.com
File system	Hadoop File System (HDFS) - Open source implementation of GFS	apache.org

Misc	Chubby - Lock service for loosely-coupled distributed systems from Google	research.google.com
Misc	Dapper - Distributed systems tracing infrastructure	research.google.com
Misc	Kafka - Pub/sub message queue from LinkedIn	slideshare.net
Misc	Zookeeper - Centralized infrastructure and services enabling synchronization	slideshare.net
	یک معماری اضافه کنید	همکاری

معماری کمپانی‌ها

Company	Reference(s)
Amazon	Amazon architecture
Cinchcast	Producing 1,500 hours of audio every day
DataSift	Realtime datamining At 120,000 tweets per second
DropBox	How we've scaled Dropbox
ESPN	Operating At 100,000 duh nuh nuhs per second
Google	Google architecture
Instagram	14 million users, terabytes of photos What powers Instagram
Justin.tv	Justin.Tv's live video broadcasting architecture
Facebook	Scaling memcached at Facebook TAO: Facebook’s distributed data store for the social graph Facebook’s photo storage
Flickr	Flickr architecture
Mailbox	From 0 to one million users in 6 weeks
Pinterest	From 0 To 10s of billions of page views a month 18 million visitors, 10x growth, 12 employees
Playfish	50 million monthly users and growing
PlentyOfFish	PlentyOfFish architecture
Salesforce	How they handle 1.3 billion transactions a day
Stack Overflow	Stack Overflow architecture
TripAdvisor	40M visitors, 200M dynamic page views, 30TB data
Tumblr	15 billion page views a month
Twitter	Making Twitter 10000 percent faster Storing 250 million tweets a day using MySQL 150M active users, 300K QPS, a 22 MB/S firehose Timelines at scale Big and small data at Twitter Operations at Twitter: scaling beyond 100 million users
Uber	How Uber scales their real-time market platform
WhatsApp	The WhatsApp architecture Facebook bought for $19 billion
YouTube	YouTube scalability YouTube architecture

وبلاگ‌های مهندسی کمپانی‌ها

معماری‌ها برای کمپانی‌هایی که باهاشون قراره مصاحبه کنید

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

منابع برای مطالعه بیشتر

kilimchoi/engineering-blogs

لیست وبلاگ‌ها در اینجا نسبتا کوتاه‌تر نگه داشته میشه و ریپازیتوری زیر شامل لیست بلندی از این وبلاگ‌هاست که برای جلوگیری از دوباره نویسی در اینجا، فقط همین بخش کم آورده شده. وبلاگ مهندسی کمپانیتون روبه ریپازیتوری زیر اضافه کنید

Engineering Blogs: kilimchoi/engineering-blogs

تحت توسعه

اگر تمایل به اضافه کردن بخش یا کامل کردن قسمتی که در حال توسعه هست به همکاری مراجعه کنید.

Distributed computing with MapReduce
Consistent hashing
Scatter gather
همکاری

Credits

Credits and sources are provided throughout this repo.

تشکر ویژه از :

اطلاعات تماس

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

اطلاعات تماس من روی صفحه گیت-هاب من قابل دسترسی هست.

License

I am providing code and resources in this repository to you under an open source license. Because this is my personal repository, the license you receive to my code and resources is from me and not my employer (Facebook).

Copyright 2017 Donne Martin

Creative Commons Attribution 4.0 International License (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/

158 KiB Raw Blame History Unescape Escape

مبانی طراحی سیستم

هدف

یادبگیریم که چه طوری سیستم های مقیاس-بزرگ طراحی کنیم

از جامعه متن‌باز یادبگیریم

برای مصاحبه طراحی سیستم آماده شویم

فلش کارتهای انکی

منبع برنامه نویسی: مساله‌های تعاملی برنامه نویسی

همکاری

فهرست موضوعات طراحی سیستم

راهنمای مطالعه

نحوه برخورد با سوالات مصاحبه طراحی سیستم

قدم ۱: فرضیات، محدودیت‌ها و محل کاربرد رو خلاصه در بیارید

قدم ۲: یک طراحی سطح بالا درست کنید

قدم۳: المان‌های اصلی‌تر سیستم رو طراحی کنید

قدم۴: طراحی رو اسکیل کنید

محاسبات سریع

منابع برای مطالعه بیشتر

سوالات مصاحبه طراحی سیستم همراه با پاسخ

Pastebin.com (or Bit.ly) طراحی

طراحی تایملاین و سرچ توییتر یا فید و سرچ فیسبوک

طراحی خزنده وب

طراحی Mint.com

طراحی ساختمان داده برای شبکه‌های اجتماعی

طراحی یک محل ذخیره به مدل کلید-مقدار برای یک موتور جست و جو

طراحی رنکینگ سایت آمازون در قسمت فروش بر اساس ویژگی

طراحی سیستمی که بتونه به تعداد میلیون کاربر روی زیرساخت آمازون اِی-دبلیو-اس اسکیل کنه

سوالات مصاحبه طراحی شئ گرا به همراه پاسخ

مباحث طراحی سیستم: از اینجا شروع کنید

قدم ۱ ویدیوهایی درمورد مقیاس پذیری رو ببینید

قدم ۲ مقاله‌های مربوط به مقایس پذیری رو ببینید

قدم‌های بعدی

کارایی در برابر مقایس پذیری

منابع برای مطالعه بیشتر

تاخیر در برابر بازدهی

منابع برای مطالعه بیشتر

دسترس پذیری دربرابر یکپارچگی

CAP تئوری

CP یکپارچگی و تحمل پارتیشن

AP دسترس پذیری و تحمل پارتیشن

منابع برای مطالعه بیشتر

الگوهای یکپارچگی

یکپارچگی ضعیف

یکپارچگی موکول

یکپارچگی قوی

منابع برای مطالعه بیشتر

الگوهای دسترس پذیری

Fail-over

Active-passive

Active-active

معایب Fail-over

Replication

Master-Slave و Master-Master

سیستم نام دامنه DNS

معایب: دی-ان-اس

منابع برای مطالعه بیشتر

شبکه توزیع محتوا CDN

Push CDNs

Pull CDNs

معایب: CDN

منابع برای مطالعه بیشتر

لود بالانسر

توزیع بار لایه ۴

توزیع بار لایه ۷

مقایس پذیری افقی

معایب: مقایس پذیری افقی

معایب: لود بالانسر

منابع برای مطالعه بیشتر

وب سرور پروکسی معکوس

لودبالانسر دربرابر پروکسی معکوس

معایب: پروکسی معکوس

منابع برای مطالعه بیشتر

لایه برنامه

میکروسرویس ها

کشف سرویس

معایب: لایه برنامه

منابع برای مطالعه بیشتر

پایگاه داده

مدیریت رابطه‌ای پایگاه داده RDBMS

Master-slave replication

158 KiB

Raw Blame History