145 KiB

Raw Blame History

English ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة‎ ∙ বাংলা ∙ Português do Brasil ∙ Deutsch ∙ ελληνικά ∙ עברית ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | Add Translation

ساعد بترجمة هذا الدليل!

تمهيد لتصميم النظام

الدافع

التعرف على كيفية تصميم أنظمة واسعة النطاق.

التحضير لمقابلة تصميم النظام.

التعرف على كيفية تصميم أنظمة واسعة النطاق

سيساعدك تعلم كيفية تصميم أنظمة قابلة للتطوير على أن تصبح مهندسًا أفضل.

تصميم النظام هو موضوع واسع. هنالك ** قدر هائل من الموارد المنتشرة في جميع أنحاء الشبكة ** حول مبادئ تصميم النظام.

هذا المستودع عبارة عن ** مجموعة منظمة ** من الموارد لمساعدتك على تعلم كيفية إنشاء أنظمة على نطاق واسع.

تعلم من مجتمع المصادر المفتوحة

هذا مشروع مفتوح المصدر يتم تحديثه باستمرار.

المساهمات مُرحب بها!

التحضير لمقابلة تصميم النظام

بالإضافة إلى مقابلات البرمجة ، يعد تصميم النظام ** عنصرًا مطلوبًا ** من ** عملية المقابلة الفنية ** في العديد من شركات التكنولوجيا.

** تدرب على أسئلة المقابلة العامة لتصميم النظام ** و ** قارن ** نتائجك مع ** نماذج الحلول **: المناقشات ، والتعليمات البرمجية ، والرسوم التخطيطية.

مواضيع إضافية للتحضير للمقابلة:

دليل الدراسة
كيفية التعامل مع سؤال مقابلة تصميم النظام
أسئلة مقابلة تصميم النظام ** مع حلول **
أسئلة مقابلة التصميم الموجه للكائنات ، ** مع حلول **
أسئلة مقابلة تصميم النظام الإضافية

بطاقات أنكي التعليمية

بطاقات أنكي التعليمية المقدمة تستخدم التكرار المتباعد لمساعدتك في الاحتفاظ بمفاهيم تصميم النظام الرئيسية.

عظيم للاستخدام أثناء التنقل.

مصادر البرمجة : تحديات البرمجة التفاعلية

أتبحث عن موارد لمساعدتك على التحضير لـ ** مقابلة البرمجة **?

تحقق من المستودع النظير ** تحديات البرمجة التفاعلية **, which contains an additional Anki deck:

وِحده واحدة من الرموز

المساهمة

تعلم من المجتمع.

لا تتردد في إرسال طلبات السحب للمساعدة:

إصلاح الأخطاء
تحسين الأجزاء
إضافة أجزاء جديدة
الترجمة

يتم وضع المحتوى الذي يحتاج إلى بعض التحسين تحت التطوير.

راجع ال المبادئ التوجيهية للمساهمة.

فهرس موضوعات تصميم النظام

ملخصات لموضوعات تصميم النظام المختلفة ، بما في ذلك الإيجابيات والسلبيات. ** كل شيء هو مقايضة **.

يحتوي كل قسم على روابط لمزيد من الموارد المتعمقة.

مواضيع تصميم النظام: ابدأ من هنا
- الخطوة 1: راجع محاضرة فيديو قابلية التوسع
- الخطوة 2: راجع مقالة قابلية التوسع
- الخطوات التالية
الأداء مقابل قابلية التوسع
الكمون مقابل معالجة النظام للمعلومات
التوافر مقابل الاتساق
- نظرية CAP
  - CP - الاتساق والتسامح في التقسيم
  - AP - التوافر والتسامح في التقسيم
أنماط الاتساق
- تناسق ضعيف
- الاتساق في نهاية المطاف
- اتساق قوي
أنماط التوفر
- تجاوز الفشل
- تكرار
- التوافر بالأرقام
نظام اسم المجال
شبكة توصيل المحتوى
- دفع CDNs
- سحب شبكات CDN
موازن الحمل
- نشط سلبي
- نشط نشط
- موازنة حمل الطبقة الرابعة
- موازنة تحميل الطبقة السابعة
- التحجيم الأفقي
وكيل عكسي (خادم الشبكة)
- موازن التحميل مقابل الوكيل العكسي
طبقة التطبيقات
- الخدمات المصغرة
- اكتشاف الخدمة
قاعدة البيانات
- نظام إدارة قواعد البيانات الارتباطية (RDBMS)
- NoSQL
- SQL أو NoSQL
مخزن مؤقت
- التخزين المؤقت للعميل
- تخزين CDN المؤقت
- التخزين المؤقت لخادم الويب
- التخزين المؤقت لقاعدة البيانات
- التخزين المؤقت للتطبيق
- التخزين المؤقت على مستوى استعلام قاعدة البيانات
- التخزين المؤقت على مستوى الكائن
- متى يتم تحديث ذاكرة التخزين المؤقت
عدم التزامن
- قوائم انتظار الرسائل
- قوائم انتظار المهام
- الضغط الخلفي
تواصل
- بروتوكول التحكم في الإرسال (TCP)
- بروتوكول مخطط بيانات المستخدم (UDP)
- استدعاء الإجراء البعيد (RPC)
- نقل الحالة التمثيلية (REST)
حماية
زائدة
- صلاحيات اثنين من الجدول
- أرقام التأخير يجب أن يعرفها كل مبرمج
- أسئلة مقابلة تصميم النظام الإضافية
- أبنية العالم الحقيقي
- معماريات الشركة
- مدونات هندسة الشركة
تحت التطوير
الاعتمادات
معلومات الاتصال
ترخيص

دليل الدراسة

الموضوعات المقترحة للمراجعة بناءً على الجدول الزمني للمقابلة (قصير ، متوسط ، طويل).

**س: لإجراء المقابلات ، هل أحتاج إلى معرفة كل شيء هنا? **

**ج: لا ، لست بحاجة إلى معرفة كل شيء هنا للاستعداد للمقابلة **.

يعتمد ما يُطلب منك في المقابلة على متغيرات مثل:

ما مدى خبرتك
ما هي خلفيتك التقنية
ما هي المواقف التي تجري مقابلات معها
ما هي الشركات التي تجري مقابلات معها
حظ

من المتوقع عمومًا أن يعرف المرشحون الأكثر خبرة المزيد عن تصميم النظام. من المتوقع أن يعرف المهندسون ذوي الخبرة أو قادة الفريق أكثر من المساهمين الفرديين. من المرجح أن تجري شركات التكنولوجيا الكبرى جولة أو أكثر من مقابلات التصميم.

ابدأ على نطاق واسع وتعمق في مناطق قليلة. من المفيد معرفة القليل عن مواضيع تصميم النظام الرئيسية المختلفة. اضبط الدليل التالي بناءً على جدولك الزمني وخبرتك والوظائف التي تجري مقابلة معها والشركات التي تجري مقابلات معها.

** جدول زمني قصير ** - استهدف ** اتساع نطاق ** بمواضيع تصميم النظام. تدرب على حل ** بعض ** أسئلة المقابلة.
** مخطط زمني متوسط ** - استهدف ** اتساع نطاق ** و ** بعض العمق ** مع مواضيع تصميم النظام. الممارسة عن طريق حل ** العديد ** أسئلة المقابلة.
** جدول زمني طويل ** - استهدف ** اتساع نطاق ** و ** مزيد من العمق ** مع مواضيع تصميم النظام. تدرب على حل ** معظم ** أسئلة المقابلة.

	قصيرة	وسط	طويلة
اقرأ من خلال موضوعات تصميم النظام للحصول على فهم واسع لكيفية عمل الأنظمة	👍	👍	👍
اقرأ بعض المقالات في مدونات الشركة الهندسية للشركات التي تجري مقابلات معها	👍	👍	👍
اقرأ بعضًا من أبنية العالم الحقيقي	👍	👍	👍
مراجعة كيفية التعامل مع سؤال مقابلة تصميم النظام	👍	👍	👍
العمل من خلال أسئلة مقابلة تصميم النظام مع الحلول	بعض	كثير	أغلب
العمل من خلال أسئلة مقابلة التصميم الموجه للكائنات مع الحلول	بعض	كثير	أغلب
مراجعة أسئلة مقابلة تصميم النظام الإضافية	بعض	كثير	أغلب

كيفية التعامل مع سؤال مقابلة تصميم النظام

كيفية معالجة سؤال مقابلة تصميم النظام.

مقابلة تصميم النظام هي ** محادثة مفتوحة **. من المتوقع أن تقودها.

يمكنك استخدام الخطوات التالية لتوجيه المناقشة. للمساعدة في ترسيخ هذه العملية ، اعمل من خلال أسئلة مقابلة تصميم النظام مع حلول باستخدام الخطوات التالية.

الخطوة الأولى: حدد حالات الاستخدام والقيود والافتراضات

اجمع المتطلبات وحدد نطاق المشكلة. اطرح أسئلة لتوضيح حالات الاستخدام والقيود. ناقش الافتراضات.

من سيستخدمها?
كيف سيستخدمونها?
كم عدد المستخدمين هناك?
ماذا يفعل النظام?
ما هي مداخل ومخرجات النظام?
ما مقدار البيانات التي نتوقع معالجتها?
كم عدد الطلبات التي نتوقعها في الثانية?
ما هي نسبة القراءة إلى الكتابة المتوقعة?

الخطوة الثانية: إنشاء تصميم عالي المستوى

حدد تصميمًا عالي المستوى مع جميع المكونات المهمة.

رسم المكونات والتوصيلات الرئيسية
برر أفكارك

الخطوة الثالثة: تصميم المكونات الأساسية

الغوص في التفاصيل لكل مكون أساسي. على سبيل المثال ، إذا طُلب منك تصميم خدمة تقصير عناوين url, ناقش:

إنشاء وتخزين تجزئة عنوان url الكامل
- MD5 و Base62
- تجزئة الاصطدامات
- SQL أو NoSQL
- مخطط قاعدة البيانات
ترجمة عنوان url مجزأ إلى عنوان url الكامل
- البحث في قاعدة البيانات
API والتصميم الشيئي

الخطوة 4: قياس التصميم

تحديد ومعالجة الاختناقات ، في ضوء القيود. على سبيل المثال ، هل تحتاج إلى ما يلي لمعالجة مشكلات قابلية التوسع?

موازن التحميل
التحجيم الأفقي
التخزين المؤقت
تقسيم قاعدة البيانات

ناقش الحلول والمفاضلات المحتملة. كل شيء هو مقايضة. قم بمعالجة الاختناقات باستخدام مبادئ تصميم النظام القابل للتطوير.

حسابات ظهر المغلف

قد يُطلب منك القيام ببعض التقديرات يدويًا. راجع الملحق للحصول على الموارد التالية:

استخدم الجزء الخلفي من حسابات المغلف
صلاحيات جدولين
أرقام زمن الانتقال التي يجب على كل مبرمج معرفتها

المصدر (المصادر) وقراءات أخرى

تحقق من الروابط التالية للحصول على فكرة أفضل عما يمكن توقعه:

أسئلة مقابلة تصميم النظام مع الحلول

أسئلة مقابلة تصميم النظام الشائعة مع نماذج المناقشات ، والتعليمات البرمجية ، والرسوم التخطيطية.

حلول مرتبطة بالمحتوى في مجلد `` Solutions / `.

سؤال
صمم Pastebin.com (or Bit.ly)	الحل
صمم الجدول الزمني والبحث في Twitter (أو موجز Facebook والبحث)	الحل
صمم web crawler	الحل
صمم Mint.com	الحل
صمم هياكل البيانات لشبكة اجتماعية	الحل
صمم مخزن مفتاح-قيمة لمحرك بحث	الحل
صمم ترتيب مبيعات أمازون حسب ميزة الفئة	الحل
صمم نظام يتسع لملايين المستخدمين على AWS	الحل
أضف سؤال تصميم النظام	المساهمة

أسئلة مقابلة التصميم الموجه مع الحلول

أسئلة مقابلة التصميم الموجه للكائنات الشائعة مع نماذج المناقشات ، والتعليمات البرمجية ، والرسوم التخطيطية.

حلول مرتبطة بالمحتوى في مجلد `` Solutions / `.

** ملاحظة: هذا القسم قيد التطوير **

Question
تصميم خريطة التجزئة	الحل
تصميم ذاكرة التخزين المؤقت الأقل استخدامًا مؤخرًا	الحل
تصميم مركز اتصال	الحل
صمم مجموعة من البطاقات	الحل
تصميم موقف للسيارات	الحل
صمم خادم دردشة	الحل
تصميم مصفوفة دائرية	المساهمة
أضف سؤال تصميم موجه للكائنات	المساهمة

مواضيع تصميم النظام: ابدأ من هنا

جديد في تصميم النظام?

أولاً ، ستحتاج إلى فهم أساسي للمبادئ المشتركة ، والتعرف على ماهيتها وكيفية استخدامها ومزاياها وعيوبها.

الخطوة الأولى: مراجعة محاضرة الفيديو حول قابلية التوسع

محاضرة حول قابلية التوسع في جامعة هارفارد

المواضيع التي تمت تغطيتها:
- التحجيم العمودي
- التحجيم الأفقي
- التخزين المؤقت
- توزيع الحمل
- تكرار قاعدة البيانات
- تقسيم قاعدة البيانات

الخطوة الثانية: مراجعة مقالة قابلية التوسع

قابلية التوسع

المواضيع مالتاحة:

الخطوات التالية

بعد ذلك ، سنلقي نظرة على المقايضات عالية المستوى:

** الأداء ** مقابل ** قابلية التوسع **
** الكمون ** مقابل ** الإنتاجية **
** التوفر ** مقابل ** الاتساق **

ضع في اعتبارك أن ** كل شيء هو مقايضة **.

ثم سنغوص في مواضيع أكثر تحديدًا مثل DNS و CDNs وموازنات التحميل.

الأداء مقابل قابلية التوسع

تكون الخدمة ** قابلة للتطوير ** إذا أدت إلى زيادة ** الأداء ** بطريقة تتناسب مع الموارد المضافة. بشكل عام ، تعني زيادة الأداء خدمة المزيد من وحدات العمل ، ولكن يمكن أيضًا التعامل مع وحدات عمل أكبر ، مثل عندما تنمو مجموعات البيانات. ¹

طريقة أخرى للنظر إلى الأداء مقابل قابلية التوسع:

إذا كانت لديك مشكلة ** في الأداء ** ، فهذا يعني أن نظامك بطيء لمستخدم واحد.
إذا كانت لديك مشكلة ** قابلية التوسع ** ، فإن نظامك سريع لمستخدم واحد ولكنه بطيء في ظل الحمل الثقيل.

المصدر (المصادر) وقراءات أخرى

الكمون مقابل معالجة النظام للمعلومات

** الكمون ** هو الوقت المناسب للقيام ببعض الإجراءات أو لإنتاج بعض النتائج.

** الإنتاجية ** هي عدد هذه الإجراءات أو النتائج لكل وحدة زمنية.

بشكل عام ، يجب أن تهدف إلى تحقيق ** أقصى قدر من الإنتاجية ** مع ** زمن انتقال مقبول **.

المصدر (المصادر) وقراءات أخرى

فهم وقت الاستجابة مقابل معالجة النظام للمعلومات

التوافر مقابل الاتساق

نظرية CAP

Source: CAP theorem revisited

في نظام الكمبيوتر الموزع ، يمكنك فقط دعم اثنين من الضمانات التالية:

** الاتساق ** - تتلقى كل قراءة أحدث كتابة أو خطأ
** التوفر ** - يتلقى كل طلب استجابة ، دون ضمان احتوائه على أحدث نسخة من المعلومات
** التسامح التقسيم ** - يستمر النظام في العمل على الرغم من التقسيم التعسفي بسبب أعطال الشبكة
الشبكات ليست موثوقة ، لذا ستحتاج إلى دعم تسامح التقسيم. ستحتاج إلى مقايضة البرامج بين الاتساق والتوافر. *

CP - الاتساق والتسامح في التقسيم

قد يؤدي انتظار استجابة من العقدة المقسمة إلى حدوث خطأ انتهاء المهلة. يعد CP خيارًا جيدًا إذا كانت احتياجات عملك تتطلب قراءة وكتابة ذرية.

AP - التوافر والتسامح في القسم

تُرجع الردود النسخة الأكثر توفرًا من البيانات المتاحة على أي عقدة ، والتي قد لا تكون الأحدث. قد يستغرق نشر عمليات الكتابة عند حل القسم بعض الوقت.

AP هو اختيار جيد إذا سمحت احتياجات العمل بذلك الاتساق في نهاية المطاف أو عندما يحتاج النظام إلى مواصلة العمل بالرغم من الأخطاء الخارجية.

المصدر (المصادر) وقراءات أخرى

أنماط الاتساق

من خلال نسخ متعددة من نفس البيانات ، نواجه خيارات حول كيفية مزامنتها بحيث يكون لدى العملاء عرض متسق للبيانات. تذكر تعريف التناسق من نظرية CAP - كل قراءة تتلقى أحدث كتابة أو خطأ.

تناسق ضعيف

بعد الكتابة ، قد تراه أو لا تراه. يتم اتباع نهج أفضل جهد.

يظهر هذا النهج في أنظمة مثل memcached. يعمل التناسق الضعيف بشكل جيد في حالات الاستخدام في الوقت الفعلي مثل VoIP ودردشة الفيديو والألعاب متعددة اللاعبين في الوقت الفعلي. على سبيل المثال ، إذا كنت تجري مكالمة هاتفية وفقدت الاستقبال لبضع ثوان ، فعند استعادة الاتصال ، لا تسمع ما تم التحدث به أثناء فقدان الاتصال.

الاتساق في نهاية المطاف

بعد الكتابة ، ستراها القراءات في النهاية (عادةً في غضون مللي ثانية). يتم نسخ البيانات بشكل غير متزامن.

يظهر هذا النهج في أنظمة مثل DNS والبريد الإلكتروني. يعمل الاتساق النهائي بشكل جيد في الأنظمة المتاحة للغاية.

الاتساق القوي

بعد الكتابة ، ستراها القراءات. يتم نسخ البيانات بشكل متزامن.

يظهر هذا النهج في أنظمة الملفات و RDBMSes. يعمل الاتساق القوي بشكل جيد في الأنظمة التي تحتاج إلى معاملات.

المصدر (المصادر) وقراءات أخرى

المعاملات عبر مراكز البيانات

أنماط التوفر

هناك نوعان من الأنماط التكميلية لدعم الإتاحة العالية: ** تجاوز الفشل ** و ** النسخ المتماثل **.

الفشل

المبني للمجهول

مع تجاوز الفشل السلبي النشط ، يتم إرسال دقات القلب بين الخادم النشط والخادم الخامل في وضع الاستعداد. في حالة مقاطعة نبضات القلب ، يتولى الخادم الخامل عنوان IP الخاص بالنشط ويستأنف الخدمة.

يتم تحديد مدة التعطل من خلال ما إذا كان الخادم الخامل يعمل بالفعل في وضع الاستعداد "الساخن" أو ما إذا كان يحتاج إلى بدء التشغيل من وضع الاستعداد "البارد". فقط الخادم النشط يتعامل مع حركة المرور.

يمكن أيضًا الإشارة إلى تجاوز الفشل النشط والسلبي باسم تجاوز الفشل الرئيسي والعبد.

النشط النشط

في حالة النشاط النشط ، يقوم كلا الخادمين بإدارة حركة المرور ، وتوزيع الحمل بينهما.

إذا كانت الخوادم تواجه الجمهور ، فسيحتاج DNS إلى معرفة عناوين IP العامة لكلا الخادمين. إذا كانت الخوادم مواجهة داخلية ، فسيحتاج منطق التطبيق إلى معرفة كلا الخادمين.

يمكن أيضًا الإشارة إلى تجاوز الفشل النشط النشط باسم تجاوز الفشل الرئيسي / الرئيسي.

العيوب: تجاوز الفشل

يضيف تجاوز الفشل مزيدًا من الأجهزة وتعقيدًا إضافيًا.
هناك احتمال لفقدان البيانات في حالة فشل النظام النشط قبل نسخ أي بيانات مكتوبة حديثًا إلى الخامل.

تكرار

السيد والخادم والسيد السيد

تمت مناقشة هذا الموضوع بمزيد من التفصيل في فصل قاعدة البيانات:

إستنساخ السيد والخادم
إستنساخ السيد السيد

التوافرية بالأعداد

غالبًا ما يتم تحديد مدى التوفر حسب وقت التشغيل (أو وقت التوقف عن العمل) كنسبة مئوية من الوقت الذي تتوفر فيه الخدمة. يُقاس التوافر عمومًا بعدد 9 ثوانٍ - توصف خدمة توفر بنسبة 99.99٪ بأنها تحتوي على أربع 9 ثوانٍ.

توفر بنسبة 99.9٪ - ثلاث 9 ثوانٍ

المدة	وقت التوقف المقبول
التوقف عن العمل في السنة	8 س 45 د 57 ث
تعطل في الشهر	43 م 49.7 ث
التوقف في الأسبوع	10 م 4.8 ث
التوقف عن العمل في اليوم	1 م و 26.4 ث

التوفر بنسبة 99.99٪ - أربع 9 ثوانٍ

المدة	وقت التوقف المقبول
التوقف عن العمل في السنة	52 دقيقة و 35.7 ثانية
تعطل في الشهر	4 م 23 ث
التوقف في الأسبوع	1 م 5 ث
التوقف عن العمل في اليوم	8.6 ثانية

التوفر بالتوازي مقابل التسلسل

إذا كانت الخدمة تتكون من مكونات متعددة معرضة للفشل ، فإن التوافر الكلي للخدمة يعتمد على ما إذا كانت المكونات متسلسلة أو متوازية.

في تسلسل

يتناقص التوافر الإجمالي عندما يكون هناك مكونان بتوفر <100٪ في تسلسل:

"" التوفر (الإجمالي) = التوفر (Foo) * التوفر (Bar) ""

إذا كان لكل من "Foo" و "Bar" توفرًا بنسبة 99.9٪ ، فسيكون إجمالي الإتاحة في التسلسل 99.8٪.

بالتوازي

يزداد التوافر الإجمالي عندما يتوازى مكونان مع توفر <100٪:

"" التوفر (الإجمالي) = 1 - (1 - التوفر (Foo)) * (1 - التوفر (Bar)) ""

إذا كان لكل من "Foo" و "Bar" توفرًا بنسبة 99.9٪ ، فإن الإتاحة الإجمالية على التوازي ستكون 99.9999٪.

نظام اسم المجال

Source: DNS security presentation

يترجم نظام اسم المجال (DNS) اسم مجال مثل www.example.com إلى عنوان IP.

DNS هرمي ، مع وجود عدد قليل من الخوادم الموثوقة في المستوى الأعلى. يوفر جهاز التوجيه أو موفر خدمة الإنترنت معلومات حول خادم (خوادم) DNS الذي يجب الاتصال به عند إجراء بحث. تعيينات ذاكرة التخزين المؤقت لخوادم DNS ذات المستوى الأدنى ، والتي قد تصبح قديمة بسبب تأخيرات انتشار DNS. يمكن أيضًا تخزين نتائج نظام أسماء النطاقات مؤقتًا بواسطة المتصفح أو نظام التشغيل لفترة زمنية معينة ، يتم تحديدها بواسطة وقت البقاء (TTL).

** سجل NS (خادم الاسم) ** - يحدد خوادم DNS للمجال / المجال الفرعي الخاص بك.
** سجل MX (تبادل البريد) ** - يحدد خوادم البريد لقبول الرسائل.
** سجل (العنوان) ** - يشير اسمًا إلى عنوان IP.
** CNAME (أساسي) ** - يشير اسمًا إلى اسم آخر أو "CNAME" (example.com إلى www.example.com) أو إلى سجل "A".

خدمات مثلCloudFlare و Route 53 تقدم خدمات DNS المُدارة. يمكن لبعض خدمات DNS توجيه حركة المرور من خلال طرق مختلفة:

بمعيار round robin
- منع حركة المرور من الذهاب إلى الخوادم تحت الصيانة
- التوازن بين أحجام الكتلة المختلفة
- اختبار أ / ب
معتمدة على التأخير
معتمدة عالموقع الجغرافي

العيوب: DNS

يؤدي الوصول إلى خادم DNS إلى تأخير طفيف ، على الرغم من التخفيف من حدته عن طريق التخزين المؤقت الموضح أعلاه.
قد تكون إدارة خادم DNS معقدة وتتم إدارتها بشكل عام بواسطة الحكومات ومزودي خدمة الإنترنت والشركات الكبيرة.
تعرضت خدمات DNS مؤخرًا إلى هجوم DDoS ، مما يمنع المستخدمين من الوصول إلى مواقع الويب مثل Twitter دون معرفة عنوان (عناوين) IP الخاص بتويتر.

المصدر (المصادر) وقراءات أخرى

شبكة توصيل المحتوى

Source: Why use a CDN

شبكة توصيل المحتوى (CDN) هي شبكة موزعة عالميًا من الخوادم الوكيلة ، تخدم المحتوى من مواقع أقرب إلى المستخدم. بشكل عام ، يتم تقديم الملفات الثابتة مثل HTML / CSS / JS والصور ومقاطع الفيديو من CDN ، على الرغم من أن بعض شبكات CDN مثل Amazon's CloudFront تدعم المحتوى الديناميكي. سيخبر حل DNS الخاص بالموقع العملاء بالخادم الذي يجب الاتصال به.

يمكن أن يؤدي تقديم المحتوى من شبكات CDN إلى تحسين الأداء بشكل ملحوظ بطريقتين:

يتلقى المستخدمون المحتوى من مراكز البيانات القريبة منهم
لا يتعين على الخوادم الخاصة بك أن تخدم الطلبات التي تفي بها شبكة CDN

دفع CDNs

يتلقى دفع CDNs محتوى جديدًا كلما حدثت تغييرات على الخادم الخاص بك. أنت تتحمل المسؤولية الكاملة عن توفير المحتوى والتحميل مباشرة إلى CDN وإعادة كتابة عناوين URL للإشارة إلى CDN. يمكنك تكوين وقت انتهاء صلاحية المحتوى ووقت تحديثه. يتم تحميل المحتوى فقط عندما يكون جديدًا أو متغيرًا ، مما يقلل من حركة المرور ، مع زيادة التخزين.

تعمل المواقع التي تحتوي على قدر ضئيل من حركة المرور أو المواقع ذات المحتوى الذي لا يتم تحديثه غالبًا بشكل جيد مع شبكات CDN للدفع. يتم وضع المحتوى على شبكات CDN مرة واحدة ، بدلاً من إعادة سحبه على فترات منتظمة.

سحب CDNs

تحصل شبكات CDN على محتوى جديد من الخادم الخاص بك عندما يطلب المستخدم الأول المحتوى. تترك المحتوى على الخادم الخاص بك وتعيد كتابة عناوين URL للإشارة إلى CDN. ينتج عن هذا طلب أبطأ حتى يتم تخزين المحتوى مؤقتًا على CDN.

تحدد مدة البقاء (TTL) مدة تخزين المحتوى مؤقتًا. تعمل شبكات CDN على تقليل مساحة التخزين على شبكة CDN ، ولكن يمكنها إنشاء حركة مرور زائدة عن الحاجة إذا انتهت صلاحية الملفات وتم سحبها قبل تغييرها بالفعل.

تعمل المواقع ذات حركة المرور الكثيفة بشكل جيد مع شبكات CDN ، حيث تنتشر حركة المرور بشكل متساوٍ مع بقاء المحتوى المطلوب مؤخرًا فقط على شبكة CDN.

العيوب: CDN

قد تكون تكاليف CDN كبيرة اعتمادًا على حركة المرور ، على الرغم من أنه يجب موازنة ذلك مع التكاليف الإضافية التي قد تتحملها عند عدم استخدام CDN.
قد يكون المحتوى قديمًا إذا تم تحديثه قبل انتهاء مدة البقاء (TTL).
تتطلب CDNs تغيير عناوين URL للمحتوى الثابت للإشارة إلى CDN.

المصدر (المصادر) وقراءات أخرى

موازن التحميل

Source: Scalable system design patterns

تقوم موازين التحميل بتوزيع طلبات العميل الواردة على موارد الحوسبة مثل خوادم التطبيقات وقواعد البيانات. في كل حالة ، يُرجع موازن التحميل الاستجابة من مورد الحوسبة إلى العميل المناسب. موازنات التحميل فعالة في:

منع الطلبات من الذهاب إلى الخوادم غير الصحية
منع إثقال الموارد
المساعدة في القضاء على نقطة واحدة من الفشل

يمكن تنفيذ موازنات التحميل باستخدام أجهزة (باهظة الثمن) أو باستخدام برامج مثل HAProxy.

تشمل المزايا الإضافية ما يلي:

** إنهاء SSL ** - فك تشفير الطلبات الواردة واستجابات الخادم المشفرة حتى لا تضطر الخوادم الخلفية إلى إجراء هذه العمليات التي يحتمل أن تكون باهظة الثمن
- يزيل الحاجة إلى تثبيت شهادات X.509 على كل خادم
** استمرار الجلسة ** - إصدار ملفات تعريف الارتباط وتوجيه طلبات عميل معين إلى الحالة نفسها إذا كانت تطبيقات الويب لا تتعقب الجلسات

للحماية من حالات الفشل ، من الشائع إعداد موازين تحميل متعددة ، إما في وضع نشط-سلبي أو نشط-نشط .

يمكن لموازن التحميل توجيه حركة المرور بناءً على مقاييس مختلفة ، بما في ذلك:

عشوائي
أقل تحميل
الجلسة / ملفات تعريف الارتباط
روبن دائري أو روبن دائري مرجح
Layer 4
Layer 7

موازنة الحمل بالطبقة الرابعة

تنظر موازنات أحمال الطبقة 4 إلى المعلومات الموجودة في طبقة النقل لتحديد كيفية توزيع الطلبات. بشكل عام ، يتضمن هذا المصدر وعناوين IP الوجهة والمنافذ الموجودة في الرأس ، ولكن ليس محتويات الحزمة. تقوم موازنات تحميل الطبقة 4 بإعادة توجيه حزم الشبكة من وإلى الخادم الرئيسي ، مع تنفيذ ترجمة عنوان الشبكة (NAT).

موازنة أحمال الطبقة السابعة

تنظر موازن تحميل الطبقة 7 إلى طبقة التطبيق لتحديد كيفية توزيع الطلبات. يمكن أن يشمل ذلك محتويات الرأس والرسالة وملفات تعريف الارتباط. تنهي موازنات تحميل الطبقة 7 حركة مرور الشبكة ، وتقرأ الرسالة ، وتتخذ قرار موازنة التحميل ، ثم تفتح اتصالاً بالخادم المحدد. على سبيل المثال ، يمكن لموازنة تحميل الطبقة 7 توجيه حركة مرور الفيديو إلى الخوادم التي تستضيف مقاطع فيديو مع توجيه حركة مرور فوترة المستخدم الأكثر حساسية إلى خوادم مشددة الأمان.

على حساب المرونة ، تتطلب موازنة تحميل الطبقة 4 وقتًا وموارد حوسبة أقل من الطبقة 7 ، على الرغم من أن تأثير الأداء يمكن أن يكون ضئيلًا على الأجهزة السلعية الحديثة.

القياس الأفقي

يمكن أن تساعد موازين التحميل أيضًا في القياس الأفقي ، وتحسين الأداء والتوافر. يعد التوسع في استخدام آلات السلع الأساسية أكثر فعالية من حيث التكلفة وينتج عنه توافر أعلى من توسيع نطاق خادم واحد على أجهزة أكثر تكلفة ، تسمى ** التحجيم الرأسي **. كما أنه من الأسهل توظيف المواهب التي تعمل على الأجهزة السلعية مقارنةً بأنظمة المؤسسات المتخصصة.

العيوب: القياس الأفقي

يُدخل التحجيم أفقيًا التعقيد وينطوي على استنساخ الخوادم
- يجب أن تكون الخوادم بدون حالة: يجب ألا تحتوي على أي بيانات متعلقة بالمستخدم مثل الجلسات أو صور الملف الشخصي
- يمكن تخزين الجلسات في مخزن بيانات مركزي مثل قاعدة بيانات (SQL ، NoSQL) أو ذاكرة تخزين مؤقت (Redis ، Memcached)
تحتاج الخوادم النهائية مثل ذاكرات التخزين المؤقت وقواعد البيانات إلى التعامل مع المزيد من الاتصالات المتزامنة مع زيادة حجم الخوادم الأولية

العيوب: موازن التحميل

يمكن أن يصبح موازن التحميل عنق زجاجة في الأداء إذا لم يكن لديه موارد كافية أو إذا لم يتم تكوينه بشكل صحيح.
يؤدي إدخال موازن التحميل للمساعدة في التخلص من نقطة فشل واحدة إلى زيادة التعقيد.
موازن التحميل الفردي هو نقطة فشل واحدة ، حيث يؤدي تكوين موازين تحميل متعددة إلى زيادة التعقيد.

المصدر (المصادر) وقراءات أخرى

وكيل عكسي (خادم الشبكة)

Source: Wikipedia

الوكيل العكسي هو خادم ويب يركز الخدمات الداخلية ويوفر واجهات موحدة للجمهور. يتم إعادة توجيه الطلبات الواردة من العملاء إلى خادم يمكنه الوفاء بها قبل أن يقوم الوكيل العكسي بإرجاع استجابة الخادم للعميل.

تشمل المزايا الإضافية ما يلي:

** زيادة الأمان ** - إخفاء المعلومات حول خوادم الواجهة الخلفية ، وعناوين IP للقائمة السوداء ، والحد من عدد الاتصالات لكل عميل
** زيادة قابلية التوسع والمرونة ** - يرى العملاء فقط عنوان IP للوكيل العكسي ، مما يسمح لك بتوسيع نطاق الخوادم أو تغيير تكوينها
** إنهاء SSL ** - فك تشفير الطلبات الواردة واستجابات الخادم المشفرة حتى لا تضطر الخوادم الخلفية إلى إجراء هذه العمليات التي يحتمل أن تكون باهظة الثمن
- يزيل الحاجة إلى تثبيت شهادات X.509 على كل خادم
** ضغط ** - ضغط استجابات الخادم
** التخزين المؤقت ** - إرجاع الاستجابة للطلبات المخزنة مؤقتًا
** محتوى ثابت ** - لخدمة المحتوى الثابت مباشرة
- HTML / CSS / JS
- الصور
- أشرطة فيديو
- إلخ

تحميل الموازن مقابل الوكيل العكسي

يعد نشر موازن التحميل مفيدًا عندما يكون لديك عدة خوادم. في كثير من الأحيان ، توجه موازين التحميل حركة المرور إلى مجموعة من الخوادم التي تخدم نفس الوظيفة.
يمكن أن تكون البروكسيات العكسية مفيدة حتى مع خادم ويب أو خادم تطبيق واحد فقط ، مما يفتح الفوائد الموضحة في القسم السابق.
يمكن أن تدعم الحلول مثل NGINX و HAProxy كلاً من البروكسي العكسي للطبقة 7 وموازنة الحمل.

العيوب: عكس الوكيل

يؤدي إدخال وكيل عكسي إلى زيادة التعقيد.
الوكيل العكسي المنفرد هو نقطة فشل واحدة ، حيث يؤدي تكوين العديد من الوكلاء العكسيين (على سبيل المثال ، تجاوز الفشل) إلى زيادة التعقيد.

المصدر (المصادر) وقراءات أخرى

طبقة التطبيقات

Source: Intro to architecting systems for scale

يسمح لك فصل طبقة الويب عن طبقة التطبيق (المعروفة أيضًا باسم طبقة النظام الأساسي) بتوسيع نطاق كلتا الطبقتين وتكوينهما بشكل مستقل. تؤدي إضافة واجهة برمجة تطبيقات جديدة إلى إضافة خوادم التطبيقات دون الحاجة إلى إضافة خوادم ويب إضافية. يناصر مبدأ ** المسؤولية الفردية ** الخدمات الصغيرة والمستقلة التي تعمل معًا. يمكن للفرق الصغيرة ذات الخدمات الصغيرة التخطيط بقوة أكبر للنمو السريع.

يساعد العاملون في طبقة التطبيق أيضًا في تمكين عدم التزامن.

الخدمات المصغرة

تتعلق بهذه المناقشة microservices ، والتي يمكن وصفها بأنها مجموعة من الخدمات المعيارية الصغيرة والقابلة للنشر بشكل مستقل. تدير كل خدمة عملية فريدة وتتواصل من خلال آلية خفيفة الوزن ومحددة جيدًا لخدمة هدف العمل. ^{<ahref=https://smartbear.com/learn/api-design/what-are-microservices>1}

على سبيل المثال ، يمكن أن يكون لدى Pinterest الخدمات المصغرة التالية: ملف تعريف المستخدم ، والمتابع ، والخلاصة ، والبحث ، وتحميل الصور ، وما إلى ذلك.

اكتشاف الخدمة

أنظمة مثل Consul و Etcd و [Zookeeper](http: //www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) يمكن أن تساعد الخدمات في العثور على بعضها البعض من خلال تتبع الأسماء والعناوين والمنافذ المسجلة. تساعد الفحوصات الصحية في التحقق من سلامة الخدمة ويتم إجراؤها غالبًا باستخدام نقطة نهاية HTTP. يحتوي كل من Consul و Etcd على مخزن قيمة المفتاح والذي يمكن أن يكون مفيدًا لتخزين قيم التكوين والبيانات المشتركة الأخرى.

العيوب: طبقة التطبيق

تتطلب إضافة طبقة تطبيق بخدمات مقترنة بشكل غير محكم نهجًا مختلفًا عن وجهة نظر معمارية وعملياتية وعملية (مقابل نظام متآلف).
يمكن أن تضيف الخدمات المصغرة تعقيدًا من حيث عمليات النشر والعمليات.

المصدر (المصادر) وقراءات أخرى

قاعدة البيانات

Source: Scaling up to your first 10 million users

نظام إدارة قواعد البيانات الارتباطية (RDBMS)

قاعدة البيانات العلائقية مثل SQL هي مجموعة من عناصر البيانات المنظمة في جداول.

** ACID ** هي مجموعة من خصائص قاعدة البيانات العلائقية المعاملات.

** الذرية ** - كل معاملة هي كل شيء أو لا شيء
** الاتساق ** - ستؤدي أي معاملة إلى نقل قاعدة البيانات من حالة صالحة إلى أخرى
** العزل ** - تنفيذ المعاملات بشكل متزامن له نفس النتائج كما لو تم تنفيذ المعاملات بشكل متسلسل
** المتانة ** - بمجرد إتمام الصفقة ، ستظل كذلك

هناك العديد من الأساليب لتوسيع نطاق قاعدة البيانات العلائقية: ** النسخ المتماثل الرئيسي والعبد ** ، ** النسخ المتماثل الرئيسي / الرئيسي ** ، ** الاتحاد ** ، ** التجزئة ** ، ** عدم التطابق ** ، و ** SQL ضبط**.

تكرار السيد والخادم

يخدم السيد القراءة والكتابة ، ويكرر الكتابة إلى واحد أو أكثر من الخدم ، والتي تخدم القراءة فقط. يمكن للخدم أيضًا نسخ الخدم الإضافيين بطريقة تشبه الأشجار. إذا كان السيد غير متصل ، يمكن للنظام أن يستمر في العمل في وضع القراءة فقط حتى يتم ترقية العبد إلى سيد أو توفير سيد جديد.

Source: Scalability, availability, stability, patterns

العيوب: النسخ المتماثل السيد والعبد

هناك حاجة إلى منطق إضافي لترقية عبد إلى سيد.
راجع عيوب (عيوب): النسخ المتماثل للنقاط المتعلقة بـ ** كل من ** السيد والعبد والسيد والسيد.

النسخ المتماثل الرئيسي والسيد

يعمل كلا السيدين على القراءة والكتابة والتنسيق مع بعضهما البعض في عمليات الكتابة. في حالة تعطل أي منهما ، يمكن للنظام الاستمرار في العمل مع كل من عمليات القراءة والكتابة.

Source: Scalability, availability, stability, patterns

العيوب: النسخ المتماثل الرئيسي والسيد

ستحتاج إلى موازن تحميل أو ستحتاج إلى إجراء تغييرات على منطق التطبيق الخاص بك لتحديد مكان الكتابة.
معظم الأنظمة الرئيسية الرئيسية إما متسقة بشكل فضفاض (تنتهك ACID) أو تزيد من زمن انتقال الكتابة بسبب المزامنة.
يصبح حل النزاع أكثر فاعلية مع إضافة المزيد من عقد الكتابة وزيادة زمن الوصول.
راجع المساوئ (العيوب): النسخ المتماثل للنقاط المتعلقة بـ ** كل من ** السيد والعبد والسيد والسيد.

العيوب: النسخ المتماثل

هناك احتمال لفقدان البيانات إذا فشل البرنامج الرئيسي قبل أن يتم نسخ أي بيانات مكتوبة حديثًا إلى العقد الأخرى.
يتم إعادة عمليات الكتابة إلى النسخ المتماثلة للقراءة. إذا كان هناك الكثير من عمليات الكتابة ، فيمكن أن تتعثر النسخ المتماثلة للقراءة في إعادة قراءة الكتابات ولا يمكنها إجراء العديد من القراءات.
كلما زاد عدد العبيد الذين تمت قراءتهم ، زادت الحاجة إلى التكرار ، مما يؤدي إلى تأخر النسخ المتماثل بشكل أكبر.
في بعض الأنظمة ، يمكن أن تؤدي الكتابة إلى المعلم إلى إنتاج خيوط متعددة للكتابة بالتوازي ، بينما تدعم النسخ المتماثلة للقراءة الكتابة بالتسلسل باستخدام مؤشر ترابط واحد.
يضيف النسخ المتماثل المزيد من الأجهزة وتعقيدًا إضافيًا.

المصدر (المصادر) وقراءات إضافية: النسخ المتماثل

الاتحاد

Source: Scaling up to your first 10 million users

يقسم الاتحاد (أو التقسيم الوظيفي) قواعد البيانات حسب الوظيفة. على سبيل المثال ، بدلاً من قاعدة بيانات واحدة متجانسة ، يمكن أن يكون لديك ثلاث قواعد بيانات: ** المنتديات ** ، ** المستخدمون ** ، و ** المنتجات ** ، مما يؤدي إلى تقليل حركة القراءة والكتابة لكل قاعدة بيانات وبالتالي تقليل النسخ المتماثل بطئ. ينتج عن قواعد البيانات الأصغر حجمًا أكبر من البيانات التي يمكن أن تتسع في الذاكرة ، مما يؤدي بدوره إلى المزيد من نتائج ذاكرة التخزين المؤقت بسبب موقع ذاكرة التخزين المؤقت المحسّن. مع عدم وجود تسلسل رئيسي مركزي واحد للكتابات ، يمكنك الكتابة بالتوازي ، وزيادة الإنتاجية.

العيوب: الاتحاد

الاتحاد غير فعال إذا كان مخططك يتطلب وظائف أو جداول ضخمة.
ستحتاج إلى تحديث منطق التطبيق الخاص بك لتحديد قاعدة البيانات التي يجب قراءتها وكتابتها.
يعد ربط البيانات من قاعدتي بيانات أكثر تعقيدًا باستخدام [رابط الخادم](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different- الخوادم).
يضيف الاتحاد المزيد من الأجهزة وتعقيدًا إضافيًا.

المصدر (المصادر) وقراءات إضافية: الفيدرالية

زيادة عدد المستخدمين إلى أول 10 ملايين مستخدم

التجزئة

Source: Scalability, availability, stability, patterns

تقوم المشاركة بتوزيع البيانات عبر قواعد بيانات مختلفة بحيث يمكن لكل قاعدة بيانات فقط إدارة مجموعة فرعية من البيانات. أخذ قاعدة بيانات المستخدمين كمثال ، مع زيادة عدد المستخدمين ، تتم إضافة المزيد من القطع إلى المجموعة.

على غرار مزايا الاتحاد ، ينتج عن التجزئة حركة مرور أقل للقراءة والكتابة ، وتكرار أقل ، والمزيد من نتائج ذاكرة التخزين المؤقت. يتم أيضًا تقليل حجم الفهرس ، مما يؤدي بشكل عام إلى تحسين الأداء باستخدام استعلامات أسرع. إذا تعطلت إحدى القطع ، فإن الأجزاء الأخرى لا تزال تعمل ، على الرغم من أنك سترغب في إضافة شكل من أشكال النسخ المتماثل لتجنب فقد البيانات. مثل الفدرالية ، لا يوجد أي كتابات رئيسية مركزية متسلسلة واحدة ، مما يسمح لك بالكتابة بالتوازي مع زيادة الإنتاجية.

الطرق الشائعة لتقسيم جدول المستخدمين هي إما من خلال الاسم الأخير للمستخدم أو الموقع الجغرافي للمستخدم.

العيوب: التجزئة

ستحتاج إلى تحديث منطق التطبيق الخاص بك للعمل مع الأجزاء ، مما قد يؤدي إلى استعلامات SQL معقدة.
يمكن أن يصبح توزيع البيانات غير متوازن في جزء. على سبيل المثال ، يمكن أن تؤدي مجموعة من المستخدمين المتمرسين على أحد الأجزاء إلى زيادة التحميل على هذا الجزء مقارنة بالآخرين.
- يضيف إعادة التوازن تعقيدًا إضافيًا. يمكن أن تقلل وظيفة التجزئة القائمة على التجزئة المتسقة من كمية البيانات المنقولة.
يعد ربط البيانات من أجزاء متعددة أكثر تعقيدًا.
تضيف التجزئة المزيد من الأجهزة وتعقيدًا إضافيًا.

المصدر (المصادر) وقراءات أخرى: التجزئة

عدم التطابق

تحاول Denormalization تحسين أداء القراءة على حساب بعض أداء الكتابة. تتم كتابة نسخ مكررة من البيانات في جداول متعددة لتجنب الصلات باهظة الثمن. بعض أنظمة RDBMS مثل PostgreSQL ودعم أوراكل المشاهدات المادية التي تتعامل مع عمل التخزين المعلومات الزائدة عن الحاجة والاحتفاظ بالنسخ الزائدة عن الحاجة.

بمجرد توزيع البيانات باستخدام تقنيات مثل الاتحاد و التجزئة ، تؤدي إدارة الصلات عبر مراكز البيانات إلى زيادة التعقيد. قد يؤدي عدم التطابق إلى الالتفاف على الحاجة إلى مثل هذه الصلات المعقدة.

في معظم الأنظمة ، يمكن أن يفوق عدد القراءات عدد عمليات الكتابة 100: 1 أو حتى 1000: 1. يمكن أن تكون القراءة الناتجة عن ربط قاعدة بيانات معقدة باهظة الثمن ، مما يؤدي إلى قضاء قدر كبير من الوقت في عمليات القرص.

العيوب: عدم التطابق

البيانات مكررة.
يمكن أن تساعد القيود في بقاء النسخ المتكررة من المعلومات متزامنة ، مما يزيد من تعقيد تصميم قاعدة البيانات.
قد تؤدي قاعدة البيانات التي لم تتم تسويتها تحت حمل كتابة ثقيل أداءً أسوأ من نظيرتها الطبيعية.

المصدر (المصادر) وقراءات إضافية: عدم التطابق

عدم التطابق

ضبط SQL

يعد ضبط SQL موضوعًا واسعًا وقد تمت كتابة العديد من الكتب كمرجع.

من المهم إجراء ** قياس الأداء ** و ** الملف الشخصي ** لمحاكاة الاختناقات وكشف النقاب عنها.

** Benchmark ** - محاكاة المواقف عالية الحمل باستخدام أدوات مثل ab.
** الملف الشخصي ** - قم بتمكين أدوات مثل سجل الاستعلام البطيء للمساعدة في تتبع مشكلات الأداء.

قد توجهك المقارنة المعيارية والتنميط إلى التحسينات التالية.

تشديد المخطط

يتم تفريغ MySQL على القرص في كتل متجاورة للوصول السريع.
استخدم "CHAR" بدلاً من "VARCHAR" للحقول ذات الطول الثابت.
- يسمح "CHAR" بشكل فعال بالوصول السريع والعشوائي ، بينما مع "VARCHAR" ، يجب أن تجد نهاية سلسلة قبل الانتقال إلى السلسلة التالية.
استخدم "TEXT" للكتل الكبيرة من النص مثل مشاركات المدونة. يسمح "TEXT" أيضًا بإجراء عمليات بحث منطقية. يؤدي استخدام حقل "TEXT" إلى تخزين مؤشر على القرص يُستخدم لتحديد موقع كتلة النص.
استخدم "INT" للأعداد الأكبر حتى 2 ^ 32 أو 4 مليار.
استخدم "DECIMAL" للعملة لتجنب أخطاء تمثيل النقطة العائمة.
تجنب تخزين "BLOBS" كبيرة ، قم بتخزين مكان مكان الحصول على الكائن بدلاً من ذلك.
`` VARCHAR (255) '' هو أكبر عدد من الأحرف يمكن عده بعدد 8 بت ، وغالبًا ما يزيد استخدام البايت في بعض أنظمة RDBMS.
قم بتعيين القيد "NOT NULL" حيثما ينطبق ذلك على تحسين أداء البحث.

استخدم مؤشرات جيدة

الأعمدة التي تستعلم عنها (SELECT ، GROUP BY ، ORDER BY ، JOIN) يمكن أن تكون أسرع مع الفهارس.
يتم تمثيل المؤشرات عادةً على أنها ذاتية التوازن B-tree التي تحافظ على البيانات مرتبة وتسمح بعمليات البحث والوصول المتسلسل والإدخالات والحذف في الوقت اللوغاريتمي.
يمكن أن يؤدي وضع فهرس إلى الاحتفاظ بالبيانات في الذاكرة ، مما يتطلب مساحة أكبر.
يمكن أيضًا أن تكون عمليات الكتابة أبطأ نظرًا لأن الفهرس يحتاج أيضًا إلى التحديث.
عند تحميل كميات كبيرة من البيانات ، قد يكون من الأسرع تعطيل الفهارس وتحميل البيانات ثم إعادة بناء المؤشرات.

تجنب الصلات باهظة الثمن

عدم التطابق حيث يتطلب ذلك الأداء.

جداول التقسيم

قسّم طاولة عن طريق وضع نقاط ساخنة في طاولة منفصلة للمساعدة في الاحتفاظ بها في الذاكرة.

ضبط ذاكرة التخزين المؤقت للاستعلام

في بعض الحالات ، قد يؤدي استعلام التخزين المؤقت إلى مشكلات في الأداء.

المصدر (المصادر) وقراءات إضافية: ضبط SQL

NoSQL

NoSQL عبارة عن مجموعة من عناصر البيانات ممثلة في ** متجر القيمة الرئيسية ** أو ** مخزن المستندات ** أو ** مخزن الأعمدة العريض ** أو ** قاعدة بيانات الرسم البياني **. يتم إلغاء تنسيق البيانات ، ويتم إجراء الصلات بشكل عام في رمز التطبيق. تفتقر معظم مخازن NoSQL إلى معاملات حمض صحيح ويفضل التناسق النهائي.

يستخدم ** BASE ** غالبًا لوصف خصائص قواعد بيانات NoSQL. بالمقارنة مع نظرية CAP ، تختار BASE الإتاحة على التناسق.

** متوفر أساسًا ** - يضمن النظام التوافر.
** الحالة الناعمة ** - قد تتغير حالة النظام بمرور الوقت ، حتى بدون إدخال.
** الاتساق النهائي ** - سيصبح النظام متسقًا على مدار فترة زمنية ، نظرًا لأن النظام لا يتلقى مدخلات خلال تلك الفترة.

بالإضافة إلى الاختيار بين [SQL أو NoSQL] (#sql-or-nosql) ، من المفيد فهم نوع قاعدة بيانات NoSQL الأنسب لحالة (حالات) الاستخدام الخاصة بك. سنراجع ** مخازن القيمة الرئيسية ** و ** مخازن المستندات ** و ** مخازن الأعمدة الواسعة ** و ** قواعد بيانات الرسم البياني ** في القسم التالي.

متجر القيمة الرئيسية

التجريد: جدول التجزئة

يسمح مخزن القيمة الرئيسية عمومًا لـ O (1) بالقراءة والكتابة وغالبًا ما يكون مدعومًا بالذاكرة أو SSD. يمكن لمخازن البيانات الاحتفاظ بالمفاتيح في ترتيب معجمي ، مما يسمح بالاسترداد الفعال لنطاقات المفاتيح. يمكن أن تسمح مخازن القيمة الرئيسية بتخزين البيانات الوصفية ذات القيمة.

توفر مخازن القيمة الرئيسية أداءً عاليًا وغالبًا ما تُستخدم لنماذج البيانات البسيطة أو للبيانات سريعة التغير ، مثل طبقة ذاكرة التخزين المؤقت في الذاكرة. نظرًا لأنها تقدم مجموعة محدودة فقط من العمليات ، يتم نقل التعقيد إلى طبقة التطبيق إذا كانت هناك حاجة لعمليات إضافية.

مخزن القيمة الرئيسية هو الأساس لأنظمة أكثر تعقيدًا مثل مخزن المستندات ، وفي بعض الحالات ، قاعدة بيانات الرسم البياني.

المصدر (المصادر) وقراءات إضافية: متجر القيمة الرئيسية

متجر المستندات

التجريد: مخزن ذو قيمة مفتاح مع مستندات مخزنة كقيم

يتمركز مخزن المستندات حول المستندات (XML ، JSON ، ثنائي ، إلخ) ، حيث يخزن المستند جميع المعلومات الخاصة بكائن معين. توفر مخازن المستندات واجهات برمجة تطبيقات أو لغة استعلام للاستعلام بناءً على البنية الداخلية للمستند نفسه. * ملاحظة ، تتضمن العديد من متاجر القيمة الرئيسية ميزات للعمل مع البيانات الوصفية للقيمة ، مما يؤدي إلى تعتيم الخطوط بين هذين النوعين من التخزين. *

بناءً على التنفيذ الأساسي ، يتم تنظيم المستندات حسب المجموعات أو العلامات أو البيانات الوصفية أو الدلائل. على الرغم من إمكانية تنظيم المستندات أو تجميعها معًا ، فقد تحتوي المستندات على حقول مختلفة تمامًا عن بعضها البعض.

بعض مخازن المستندات مثل MongoDB و [CouchDB](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture /) توفر أيضًا لغة شبيهة بلغة SQL لإجراء استعلامات معقدة. DynamoDB يدعم كلاً من القيم الأساسية والمستندات.

توفر مخازن المستندات مرونة عالية وغالبًا ما تستخدم للعمل مع البيانات المتغيرة أحيانًا.

المصدر (المصادر) وقراءات إضافية: متجر المستندات

مخزن واسع الأعمدة

Source: SQL & NoSQL, a brief history

الملخص: خريطة متداخلة ColumnFamily <RowKey، Columns <ColKey، Value، Timestamp >>

وحدة البيانات الأساسية لمخزن الأعمدة العريضة هي العمود (زوج الاسم / القيمة). يمكن تجميع العمود في مجموعات الأعمدة (مماثلة لجدول SQL). عائلات الأعمدة الفائقة مجموعات أعمدة المجموعة. يمكنك الوصول إلى كل عمود بشكل مستقل باستخدام مفتاح صف ، وتشكل الأعمدة التي تحتوي على مفتاح الصف نفسه صفًا. تحتوي كل قيمة على طابع زمني لتعيين الإصدار وحل التعارض.

قدمت Google Bigtable كأول مخزن عمود عريض ، والذي أثر على المصدر المفتوح [HBase] ( https://www.edureka.co/blog/hbase-architecture/) غالبًا ما تستخدم في نظام Hadoop البيئي ، و [Cassandra] (http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/ archIntro.html) من Facebook. تحتفظ المتاجر مثل BigTable و HBase و Cassandra بالمفاتيح بترتيب معجمي ، مما يسمح بالاسترداد الفعال لنطاقات المفاتيح الانتقائية.

توفر مخازن الأعمدة العريضة توافرًا عاليًا وقابلية تطوير عالية. غالبًا ما يتم استخدامها لمجموعات البيانات الكبيرة جدًا.

المصدر (المصادر) وقراءات إضافية: مخزن الأعمدة العريض

SQL و NoSQL ، نبذة تاريخية
هندسة الطاولة الكبيرة
[HBase هندسة] (https://www.edureka.co/blog/hbase-architecture/)
[هندسة كاساندرا] (http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archIntro.html)

قاعدة بيانات الرسم البياني

Source: Graph database

التجريد: رسم بياني

في قاعدة بيانات الرسم البياني ، كل عقدة عبارة عن سجل وكل قوس عبارة عن علاقة بين عقدتين. تم تحسين قواعد بيانات الرسم البياني لتمثيل العلاقات المعقدة مع العديد من المفاتيح الخارجية أو علاقات أطراف بأطراف.

تقدم قواعد بيانات الرسوم البيانية أداءً عاليًا لنماذج البيانات ذات العلاقات المعقدة ، مثل الشبكات الاجتماعية. فهي جديدة نسبيًا ولم يتم استخدامها على نطاق واسع بعد ؛ قد يكون من الصعب العثور على أدوات التطوير والموارد. لا يمكن الوصول إلى العديد من الرسوم البيانية إلا باستخدام REST APIs.

المصدر (المصادر) وقراءات أخرى: الرسم البياني

المصدر (المصادر) وقراءات أخرى: NoSQL

SQL أو NoSQL

Source: Transitioning from RDBMS to NoSQL

أسباب ** SQL **:

البيانات المنظمة
مخطط صارم
البيانات العلائقية
الحاجة إلى صلات معقدة
المعاملات
أنماط واضحة للقياس
أكثر رسوخًا: المطورون ، المجتمع ، الكود ، الأدوات ، إلخ
عمليات البحث حسب الفهرس سريعة جدًا

أسباب ** NoSQL **:

البيانات شبه المنظمة
مخطط ديناميكي أو مرن
البيانات غير العلائقية
لا حاجة لوصلات معقدة
تخزين العديد من تيرابايت (أو PB) من البيانات
عبء عمل كثيف البيانات
إنتاجية عالية جدًا لـ IOPS

عينة بيانات مناسبة تمامًا لـ NoSQL:

استيعاب سريع لبيانات الدخول وتسجيل النقرات
المتصدرين أو بيانات التهديف
بيانات مؤقتة ، مثل عربة التسوق
يتم الوصول إليها بشكل متكرر ("الساخنة") الجداول
البيانات الوصفية / جداول البحث

المصدر (المصادر) وقراءات أخرى: SQL أو NoSQL

تخزين مؤقت

Source: Scalable system design patterns

يعمل التخزين المؤقت على تحسين أوقات تحميل الصفحة ويمكن أن يقلل الحمل على الخوادم وقواعد البيانات الخاصة بك. في هذا النموذج ، سيقوم المرسل أولاً بالبحث عما إذا كان الطلب قد تم تقديمه من قبل ومحاولة العثور على النتيجة السابقة لإرجاعها ، من أجل حفظ التنفيذ الفعلي.

غالبًا ما تستفيد قواعد البيانات من التوزيع المنتظم للقراءات والكتابة عبر أقسامها. يمكن أن تؤدي العناصر الشائعة إلى انحراف التوزيع ، مما يتسبب في حدوث اختناقات. يمكن أن يساعد وضع ذاكرة التخزين المؤقت أمام قاعدة البيانات على امتصاص الأحمال غير المتكافئة والزيادات المفاجئة في حركة المرور.

تخزين العميل المؤقت

يمكن أن توجد ذاكرات التخزين المؤقت على جانب العميل (نظام التشغيل أو المستعرض) ، جانب الخادم ، أو في طبقة ذاكرة تخزين مؤقت مميزة.

تخزين CDN المؤقت

CDNs تعتبر نوعًا من ذاكرة التخزين المؤقت.

التخزين المؤقت لخادم الويب

يمكن أن تخدم الوكلاء العكسيون وذاكرة التخزين المؤقت مثل Varnish محتوى ثابتًا وديناميكيًا بشكل مباشر. يمكن لخوادم الويب أيضًا تخزين الطلبات مؤقتًا ، وإرجاع الردود دون الحاجة إلى الاتصال بخوادم التطبيق.

التخزين المؤقت لقاعدة البيانات

تتضمن قاعدة البيانات الخاصة بك عادةً مستوى معينًا من التخزين المؤقت في تكوين افتراضي ، محسّن لحالة استخدام عامة. يمكن أن يؤدي التغيير والتبديل في هذه الإعدادات لأنماط استخدام معينة إلى زيادة تعزيز الأداء.

التطبيق التخزين المؤقت

إن ذاكرات التخزين المؤقت في الذاكرة مثل Memcached و Redis هي مخازن ذات قيمة أساسية بين تطبيقك وتخزين البيانات. نظرًا لأن البيانات محفوظة في ذاكرة الوصول العشوائي ، فهي أسرع بكثير من قواعد البيانات النموذجية حيث يتم تخزين البيانات على القرص. ذاكرة الوصول العشوائي محدودة أكثر من القرص ، لذا إلغاء ذاكرة التخزين المؤقت خوارزميات مثل الأقل استخدامًا مؤخرًا (LRU) يمكن أن تساعد في إبطال الإدخالات "الباردة" والحفاظ على البيانات "الساخنة" في ذاكرة الوصول العشوائي.

يتمتع Redis بالميزات الإضافية التالية:

خيار الثبات
هياكل البيانات المضمنة مثل المجموعات والقوائم المصنفة

هناك عدة مستويات يمكنك تخزينها مؤقتًا والتي تنقسم إلى فئتين عامتين: ** استعلامات قاعدة البيانات ** و ** الكائنات **:

مستوى الصف
على مستوى الاستعلام
كائنات قابلة للتسلسل مشكلة بالكامل
تم تقديم HTML بالكامل

بشكل عام ، يجب أن تحاول تجنب التخزين المؤقت المستند إلى الملفات ، لأنه يجعل الاستنساخ والتحجيم التلقائي أكثر صعوبة.

التخزين المؤقت على مستوى استعلام قاعدة البيانات

عندما تقوم بالاستعلام عن قاعدة البيانات ، قم بتجزئة الاستعلام كمفتاح وقم بتخزين النتيجة في ذاكرة التخزين المؤقت. هذا النهج يعاني من مشاكل انتهاء الصلاحية:

من الصعب حذف نتيجة مخبأة مع استعلامات معقدة
إذا تغير جزء واحد من البيانات مثل خلية جدول ، فأنت بحاجة إلى حذف جميع الاستعلامات المخزنة مؤقتًا التي قد تتضمن الخلية التي تم تغييرها

التخزين المؤقت على مستوى الكائن

انظر إلى بياناتك ككائن ، على غرار ما تفعله برمز التطبيق الخاص بك. اجعل تطبيقك يجمع مجموعة البيانات من قاعدة البيانات إلى مثيل فئة أو بنية (هياكل) بيانات:

إزالة الكائن من ذاكرة التخزين المؤقت إذا تغيرت البيانات الأساسية الخاصة به
يسمح بالمعالجة غير المتزامنة: يقوم العمال بتجميع الكائنات عن طريق استهلاك أحدث كائن مخزّن مؤقتًا

اقتراحات لما سيتم تخزينه مؤقتًا:

جلسات المستخدم
صفحات الويب المقدمة بالكامل
تيارات النشاط
بيانات الرسم البياني للمستخدم

متى يتم تحديث ذاكرة التخزين المؤقت

نظرًا لأنه لا يمكنك تخزين سوى كمية محدودة من البيانات في ذاكرة التخزين المؤقت ، فستحتاج إلى تحديد استراتيجية تحديث ذاكرة التخزين المؤقت التي تعمل بشكل أفضل لحالة الاستخدام الخاصة بك.

وضع ذاكرة التخزين المؤقت جانبًا

Source: From cache to in-memory data grid

التطبيق مسؤول عن القراءة والكتابة من التخزين. ذاكرة التخزين المؤقت لا تتفاعل مع التخزين مباشرة. يقوم التطبيق بما يلي:

ابحث عن الإدخال في ذاكرة التخزين المؤقت ، مما أدى إلى فقدان ذاكرة التخزين المؤقت
تحميل دخول من قاعدة البيانات
إضافة إدخال إلى ذاكرة التخزين المؤقت
عودة الدخول

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

يتم استخدام [Memcached] (https://memcached.org/) بشكل عام بهذه الطريقة.

تتم القراءات اللاحقة للبيانات المضافة إلى ذاكرة التخزين المؤقت بسرعة. يشار إلى ذاكرة التخزين المؤقت الجانبية أيضًا باسم التحميل البطيء. يتم تخزين البيانات المطلوبة فقط مؤقتًا ، مما يؤدي إلى تجنب ملء ذاكرة التخزين المؤقت بالبيانات غير المطلوبة.

العيوب: cache-aside

ينتج عن كل خطأ في ذاكرة التخزين المؤقت ثلاث رحلات ، مما قد يتسبب في تأخير ملحوظ.
يمكن أن تصبح البيانات قديمة إذا تم تحديثها في قاعدة البيانات. يتم تخفيف هذه المشكلة عن طريق تعيين مدة البقاء (TTL) التي تفرض تحديثًا لإدخال ذاكرة التخزين المؤقت ، أو باستخدام الكتابة.
عندما تفشل عقدة ، يتم استبدالها بعقدة جديدة فارغة ، مما يؤدي إلى زيادة زمن الوصول.

الكتابة عبر

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)

الكتابة من خلال عملية إجمالية بطيئة بسبب عملية الكتابة ، لكن القراءات اللاحقة للبيانات المكتوبة للتو تكون سريعة. يتسامح المستخدمون بشكل عام مع وقت الاستجابة عند تحديث البيانات أكثر من قراءة البيانات. البيانات في ذاكرة التخزين المؤقت ليست قديمة.

العيوب: اكتب

عند إنشاء عقدة جديدة بسبب فشل أو تحجيم ، لن تقوم العقدة الجديدة بتخزين الإدخالات مؤقتًا حتى يتم تحديث الإدخال في قاعدة البيانات. يمكن أن يؤدي وضع ذاكرة التخزين المؤقت جنبًا إلى جنب مع الكتابة من خلال إلى التخفيف من هذه المشكلة.
قد لا تتم قراءة معظم البيانات المكتوبة مطلقًا ، ويمكن تصغيرها باستخدام TTL.

الكتابة الخلفية (إعادة الكتابة)

Source: Scalability, availability, stability, patterns

في الكتابة الخلفية ، يقوم التطبيق بما يلي:

إضافة / تحديث الإدخال في ذاكرة التخزين المؤقت
كتابة الإدخال بشكل غير متزامن إلى مخزن البيانات ، مما يؤدي إلى تحسين أداء الكتابة

العيوب: الكتابة الخلفية

قد يكون هناك فقدان للبيانات إذا تعطلت ذاكرة التخزين المؤقت قبل أن تصل محتوياتها إلى مخزن البيانات.
يعد تنفيذ الكتابة الخلفية أكثر تعقيدًا من تنفيذ التخزين المؤقت جانبًا أو الكتابة.

التحديث إلى الأمام

Source: From cache to in-memory data grid

يمكنك تكوين ذاكرة التخزين المؤقت لتحديث أي إدخال مخبأ تم الوصول إليه مؤخرًا تلقائيًا قبل انتهاء صلاحيته.

يمكن أن يؤدي التحديث المسبق إلى تقليل وقت الاستجابة مقابل القراءة الكاملة إذا كان بإمكان ذاكرة التخزين المؤقت التنبؤ بدقة بالعناصر التي من المحتمل أن تكون مطلوبة في المستقبل.

العيوب: التحديث إلى الأمام

عدم التنبؤ بدقة بالعناصر التي من المحتمل أن تكون مطلوبة في المستقبل يمكن أن يؤدي إلى انخفاض الأداء مقارنة بغير التحديث المسبق.

العيوب: ذاكرة التخزين المؤقت

تحتاج إلى الحفاظ على الاتساق بين ذاكرات التخزين المؤقت ومصدر الحقيقة مثل قاعدة البيانات من خلال إبطال ذاكرة التخزين المؤقت.
يعد إبطال ذاكرة التخزين المؤقت مشكلة صعبة ، وهناك تعقيد إضافي مرتبط بموعد تحديث ذاكرة التخزين المؤقت.
تحتاج إلى إجراء تغييرات على التطبيق مثل إضافة Redis أو memcached.

المصدر (المصادر) وقراءات أخرى

عدم التزامن

Source: Intro to architecting systems for scale

تساعد تدفقات العمل غير المتزامنة على تقليل أوقات الطلب للعمليات الباهظة التي كان من الممكن إجراؤها في نفس الوقت. يمكنهم أيضًا المساعدة من خلال القيام بعمل يستغرق وقتًا طويلاً مسبقًا ، مثل التجميع الدوري للبيانات.

قوائم انتظار الرسائل

تقوم قوائم انتظار الرسائل باستلام الرسائل والاحتفاظ بها وتسليمها. إذا كانت العملية بطيئة جدًا بحيث لا يمكن تنفيذها بشكل مضمّن ، فيمكنك استخدام قائمة انتظار الرسائل مع سير العمل التالي:

يقوم أحد التطبيقات بنشر وظيفة في قائمة الانتظار ، ثم يقوم بإعلام المستخدم بحالة الوظيفة
يلتقط عامل الوظيفة من قائمة الانتظار ، ويعالجها ، ثم يشير إلى اكتمال المهمة

لا يتم حظر المستخدم وتتم معالجة المهمة في الخلفية. خلال هذا الوقت ، قد يقوم العميل اختياريًا بكمية صغيرة من المعالجة لجعل الأمر يبدو وكأن المهمة قد اكتملت. على سبيل المثال ، في حالة نشر تغريدة ، يمكن نشر التغريدة على الفور على جدولك الزمني ، ولكن قد يستغرق الأمر بعض الوقت قبل أن يتم تسليم تغريدتك فعليًا إلى جميع متابعيك.

** Redis ** مفيد كوسيط رسائل بسيط ولكن يمكن فقد الرسائل.

** RabbitMQ ** شائعة ولكنها تتطلب منك التكيف مع بروتوكول "AMQP" وإدارة العقد الخاصة بك.

** Amazon SQS ** مستضاف ولكن يمكن أن يكون له وقت استجابة مرتفع ولديه إمكانية تسليم الرسائل مرتين.

قوائم انتظار المهام

تستقبل قوائم انتظار المهام المهام والبيانات المتعلقة بها ، وتقوم بتشغيلها ، ثم تسليم نتائجها. يمكنهم دعم الجدولة ويمكن استخدامها لتشغيل وظائف حسابية مكثفة في الخلفية.

** كرفس ** لديه دعم للجدولة ولديه دعم Python بشكل أساسي.

الضغط الخلفي

إذا بدأت قوائم الانتظار في النمو بشكل ملحوظ ، يمكن أن يصبح حجم قائمة الانتظار أكبر من الذاكرة ، مما يؤدي إلى فقد ذاكرة التخزين المؤقت وقراءة القرص وحتى أداء أبطأ. يمكن أن يساعد الضغط الخلفي في الحد من حجم قائمة الانتظار ، وبالتالي الحفاظ على معدل إنتاجية مرتفع واستجابة جيدة مرات للوظائف الموجودة بالفعل في قائمة الانتظار. بمجرد امتلاء قائمة الانتظار ، يحصل العملاء على خادم مشغول أو رمز حالة HTTP 503 للمحاولة مرة أخرى لاحقًا. يمكن للعملاء إعادة محاولة الطلب في وقت لاحق ، ربما باستخدام التراجع الأسي.

العيوب: عدم التزامن

قد تكون حالات الاستخدام مثل العمليات الحسابية غير المكلفة وسير العمل في الوقت الفعلي مناسبة بشكل أفضل للعمليات المتزامنة ، حيث يمكن أن يؤدي إدخال قوائم الانتظار إلى زيادة التأخير والتعقيد.

المصدر (المصادر) وقراءات أخرى

إنها لعبة أرقام
تطبيق الضغط الخلفي عند التحميل الزائد
قانون ليتل
[ما الفرق بين قائمة انتظار الرسائل وقائمة انتظار المهام?](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue -لماذا تتطلب قائمة انتظار مهمة وسيط رسالة مثل RabbitMQ-Redis-Celery-or-IronMQ-to-function)

تواصل

Source: OSI 7 layer model

بروتوكول نقل النص التشعبي (HTTP)

HTTP هي طريقة لتشفير ونقل البيانات بين العميل والخادم. إنه بروتوكول طلب / استجابة: يصدر العملاء طلبات ويصدر الخوادم استجابات بالمحتوى ذي الصلة ومعلومات حالة الإكمال حول الطلب. HTTP قائم بذاته ، مما يسمح للطلبات والاستجابات بالتدفق عبر العديد من أجهزة التوجيه والخوادم الوسيطة التي تقوم بموازنة التحميل والتخزين المؤقت والتشفير والضغط.

يتكون طلب HTTP الأساسي من فعل (طريقة) ومورد (نقطة نهاية). فيما يلي أفعال HTTP الشائعة:

Verb	Description	Idempotent*	Safe	Cacheable
GET	Reads a resource	Yes	Yes	Yes
POST	Creates a resource or trigger a process that handles data	No	No	Yes if response contains freshness info
PUT	Creates or replace a resource	Yes	No	No
PATCH	Partially updates a resource	No	No	Yes if response contains freshness info
DELETE	Deletes a resource	Yes	No	No

يمكن استدعاؤه عدة مرات دون نتائج مختلفة.

HTTP هو بروتوكول طبقة تطبيق يعتمد على بروتوكولات المستوى الأدنى مثل ** TCP ** و ** UDP **.

المصدر (المصادر) وقراءات أخرى: HTTP

بروتوكول التحكم في الإرسال (TCP)

Source: How to make a multiplayer game

TCP هو بروتوكول مهيأ للاتصال عبر شبكة IP. يتم إنشاء الاتصال وإنهائه باستخدام المصافحة. نضمن وصول جميع الحزم المرسلة إلى الوجهة بالترتيب الأصلي وبدون فساد من خلال:

أرقام التسلسل و حقول المجموع الاختباري لكل حزمة
Acknowledgement الحزم وإعادة الإرسال التلقائي

إذا لم يتلق المرسل استجابة صحيحة ، فسيعيد إرسال الحزم. إذا كانت هناك مهلات متعددة ، فسيتم قطع الاتصال. ينفذ TCP أيضًا التحكم في التدفق و التحكم في الازدحام. تتسبب هذه الضمانات في حدوث تأخيرات وتؤدي عمومًا إلى نقل أقل كفاءة من UDP.

لضمان إنتاجية عالية ، يمكن لخوادم الويب الاحتفاظ بعدد كبير من اتصالات TCP مفتوحة ، مما يؤدي إلى استخدام ذاكرة عالية. قد يكون وجود عدد كبير من الاتصالات المفتوحة بين سلاسل عمليات خادم الويب مكلفًا ، ولنقل ، خادم memcached. يمكن أن يساعد تجميع الاتصال بالإضافة إلى التبديل إلى UDP عند الاقتضاء.

يعد بروتوكول TCP مفيدًا للتطبيقات التي تتطلب موثوقية عالية ولكنها تستغرق وقتًا أقل أهمية. تتضمن بعض الأمثلة خوادم الويب ومعلومات قاعدة البيانات و SMTP و FTP و SSH.

استخدم TCP عبر UDP عندما:

أنت بحاجة إلى جميع البيانات لتصل سليمة
تريد إجراء أفضل تقدير تلقائيًا لاستخدام معدل نقل الشبكة

بروتوكول مخطط بيانات المستخدم (UDP)

Source: How to make a multiplayer game

UDP غير متصل. يتم ضمان مخططات البيانات (المشابهة للحزم) فقط على مستوى مخطط البيانات. قد تصل مخططات البيانات إلى وجهتها خارج الترتيب أو لا تصل على الإطلاق. لا يدعم UDP التحكم في الازدحام. بدون الضمانات التي يدعمها TCP ، يكون UDP أكثر كفاءة بشكل عام.

يمكن لـ UDP البث وإرسال مخططات البيانات إلى جميع الأجهزة الموجودة على الشبكة الفرعية. هذا مفيد مع DHCP لأن العميل لم يتلق عنوان IP بعد ، وبالتالي يمنع طريقة لبث TCP بدون عنوان IP.

يعد UDP أقل موثوقية ولكنه يعمل بشكل جيد في حالات الاستخدام في الوقت الفعلي مثل VoIP ودردشة الفيديو والبث المباشر والألعاب متعددة اللاعبين في الوقت الفعلي.

استخدم UDP عبر TCP عندما:

أنت بحاجة إلى أقل زمن انتقال
البيانات المتأخرة أسوأ من فقدان البيانات
تريد تنفيذ تصحيح الخطأ الخاص بك

المصدر (المصادر) وقراءات إضافية: TCP و UDP

استدعاء الإجراء البعيد (RPC)

Source: Crack the system design interview

في RPC ، يتسبب العميل في تنفيذ إجراء على مساحة عنوان مختلفة ، عادةً ما يكون خادمًا بعيدًا. يتم ترميز الإجراء كما لو كان استدعاء إجراء محلي ، مع استبعاد تفاصيل كيفية الاتصال بالخادم من برنامج العميل. عادةً ما تكون المكالمات عن بُعد أبطأ وأقل موثوقية من المكالمات المحلية ، لذا من المفيد التمييز بين مكالمات RPC والمكالمات المحلية. تتضمن أطر عمل RPC الشائعة Protobuf و Thrift و Avro.

RPC هو بروتوكول استجابة للطلب:

** برنامج العميل ** - استدعاء إجراء كعب العميل. يتم دفع المعلمات إلى المكدس مثل استدعاء إجراء محلي.
** إجراء كعب العميل ** - معرف إجراء المشير (الحزم) والوسيطات في رسالة طلب.
** وحدة اتصالات العميل ** - يرسل نظام التشغيل الرسالة من العميل إلى الخادم.
** وحدة اتصالات الخادم ** - يمرر نظام التشغيل الحزم الواردة إلى إجراء كعب الخادم.
** إجراء كعب الخادم ** - إلغاء تنظيم النتائج ، واستدعاء إجراء الخادم المطابق لمعرف الإجراء وتمرير الوسائط المحددة.
تكرر استجابة الخادم الخطوات المذكورة أعلاه بترتيب عكسي.

نماذج استدعاءات RPC:

GET /someoperation?data=anId

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

يركز RPC على فضح السلوكيات. غالبًا ما يتم استخدام RPCs لأسباب تتعلق بالأداء مع الاتصالات الداخلية ، حيث يمكنك إجراء مكالمات محلية يدويًا لتناسب حالات الاستخدام الخاصة بك بشكل أفضل.

اختر مكتبة أصلية (تُعرف أيضًا باسم SDK) عندما:

أنت تعرف النظام الأساسي الذي تستهدفه.
تريد التحكم في كيفية الوصول إلى "المنطق" الخاص بك.
تريد التحكم في كيفية حدوث التحكم في الأخطاء خارج مكتبتك.
يعد الأداء وتجربة المستخدم النهائي شاغلك الأساسي.

تميل واجهات برمجة تطبيقات HTTP التي تتبع ** REST ** إلى الاستخدام في كثير من الأحيان لواجهات برمجة التطبيقات العامة.

العيوب: RPC

يصبح عملاء RPC مرتبطين بإحكام بتنفيذ الخدمة.
يجب تحديد واجهة برمجة تطبيقات جديدة لكل عملية أو حالة استخدام جديدة.
قد يكون من الصعب تصحيح أخطاء RPC.
قد لا تتمكن من الاستفادة من التقنيات الحالية خارج الصندوق. على سبيل المثال ، قد يتطلب الأمر جهدًا إضافيًا للتأكد من أن مكالمات RPC مخبأة بشكل صحيح على خوادم التخزين المؤقت مثل Squid .

النقل التمثيلي للدولة (REST)

REST هو أسلوب معماري يفرض نموذج العميل / الخادم حيث يعمل العميل على مجموعة من الموارد التي يديرها الخادم. يوفر الخادم تمثيلاً للموارد والإجراءات التي يمكنها إما معالجة أو الحصول على تمثيل جديد للموارد. يجب أن تكون جميع الاتصالات عديمة الحالة وقابلة للتخزين المؤقت.

هناك أربع خصائص لواجهة RESTful:

** تحديد الموارد (URI في HTTP) ** - استخدم نفس URI بغض النظر عن أي عملية.
** التغيير مع التمثيلات (الأفعال في HTTP) ** - استخدم الأفعال والعناوين والجسم.
** رسالة خطأ وصفية ذاتية (استجابة الحالة في HTTP) ** - استخدم أكواد الحالة ، ولا تعيد اختراع العجلة.
** HATEOAS (واجهة HTML لـ HTTP) ** - يجب أن تكون خدمة الويب الخاصة بك قابلة للوصول بالكامل في المتصفح.

عينة مكالمات REST:

GET /someresources/anId

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

يركز REST على كشف البيانات. إنه يقلل من الاقتران بين العميل / الخادم وغالبًا ما يستخدم لواجهات برمجة تطبيقات HTTP العامة. يستخدم REST طريقة أكثر عمومية وموحدة لعرض الموارد من خلال URIs ، التمثيل من خلال الرؤوس ، و الإجراءات من خلال أفعال مثل GET و POST و PUT و DELETE و PATCH. كونه عديم الحالة ، فإن REST رائع للقياس والتقسيم الأفقي.

العيوب: REST

مع تركيز REST على كشف البيانات ، قد لا يكون مناسبًا إذا لم يتم تنظيم الموارد بشكل طبيعي أو الوصول إليها في تسلسل هرمي بسيط. على سبيل المثال ، لا يتم التعبير بسهولة عن إعادة جميع السجلات المحدثة من الساعة الماضية التي تتطابق مع مجموعة معينة من الأحداث كمسار. باستخدام REST ، من المحتمل أن يتم تنفيذه بمجموعة من مسار URI ومعلمات الاستعلام وربما نص الطلب.
يعتمد REST عادةً على بعض الأفعال (GET و POST و PUT و DELETE و PATCH) والتي لا تناسب أحيانًا حالة الاستخدام الخاصة بك. على سبيل المثال ، قد لا يتناسب نقل المستندات منتهية الصلاحية إلى مجلد الأرشيف تمامًا مع هذه الأفعال.
يتطلب جلب الموارد المعقدة ذات التسلسلات الهرمية المتداخلة رحلات ذهاب وإياب متعددة بين العميل والخادم لعرض طرق عرض فردية ، على سبيل المثال جلب محتوى إدخال مدونة والتعليقات على هذا الإدخال. بالنسبة لتطبيقات الهاتف المحمول التي تعمل في ظروف شبكة متغيرة ، فإن هذه الرحلات المتعددة ذهابًا وإيابًا غير مرغوب فيها إلى حد كبير.
بمرور الوقت ، قد تتم إضافة المزيد من الحقول إلى استجابة API وسيتلقى العملاء الأكبر سنًا جميع حقول البيانات الجديدة ، حتى تلك التي لا يحتاجونها ، ونتيجة لذلك ، يؤدي ذلك إلى تضخيم حجم الحمولة ويؤدي إلى زمن انتقال أكبر.

مقارنة مكالمات RPC و REST

Operation	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

المصدر (المصادر) وقراءات أخرى: REST و RPC

حماية

هذا القسم يمكن أن يستخدم بعض التحديثات. ضع في اعتبارك المساهمة!

الأمن موضوع واسع. ما لم تكن لديك خبرة كبيرة ، أو خلفية أمنية ، أو تتقدم لوظيفة تتطلب معرفة بالأمان ، فربما لن تحتاج إلى معرفة أكثر من الأساسيات:

تشفير أثناء النقل وأثناء الراحة.
قم بتعقيم جميع إدخالات المستخدم أو أي معلمات إدخال معروضة للمستخدم لمنع XSS و إدخال SQL.
استخدم الاستعلامات ذات المعلمات لمنع إدخال SQL.
استخدم مبدأ الامتياز الأقل.

المصدر (المصادر) وقراءات أخرى

زائدة

سيُطلب منك أحيانًا عمل تقديرات "ظهر الظرف". على سبيل المثال ، قد تحتاج إلى تحديد المدة التي سيستغرقها إنشاء 100 صورة مصغرة من القرص أو مقدار الذاكرة التي ستستغرقها بنية البيانات. تعد ** صلاحيات الجدولين ** و ** أرقام وقت الاستجابة التي يجب أن يعرفها كل مبرمج ** من المراجع المفيدة.

صلاحيات طاولتين

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

المصدر (المصادر) وقراءات أخرى

[صلاحيات اثنين] (https://en.wikipedia.org/wiki/Power_of_two)

أرقام التأخير التي يجب على كل مبرمج معرفتها

أرقام مقارنة زمن الوصول
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   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
HDD 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 HDD     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

ملاحظات
-----
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 HDD 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

عرض أرقام وقت الاستجابة

المصدر (المصادر) وقراءات أخرى

أسئلة مقابلة تصميم النظام الإضافية

أسئلة مقابلة تصميم النظام الشائعة ، مع روابط لمصادر حول كيفية حل كل منها.

Question	Reference(s)
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	figshare.com
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	cs.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/
Design a Stock Exchange (like NASDAQ or Binance)	Jane Street Golang Implementation Go Implemenation
Add a system design question	المساهمة

أبنية العالم الحقيقي

مقالات حول كيفية تصميم أنظمة العالم الحقيقي.

Source: Twitter timelines at scale

** لا تركز على التفاصيل الدقيقة للمقالات التالية ، بدلاً من ذلك: **

تحديد المبادئ المشتركة والتقنيات والأنماط المشتركة في هذه المقالات
ادرس المشكلات التي يتم حلها بواسطة كل مكون ، وأين يعمل ، وأين لا يعمل
مراجعة الدروس المستفادة

Type	System	Reference(s)
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
	Add an architecture	المساهمة

هندسة الشركة

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 How Facebook Live Streams To 800,000 Simultaneous Viewers
Flickr	Flickr architecture
Mailbox	From 0 to one million users in 6 weeks
Netflix	A 360 Degree View Of The Entire Netflix Stack Netflix: What Happens When You Press Play?
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 How Twitter Handles 3,000 Images Per Second
Uber	How Uber scales their real-time market platform Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories
WhatsApp	The WhatsApp architecture Facebook bought for $19 billion
YouTube	YouTube scalability YouTube architecture

مدونات هندسة الشركات

بنى للشركات التي تجري مقابلات معها.

الأسئلة التي تواجهها قد تكون من نفس المجال.

المصدر (المصادر) وقراءات أخرى

تبحث لإضافة مدونة? لتجنب تكرار العمل ، ضع في اعتبارك إضافة مدونة شركتك إلى الريبو التالي:

kilimchoi / engineering-blogs

تحت التطوير

هل أنت مهتم بإضافة قسم أو المساعدة في إكمال قسم قيد التنفيذ? [مجلّة] (#contributing)!

الحوسبة الموزعة باستخدام MapReduce
تجزئة متسقة
جمع مبعثر
مجلّة

الاعتمادات

يتم توفير الاعتمادات والمصادر في جميع أنحاء هذا المستودع.

شُكر خاص ل:

معلومات الاتصال

لا تتردد في الاتصال بي لمناقشة أي قضايا أو أسئلة أو تعليقات.

يمكن العثور على معلومات الاتصال الخاصة بي على صفحة GitHub.

رخصة

أقوم بتوفير التعليمات البرمجية والموارد في هذا المستودع لك بموجب ترخيص مفتوح المصدر. نظرًا لأن هذا هو مستودعي الشخصي ، فإن الترخيص الذي تتلقاه للرمز الخاص بي وموارده هو مني وليس من صاحب العمل (Facebook). *

Copyright 2017 Donne Martin

Creative Commons Attribution 4.0 International License (CC BY 4.0)

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

145 KiB Raw Blame History Unescape Escape

تمهيد لتصميم النظام

الدافع

التعرف على كيفية تصميم أنظمة واسعة النطاق

تعلم من مجتمع المصادر المفتوحة

التحضير لمقابلة تصميم النظام

بطاقات أنكي التعليمية

مصادر البرمجة : تحديات البرمجة التفاعلية

المساهمة

فهرس موضوعات تصميم النظام

دليل الدراسة

كيفية التعامل مع سؤال مقابلة تصميم النظام

الخطوة الأولى: حدد حالات الاستخدام والقيود والافتراضات

الخطوة الثانية: إنشاء تصميم عالي المستوى

الخطوة الثالثة: تصميم المكونات الأساسية

الخطوة 4: قياس التصميم

حسابات ظهر المغلف

المصدر (المصادر) وقراءات أخرى

أسئلة مقابلة تصميم النظام مع الحلول

تصميم Pastebin.com (أو Bit.ly)

تصميم الجدول الزمني على Twitter والبحث (أو موجز Facebook والبحث)

تصميم زاحف الويب

صمم Mint.com

تصميم هياكل البيانات لشبكة اجتماعية

تصميم مخزن مفتاح-قيمة لمحرك بحث

تصميم ترتيب مبيعات أمازون حسب ميزة الفئة

تصميم نظام يتسع لملايين المستخدمين على AWS

أسئلة مقابلة التصميم الموجه مع الحلول

مواضيع تصميم النظام: ابدأ من هنا

الخطوة الأولى: مراجعة محاضرة الفيديو حول قابلية التوسع

الخطوة الثانية: مراجعة مقالة قابلية التوسع

الخطوات التالية

الأداء مقابل قابلية التوسع

المصدر (المصادر) وقراءات أخرى

الكمون مقابل معالجة النظام للمعلومات

المصدر (المصادر) وقراءات أخرى

التوافر مقابل الاتساق

نظرية CAP

CP - الاتساق والتسامح في التقسيم

AP - التوافر والتسامح في القسم

المصدر (المصادر) وقراءات أخرى

أنماط الاتساق

تناسق ضعيف

الاتساق في نهاية المطاف

الاتساق القوي

المصدر (المصادر) وقراءات أخرى

أنماط التوفر

الفشل

المبني للمجهول

النشط النشط

العيوب: تجاوز الفشل

تكرار

السيد والخادم والسيد السيد

التوافرية بالأعداد

توفر بنسبة 99.9٪ - ثلاث 9 ثوانٍ

التوفر بنسبة 99.99٪ - أربع 9 ثوانٍ

التوفر بالتوازي مقابل التسلسل

في تسلسل

بالتوازي

نظام اسم المجال

العيوب: DNS

المصدر (المصادر) وقراءات أخرى

شبكة توصيل المحتوى

دفع CDNs

سحب CDNs

العيوب: CDN

المصدر (المصادر) وقراءات أخرى

موازن التحميل

موازنة الحمل بالطبقة الرابعة

موازنة أحمال الطبقة السابعة

القياس الأفقي

العيوب: القياس الأفقي

العيوب: موازن التحميل

المصدر (المصادر) وقراءات أخرى

وكيل عكسي (خادم الشبكة)

تحميل الموازن مقابل الوكيل العكسي

العيوب: عكس الوكيل

المصدر (المصادر) وقراءات أخرى

طبقة التطبيقات

الخدمات المصغرة

145 KiB

Raw Blame History