system design primer
1.0.0
الإنجليزية ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة ∙ বংল ∙ Português do Brasil ∙ Deutsch ∙ ενικηνικά ∙ AFVERYIT ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ Русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | أضف الترجمة
ساعد في ترجمة هذا الدليل!
تعلم كيفية تصميم الأنظمة واسعة النطاق.
الإعداد لمقابلة تصميم النظام.
إن تعلم كيفية تصميم أنظمة قابلة للتطوير سيساعدك على أن تصبح مهندسًا أفضل.
تصميم النظام هو موضوع واسع. هناك قدر هائل من الموارد المنتشرة عبر الويب حول مبادئ تصميم النظام.
هذا الريبو عبارة عن مجموعة منظمة من الموارد لمساعدتك على تعلم كيفية بناء الأنظمة على نطاق واسع.
هذا مشروع مفتوح المصدر يتم تحديثه باستمرار.
المساهمات هي موضع ترحيب!
بالإضافة إلى تشفير المقابلات، يعد تصميم النظام عنصرًا مطلوبًا في عملية المقابلة الفنية في العديد من شركات التكنولوجيا.
تدرب على أسئلة المقابلة الخاصة بتصميم النظام المشترك وقارن نتائجك مع نماذج الحلول : المناقشات، والتعليمات البرمجية، والرسوم البيانية.
مواضيع إضافية للتحضير للمقابلة:
تستخدم مجموعات بطاقات Anki التعليمية المتوفرة التكرار المتباعد لمساعدتك في الاحتفاظ بمفاهيم تصميم النظام الأساسية.
رائعة للاستخدام أثناء التنقل.
هل تبحث عن موارد لمساعدتك في الاستعداد لمقابلة البرمجة ؟
تحقق من تحديات البرمجة التفاعلية في الريبو الشقيقة، والتي تحتوي على مجموعة Anki الإضافية:
تعلم من المجتمع.
لا تتردد في تقديم طلبات السحب للمساعدة:
يتم وضع المحتوى الذي يحتاج إلى بعض الصقل قيد التطوير.
قم بمراجعة إرشادات المساهمة.
ملخصات لمختلف موضوعات تصميم النظام، بما في ذلك الإيجابيات والسلبيات. كل شيء هو مقايضة .
يحتوي كل قسم على روابط لمزيد من الموارد المتعمقة.
المواضيع المقترحة للمراجعة بناءً على الجدول الزمني للمقابلة (قصير، متوسط، طويل).
س: بالنسبة للمقابلات، هل أحتاج إلى معرفة كل شيء هنا؟
ج: لا، ليس من الضروري أن تعرف كل شيء هنا للتحضير للمقابلة .
ما يطلب منك في المقابلة يعتمد على متغيرات مثل:
من المتوقع عمومًا أن يعرف المرشحون الأكثر خبرة المزيد عن تصميم النظام. من المتوقع أن يعرف المهندسون المعماريون أو قادة الفرق أكثر من المساهمين الأفراد. من المرجح أن تجري شركات التكنولوجيا الكبرى جولة واحدة أو أكثر من مقابلات التصميم.
ابدأ على نطاق واسع وتعمق في بعض المجالات. من المفيد معرفة القليل عن موضوعات تصميم النظام الرئيسية المختلفة. اضبط الدليل التالي بناءً على جدولك الزمني وخبرتك والمناصب التي تجري المقابلة معها والشركات التي تجري المقابلة معها.
| قصير | واسطة | طويل | |
|---|---|---|---|
| اقرأ موضوعات تصميم النظام للحصول على فهم واسع لكيفية عمل الأنظمة | ؟ | ؟ | ؟ |
| اقرأ بعض المقالات في مدونات الشركة الهندسية الخاصة بالشركات التي تجري مقابلات معها | ؟ | ؟ | ؟ |
| اقرأ من خلال بعض بنيات العالم الحقيقي | ؟ | ؟ | ؟ |
| قم بمراجعة كيفية التعامل مع سؤال مقابلة تصميم النظام | ؟ | ؟ | ؟ |
| العمل من خلال أسئلة مقابلة تصميم النظام مع الحلول | بعض | كثير | معظم |
| العمل من خلال أسئلة مقابلة التصميم الموجهة للكائنات مع الحلول | بعض | كثير | معظم |
| قم بمراجعة أسئلة المقابلة الإضافية لتصميم النظام | بعض | كثير | معظم |
كيفية التعامل مع سؤال مقابلة تصميم النظام.
مقابلة تصميم النظام هي محادثة مفتوحة . من المتوقع أن تقودها.
يمكنك استخدام الخطوات التالية لتوجيه المناقشة. للمساعدة في ترسيخ هذه العملية، قم بالعمل من خلال قسم أسئلة مقابلة تصميم النظام مع الحلول باستخدام الخطوات التالية.
جمع المتطلبات ونطاق المشكلة. اطرح أسئلة لتوضيح حالات الاستخدام والقيود. ناقش الافتراضات.
الخطوط العريضة لتصميم رفيع المستوى مع جميع المكونات الهامة.
تعمق في التفاصيل لكل مكون أساسي. على سبيل المثال، إذا طُلب منك تصميم خدمة تقصير عناوين URL، فناقش:
تحديد ومعالجة الاختناقات، في ضوء القيود. على سبيل المثال، هل تحتاج إلى ما يلي لمعالجة مشكلات قابلية التوسع؟
ناقش الحلول والمقايضات المحتملة. كل شيء هو مقايضة. معالجة الاختناقات باستخدام مبادئ تصميم النظام القابل للتطوير.
قد يُطلب منك إجراء بعض التقديرات يدويًا. راجع الملحق للاطلاع على الموارد التالية:
تحقق من الروابط التالية للحصول على فكرة أفضل عما يمكن توقعه:
أسئلة المقابلة الخاصة بتصميم النظام المشترك مع نماذج المناقشات والتعليمات البرمجية والرسوم البيانية.
الحلول المرتبطة بالمحتوى الموجود في مجلد
solutions/.
| سؤال | |
|---|---|
| تصميم Pastebin.com (أو Bit.ly) | حل |
| تصميم الجدول الزمني لتويتر والبحث (أو موجز الفيسبوك والبحث) | حل |
| تصميم زاحف الويب | حل |
| تصميم Mint.com | حل |
| تصميم هياكل البيانات لشبكة اجتماعية | حل |
| تصميم مخزن ذو قيمة أساسية لمحرك البحث | حل |
| تصميم تصنيف مبيعات أمازون حسب فئة الميزة | حل |
| صمم نظامًا يتسع لملايين المستخدمين على AWS | حل |
| أضف سؤال تصميم النظام | يساهم |
شاهد التمرين والحل
شاهد التمرين والحل
شاهد التمرين والحل
شاهد التمرين والحل
شاهد التمرين والحل
شاهد التمرين والحل
شاهد التمرين والحل
شاهد التمرين والحل
أسئلة شائعة في مقابلات التصميم الموجهة للكائنات مع نماذج من المناقشات والتعليمات البرمجية والرسوم البيانية.
الحلول المرتبطة بالمحتوى الموجود في مجلد
solutions/.
ملحوظة: هذا القسم قيد التطوير
| سؤال | |
|---|---|
| تصميم خريطة التجزئة | حل |
| تصميم ذاكرة التخزين المؤقت الأقل استخدامًا مؤخرًا | حل |
| تصميم مركز اتصال | حل |
| تصميم مجموعة من البطاقات | حل |
| تصميم موقف للسيارات | حل |
| تصميم خادم الدردشة | حل |
| تصميم مصفوفة دائرية | يساهم |
| أضف سؤال تصميم موجه للكائنات | يساهم |
هل أنت جديد في تصميم النظام؟
أولاً، ستحتاج إلى فهم أساسي للمبادئ المشتركة، والتعرف على ماهيتها، وكيفية استخدامها، وإيجابياتها وسلبياتها.
محاضرة قابلية التوسع في جامعة هارفارد
قابلية التوسع
بعد ذلك، سنلقي نظرة على المقايضات رفيعة المستوى:
ضع في اعتبارك أن كل شيء هو مقايضة .
ثم سنتعمق في موضوعات أكثر تحديدًا مثل DNS وشبكات CDN وموازنات التحميل.
تكون الخدمة قابلة للتطوير إذا أدت إلى زيادة الأداء بطريقة تتناسب مع الموارد المضافة. وبشكل عام، تعني زيادة الأداء تقديم المزيد من وحدات العمل، ولكنها قد تعني أيضًا التعامل مع وحدات عمل أكبر، كما هو الحال عندما تنمو مجموعات البيانات. 1
طريقة أخرى للنظر إلى الأداء مقابل قابلية التوسع:
الكمون هو الوقت المناسب لتنفيذ بعض الإجراءات أو تحقيق بعض النتائج.
الإنتاجية هي عدد هذه الإجراءات أو النتائج لكل وحدة زمنية.
بشكل عام، يجب أن تهدف إلى تحقيق أقصى قدر من الإنتاجية مع زمن وصول مقبول .
المصدر: إعادة النظر في نظرية CAP
في نظام الكمبيوتر الموزع، يمكنك فقط دعم اثنين من الضمانات التالية:
الشبكات ليست موثوقة، لذا ستحتاج إلى دعم تحمل القسم. ستحتاج إلى إجراء مقايضة برمجية بين الاتساق والتوافر.
قد يؤدي انتظار الاستجابة من العقدة المقسمة إلى حدوث خطأ في المهلة. يعد CP خيارًا جيدًا إذا كانت احتياجات عملك تتطلب عمليات قراءة وكتابة ذرية.
تقوم الاستجابات بإرجاع الإصدار الأكثر سهولة من البيانات المتوفرة على أي عقدة، والتي قد لا تكون الأحدث. قد تستغرق عمليات الكتابة بعض الوقت للنشر عند حل القسم.
يعد AP خيارًا جيدًا إذا كانت الشركة بحاجة إلى السماح بالاتساق النهائي أو عندما يحتاج النظام إلى مواصلة العمل على الرغم من الأخطاء الخارجية.
مع نسخ متعددة من نفس البيانات، نواجه خيارات حول كيفية مزامنتها بحيث يكون لدى العملاء رؤية متسقة للبيانات. تذكر تعريف الاتساق من نظرية CAP - كل قراءة تتلقى أحدث كتابة أو خطأ.
بعد الكتابة، قد يقرأها أو لا يراها. يتم اتباع أفضل نهج للجهد.
يظهر هذا النهج في أنظمة مثل memcached. يعمل الاتساق الضعيف بشكل جيد في حالات الاستخدام في الوقت الفعلي مثل VoIP، والدردشة المرئية، والألعاب متعددة اللاعبين في الوقت الفعلي. على سبيل المثال، إذا كنت تجري مكالمة هاتفية وفقدت الاستقبال لبضع ثوان، فعندما تستعيد الاتصال، لن تسمع ما تم التحدث به أثناء فقدان الاتصال.
بعد الكتابة، ستشاهدها القراءات في النهاية (عادةً خلال أجزاء من الثانية). يتم نسخ البيانات بشكل غير متزامن.
يظهر هذا النهج في أنظمة مثل DNS والبريد الإلكتروني. يعمل الاتساق النهائي بشكل جيد في الأنظمة المتوفرة للغاية.
بعد الكتابة، سوف يرى القراء ذلك. يتم نسخ البيانات بشكل متزامن.
يظهر هذا النهج في أنظمة الملفات و RDBMSes. يعمل الاتساق القوي بشكل جيد في الأنظمة التي تحتاج إلى معاملات.
هناك نمطان متكاملان لدعم الإتاحة العالية: تجاوز الفشل والنسخ المتماثل .
مع تجاوز الفشل النشط والسلبي، يتم إرسال نبضات القلب بين الخادم النشط والخادم السلبي في وضع الاستعداد. إذا تمت مقاطعة نبضات القلب، فسيتولى الخادم السلبي عنوان IP الخاص بالنشط ويستأنف الخدمة.
يتم تحديد طول فترة التوقف عن العمل من خلال ما إذا كان الخادم الخامل يعمل بالفعل في وضع الاستعداد "الساخن" أو ما إذا كان يحتاج إلى بدء التشغيل من وضع الاستعداد "البارد". الخادم النشط فقط هو الذي يتعامل مع حركة المرور.
يمكن أيضًا الإشارة إلى تجاوز الفشل النشط السلبي على أنه تجاوز الفشل الرئيسي والتابع.
في الوضع النشط - النشط، يقوم كلا الخادمين بإدارة حركة المرور، وتوزيع الحمل بينهما.
إذا كانت الخوادم عامة، فسيحتاج DNS إلى معرفة عناوين IP العامة لكلا الخادمين. إذا كانت الخوادم مواجهة للداخل، فسيحتاج منطق التطبيق إلى معرفة كلا الخادمين.
يمكن أيضًا الإشارة إلى تجاوز الفشل النشط النشط على أنه تجاوز الفشل الرئيسي.
تمت مناقشة هذا الموضوع بمزيد من التفصيل في قسم قاعدة البيانات:
غالبًا ما يتم تحديد مدى التوفر من خلال وقت التشغيل (أو وقت التوقف عن العمل) كنسبة مئوية من وقت توفر الخدمة. يتم قياس التوفر بشكل عام بعدد 9s - يتم وصف الخدمة التي تبلغ نسبة توفرها 99.99٪ بأنها تحتوي على أربع 9s.
| مدة | توقف مقبول |
|---|---|
| التوقف في السنة | 8 ساعات و 45 دقيقة و 57 ثانية |
| فترة التوقف شهريا | 43 م 49.7 ث |
| التوقف في الأسبوع | 10 م 4.8 ثانية |
| التوقف في اليوم الواحد | 1 م و 26.4 ثانية |
| مدة | توقف مقبول |
|---|---|
| التوقف في السنة | 52 دقيقة و 35.7 ثانية |
| فترة التوقف شهريا | 4 م 23 ث |
| التوقف في الأسبوع | 1 م 5 ث |
| التوقف في اليوم الواحد | 8.6 ثانية |
إذا كانت الخدمة تتكون من مكونات متعددة عرضة للفشل، فإن التوفر الإجمالي للخدمة يعتمد على ما إذا كانت المكونات متسلسلة أم متوازية.
ينخفض التوفر الإجمالي عندما يكون مكونان بتوفر أقل من 100% بالتسلسل:
Availability (Total) = Availability (Foo) * Availability (Bar)
إذا كان لكل من Foo و Bar نسبة توفر تبلغ 99.9%، فإن إجمالي توفرهما بالتسلسل سيكون 99.8%.
يزداد التوفر الإجمالي عندما يكون مكونان بتوفر أقل من 100% متوازيين:
Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
إذا كان لكل من Foo و Bar توفر بنسبة 99.9%، فإن إجمالي توفرهما بالتوازي سيكون 99.9999%.
المصدر: عرض أمان DNS
يقوم نظام اسم المجال (DNS) بترجمة اسم المجال مثل www.example.com إلى عنوان IP.
DNS هو نظام هرمي، مع عدد قليل من الخوادم الموثوقة في المستوى الأعلى. يوفر جهاز التوجيه أو مزود خدمة الإنترنت الخاص بك معلومات حول خادم (خوادم) DNS الذي يجب الاتصال به عند إجراء بحث. تعيينات ذاكرة التخزين المؤقت لخوادم DNS ذات المستوى الأدنى، والتي قد تصبح قديمة بسبب تأخيرات نشر DNS. يمكن أيضًا تخزين نتائج DNS مؤقتًا بواسطة المتصفح أو نظام التشغيل الخاص بك لفترة زمنية معينة، يتم تحديدها حسب مدة البقاء (TTL).
CNAME (example.com إلى www.example.com) أو إلى سجل Aتوفر خدمات مثل CloudFlare وRoute 53 خدمات DNS المُدارة. يمكن لبعض خدمات DNS توجيه حركة المرور عبر طرق مختلفة:
المصدر: لماذا نستخدم CDN
شبكة توصيل المحتوى (CDN) هي شبكة موزعة عالميًا من الخوادم الوكيلة، والتي تخدم المحتوى من مواقع أقرب إلى المستخدم. بشكل عام، يتم تقديم الملفات الثابتة مثل HTML/CSS/JS والصور ومقاطع الفيديو من CDN، على الرغم من أن بعض شبكات CDN مثل CloudFront من Amazon تدعم المحتوى الديناميكي. سيخبر دقة DNS الخاصة بالموقع العملاء بالخادم الذي يجب الاتصال به.
يمكن أن يؤدي عرض المحتوى من شبكات CDN إلى تحسين الأداء بشكل كبير بطريقتين:
تتلقى شبكات CDN المدفوعة محتوى جديدًا عند حدوث تغييرات على الخادم الخاص بك. أنت تتحمل المسؤولية الكاملة عن توفير المحتوى وتحميله مباشرةً إلى شبكة CDN وإعادة كتابة عناوين URL للإشارة إلى شبكة CDN. يمكنك التهيئة عند انتهاء صلاحية المحتوى ومتى يتم تحديثه. يتم تحميل المحتوى فقط عندما يكون جديدًا أو متغيرًا، مما يقلل من حركة المرور ويزيد من مساحة التخزين.
تعمل المواقع التي تحتوي على عدد قليل من الزيارات أو المواقع التي تحتوي على محتوى لا يتم تحديثه غالبًا بشكل جيد مع شبكات CDN المدفوعة. يتم وضع المحتوى على شبكات CDN مرة واحدة، بدلاً من إعادة سحبه على فترات منتظمة.
تسحب شبكات CDN المحتوى الجديد من الخادم الخاص بك عندما يطلب المستخدم الأول المحتوى. تترك المحتوى على الخادم الخاص بك وتعيد كتابة عناوين URL للإشارة إلى شبكة CDN. يؤدي هذا إلى طلب أبطأ حتى يتم تخزين المحتوى مؤقتًا على شبكة CDN.
تحدد مدة البقاء (TTL) مدة تخزين المحتوى مؤقتًا. تعمل شبكات CDN القابلة للسحب على تقليل مساحة التخزين على CDN، ولكن يمكنها إنشاء حركة مرور متكررة إذا انتهت صلاحية الملفات وتم سحبها قبل أن تتغير فعليًا.
تعمل المواقع ذات حركة المرور الكثيفة بشكل جيد مع شبكات CDN للسحب، حيث يتم توزيع حركة المرور بشكل أكثر توازناً مع بقاء المحتوى المطلوب مؤخرًا فقط على CDN.
المصدر: أنماط تصميم النظام القابلة للتطوير
تقوم موازنات التحميل بتوزيع طلبات العميل الواردة على موارد الحوسبة مثل خوادم التطبيقات وقواعد البيانات. في كل حالة، يقوم موازن التحميل بإرجاع الاستجابة من مورد الحوسبة إلى العميل المناسب. تكون موازنات التحميل فعالة في:
يمكن تنفيذ موازنات التحميل باستخدام أجهزة (باهظة الثمن) أو باستخدام برامج مثل HAProxy.
تشمل المزايا الإضافية ما يلي:
للحماية من حالات الفشل، من الشائع إعداد موازنات تحميل متعددة، إما في الوضع النشط السلبي أو الوضع النشط النشط.
يمكن لموازنات التحميل توجيه حركة المرور استنادًا إلى مقاييس مختلفة، بما في ذلك:
تنظر موازنات التحميل من الطبقة الرابعة إلى المعلومات الموجودة في طبقة النقل لتحديد كيفية توزيع الطلبات. بشكل عام، يتضمن هذا المصدر وعناوين IP الوجهة والمنافذ الموجودة في الرأس، ولكن ليس محتويات الحزمة. تعمل موازنات التحميل من الطبقة الرابعة على توجيه حزم الشبكة من وإلى الخادم الرئيسي، وإجراء ترجمة عنوان الشبكة (NAT).
تنظر موازنات التحميل من الطبقة السابعة إلى طبقة التطبيق لتحديد كيفية توزيع الطلبات. يمكن أن يشمل ذلك محتويات الرأس والرسالة وملفات تعريف الارتباط. تعمل موازنات التحميل من الطبقة السابعة على إنهاء حركة مرور الشبكة، وقراءة الرسالة، واتخاذ قرار موازنة التحميل، ثم فتح اتصال بالخادم المحدد. على سبيل المثال، يمكن لموازن التحميل من الطبقة 7 توجيه حركة مرور الفيديو إلى الخوادم التي تستضيف مقاطع الفيديو مع توجيه حركة مرور فواتير المستخدم الأكثر حساسية إلى الخوادم ذات الأمان المشدد.
على حساب المرونة، تتطلب موازنة تحميل الطبقة الرابعة وقتًا وموارد حوسبة أقل من الطبقة السابعة، على الرغم من أن تأثير الأداء يمكن أن يكون ضئيلًا على الأجهزة السلعية الحديثة.
يمكن أن تساعد موازنات التحميل أيضًا في القياس الأفقي وتحسين الأداء والتوفر. يعد التوسع باستخدام الأجهزة السلعية أكثر فعالية من حيث التكلفة ويؤدي إلى توفر أعلى من توسيع نطاق خادم واحد على أجهزة أكثر تكلفة، وهو ما يسمى التوسع الرأسي . كما أنه من الأسهل توظيف المواهب التي تعمل على الأجهزة السلعية مقارنة بأنظمة المؤسسات المتخصصة.
المصدر: ويكيبيديا
الوكيل العكسي هو خادم ويب يقوم بمركزية الخدمات الداخلية ويوفر واجهات موحدة للجمهور. تتم إعادة توجيه الطلبات المقدمة من العملاء إلى خادم يمكنه تلبيتها قبل أن يقوم الوكيل العكسي بإرجاع استجابة الخادم إلى العميل.
تشمل المزايا الإضافية ما يلي:
المصدر: مقدمة إلى أنظمة الهندسة المعمارية للقياس
يتيح لك فصل طبقة الويب عن طبقة التطبيق (المعروفة أيضًا بطبقة النظام الأساسي) توسيع نطاق كلتا الطبقتين وتكوينهما بشكل مستقل. تؤدي إضافة واجهة برمجة تطبيقات جديدة إلى إضافة خوادم التطبيقات دون الحاجة إلى إضافة خوادم ويب إضافية بالضرورة. يدعو مبدأ المسؤولية الفردية إلى الخدمات الصغيرة والمستقلة التي تعمل معًا. يمكن للفرق الصغيرة ذات الخدمات الصغيرة التخطيط بقوة أكبر لتحقيق النمو السريع.
يساعد العاملون في طبقة التطبيق أيضًا على تمكين عدم التزامن.
ترتبط هذه المناقشة بالخدمات الصغيرة، والتي يمكن وصفها بأنها مجموعة من الخدمات المعيارية الصغيرة القابلة للنشر بشكل مستقل. تدير كل خدمة عملية فريدة وتتواصل من خلال آلية محددة جيدًا وخفيفة الوزن لخدمة هدف العمل. 1
يمكن أن يحتوي موقع Pinterest، على سبيل المثال، على الخدمات الصغيرة التالية: ملف تعريف المستخدم، والمتابعين، والموجز، والبحث، وتحميل الصور، وما إلى ذلك.
يمكن لأنظمة مثل Consul وEtcd وZookeeper مساعدة الخدمات في العثور على بعضها البعض من خلال تتبع الأسماء والعناوين والمنافذ المسجلة. تساعد عمليات التحقق من السلامة في التحقق من تكامل الخدمة ويتم إجراؤها غالبًا باستخدام نقطة نهاية HTTP. يحتوي كل من Consul وEtcd على مخزن قيمة مفتاح مدمج يمكن أن يكون مفيدًا لتخزين قيم التكوين والبيانات المشتركة الأخرى.
المصدر: توسيع النطاق إلى أول 10 ملايين مستخدم
قاعدة البيانات العلائقية مثل SQL هي عبارة عن مجموعة من عناصر البيانات المنظمة في الجداول.
ACID عبارة عن مجموعة من خصائص معاملات قاعدة البيانات العلائقية.
هناك العديد من التقنيات لقياس قاعدة البيانات العلائقية: النسخ المتماثل الرئيسي والتابع ، والنسخ المتماثل الرئيسي والماجستير ، والاتحاد ، والتجزئة ، وإلغاء التسوية ، وضبط SQL .
يخدم السيد القراءة والكتابة، ويكرر الكتابة إلى واحد أو أكثر من العبيد، الذين يخدمون القراءة فقط. يمكن للعبيد أيضًا أن يتكاثروا مع عبيد إضافيين بطريقة تشبه الشجرة. إذا أصبح السيد غير متصل بالإنترنت، فيمكن للنظام الاستمرار في العمل في وضع القراءة فقط حتى تتم ترقية العبد إلى سيد أو توفير سيد جديد.
المصدر: قابلية التوسع والتوافر والاستقرار والأنماط
يخدم كلا الماجستير عمليات القراءة والكتابة وينسقان مع بعضهما البعض في عمليات الكتابة. إذا تعطل أي منهما، يمكن للنظام الاستمرار في العمل مع كل من القراءة والكتابة.
المصدر: قابلية التوسع والتوافر والاستقرار والأنماط
المصدر: توسيع النطاق إلى أول 10 ملايين مستخدم
يقوم الاتحاد (أو التقسيم الوظيفي) بتقسيم قواعد البيانات حسب الوظيفة. على سبيل المثال، بدلاً من قاعدة بيانات واحدة متجانسة، يمكن أن يكون لديك ثلاث قواعد بيانات: المنتديات والمستخدمين والمنتجات ، مما يؤدي إلى تقليل حركة القراءة والكتابة إلى كل قاعدة بيانات وبالتالي تقليل تأخر النسخ المتماثل. تؤدي قواعد البيانات الأصغر حجمًا إلى المزيد من البيانات التي يمكن احتواؤها في الذاكرة، مما يؤدي بدوره إلى المزيد من نتائج ذاكرة التخزين المؤقت بسبب تحسين منطقة ذاكرة التخزين المؤقت. مع عدم وجود عمليات كتابة تسلسلية رئيسية مركزية واحدة، يمكنك الكتابة بالتوازي، مما يزيد من الإنتاجية.
المصدر: قابلية التوسع والتوافر والاستقرار والأنماط
تقوم المشاركة بتوزيع البيانات عبر قواعد بيانات مختلفة بحيث يمكن لكل قاعدة بيانات إدارة مجموعة فرعية فقط من البيانات. بأخذ قاعدة بيانات المستخدمين كمثال، مع زيادة عدد المستخدمين، تتم إضافة المزيد من الأجزاء إلى المجموعة.
على غرار مزايا الاتحاد، يؤدي التقسيم إلى تقليل حركة مرور القراءة والكتابة، وتقليل النسخ المتماثل، وزيادة عدد مرات الوصول إلى ذاكرة التخزين المؤقت. يتم أيضًا تقليل حجم الفهرس، مما يؤدي بشكل عام إلى تحسين الأداء من خلال الاستعلامات الأسرع. إذا تعطلت إحدى الأجزاء، فستظل الأجزاء الأخرى قيد التشغيل، على الرغم من أنك ستحتاج إلى إضافة شكل من أشكال النسخ المتماثل لتجنب فقدان البيانات. مثل الاتحاد ، لا يوجد تكتب مركزية مركزية واحدة ، مما يسمح لك بالكتابة بالتوازي مع زيادة الإنتاجية.
الطرق الشائعة لشراء جدول المستخدمين إما من خلال الاسم الأخير للمستخدم الأولي أو الموقع الجغرافي للمستخدم.
يحاول إزالة العمودية تحسين أداء القراءة على حساب بعض الأداء في الكتابة. تتم كتابة نسخ زائدة من البيانات في جداول متعددة لتجنب الوصلات باهظة الثمن. قامت بعض RDBMS مثل PostgreSQL و Oracle بدعم وجهات النظر التي تتعامل مع عمل تخزين المعلومات الزائدة والحفاظ على نسخ زائدة عن الحاجة متسقة.
بمجرد توزيع البيانات بتقنيات مثل الاتحاد والارتفاع ، تزيد الإدارة عبر مراكز البيانات من التعقيد. قد تتحايل إزالة العمودية على الحاجة إلى مثل هذا التعقيد.
في معظم الأنظمة ، يمكن أن يتفوق عدد القراءات بشكل كبير على 100: 1 أو حتى 1000: 1. يمكن أن تكون القراءة التي تؤدي إلى انضمام قاعدة بيانات معقدة باهظة الثمن ، حيث تنفق وقتًا كبيرًا في عمليات القرص.
SQL Tuning هو موضوع واسع وتم كتابة العديد من الكتب كمرجع.
من المهم أن يتم القياس والملف الشخصي لمحاكاة الاختناقات والكشف عنها.
قد يوجهك القياس والتوصيف إلى التحسينات التالية.
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 ) بشكل أسرع مع المؤشرات.NOSQL عبارة عن مجموعة من عناصر البيانات الممثلة في متجر قيمة مفاتيح ، أو متجر مستندات ، أو مخزن الأعمدة الواسعة ، أو قاعدة بيانات الرسم البياني . البيانات غير طبيعية ، ويتم تنفيذ الصلات عمومًا في رمز التطبيق. تفتقر معظم متاجر NOSQL إلى معاملات الحمض الحقيقية وتفضل الاتساق في نهاية المطاف.
غالبًا ما تستخدم القاعدة لوصف خصائص قواعد بيانات NOSQL. بالمقارنة مع نظرية CAP ، تختار Base التوفر على الاتساق.
بالإضافة إلى الاختيار بين SQL أو NOSQL ، من المفيد فهم نوع قاعدة بيانات NoSQL التي تناسب حالتك (حالات) الاستخدام. سنقوم بمراجعة متاجر القيمة الرئيسية ، ومتاجر المستندات ، ومخازن الأعمدة الواسعة ، وقواعد بيانات الرسم البياني في القسم التالي.
التجريد: جدول التجزئة
يسمح متجر القيمة الرئيسية عمومًا بقراءات O (1) ويكتب وغالبًا ما يتم دعمها بالذاكرة أو SSD. يمكن لمخازن البيانات الحفاظ على مفاتيح في ترتيب معجمي ، مما يتيح استرجاعًا فعالًا للنطاقات الرئيسية. يمكن أن تسمح متاجر القيمة الرئيسية بتخزين البيانات الوصفية ذات القيمة.
توفر متاجر القيمة الرئيسية أداءً عاليًا وغالبًا ما يتم استخدامها في نماذج البيانات البسيطة أو للبيانات المتغيرة بسرعة ، مثل طبقة ذاكرة التخزين المؤقت في الذاكرة. نظرًا لأنها توفر فقط مجموعة محدودة من العمليات ، يتم تحويل التعقيد إلى طبقة التطبيق إذا كانت هناك حاجة إلى عمليات إضافية.
يعد متجر القيمة الرئيسية هو أساس أنظمة أكثر تعقيدًا مثل متجر المستندات ، وفي بعض الحالات قاعدة بيانات الرسم البياني.
التجريد: متجر قيمة المفاتيح مع مستندات مخزنة كقيم
يتركز متجر المستندات حول المستندات (XML ، JSON ، ثنائي ، إلخ) ، حيث يقوم مستند بتخزين جميع المعلومات لكائن معين. توفر متاجر المستندات واجهات برمجة التطبيقات أو لغة الاستعلام للاستعلام بناءً على الهيكل الداخلي للوثيقة نفسها. ملاحظة ، تتضمن العديد من متاجر القيمة الرئيسية ميزات للعمل مع بيانات تعريف القيمة ، مما يؤدي إلى وضوح الخطوط بين هذين النوعين للتخزين.
بناءً على التنفيذ الأساسي ، يتم تنظيم المستندات من خلال المجموعات أو العلامات أو البيانات الوصفية أو الدلائل. على الرغم من أنه يمكن تنظيم المستندات أو تجميعها معًا ، فقد تحتوي المستندات على حقول مختلفة تمامًا عن بعضها البعض.
توفر بعض متاجر المستندات مثل MongoDB و CouchDB لغة تشبه SQL لأداء استعلامات معقدة. يدعم DynamoDB كلاً من القيم والوثائق الرئيسية.
توفر متاجر المستندات مرونة عالية وغالبًا ما تستخدم للعمل مع البيانات المتغيرة من حين لآخر.
المصدر: SQL & NOSQL ، تاريخ موجز
التجريد:
ColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>>
الوحدة الأساسية للبيانات في متجر الأعمدة الواسعة هي عمود (زوج/زوج القيمة). يمكن تجميع العمود في عائلات الأعمدة (مماثلة لجدول SQL). عائلات الأعمدة الفائقة مجموعة عمود مجموعة أخرى. يمكنك الوصول إلى كل عمود بشكل مستقل باستخدام مفتاح صف ، والأعمدة مع نفس مفتاح الصف تشكل صفًا. تحتوي كل قيمة على طابع زمني للإصدار وحل النزاع.
قدمت Google Bigtable كمتجر أعمدة واسعة ، والتي أثرت على HBase مفتوح المصدر في كثير من الأحيان في نظام Hadoop البيئي ، وكاساندرا من Facebook. تحافظ متاجر مثل Bigtable و HBase و Cassandra على مفاتيح في ترتيب معجمي ، مما يتيح استرجاعًا فعالًا لنطاقات المفاتيح الانتقائية.
توفر متاجر الأعمدة الواسعة توافرًا كبيرًا وقابلية التوسع العالية. غالبًا ما تستخدم لمجموعات البيانات الكبيرة جدًا.
المصدر: قاعدة بيانات الرسم البياني
التجريد: الرسم البياني
في قاعدة بيانات الرسم البياني ، كل عقدة هي سجل وكل قوس هو علاقة بين العقدتين. تم تحسين قواعد بيانات الرسم البياني لتمثيل علاقات معقدة مع العديد من المفاتيح الأجنبية أو العديد من العلاقات إلى العديد.
توفر قواعد بيانات الرسوم البيانية أداءً عالياً لنماذج البيانات ذات العلاقات المعقدة ، مثل الشبكة الاجتماعية. إنها جديدة نسبيًا ولا تستخدم على نطاق واسع ؛ قد يكون من الصعب العثور على أدوات وموارد التنمية. لا يمكن الوصول إلى العديد من الرسوم البيانية إلا باستخدام واجهات برمجة التطبيقات REST.
المصدر: الانتقال من RDBMS إلى NOSQL
أسباب SQL :
أسباب NOSQL :
عينة من البيانات المناسبة جيدًا لـ NOSQL:
المصدر: أنماط تصميم النظام القابلة للتطوير
يعمل التخزين المؤقت على تحسين أوقات تحميل الصفحة ويمكن أن يقلل من الحمل على الخوادم وقواعد البيانات الخاصة بك. في هذا النموذج ، سيقوم المرسل أولاً بالبحث إذا تم تقديم الطلب من قبل وحاول العثور على النتيجة السابقة للعودة ، من أجل حفظ التنفيذ الفعلي.
غالبًا ما تستفيد قواعد البيانات من توزيع موحد للقراءات ويكتب عبر أقسامها. العناصر الشائعة يمكن أن تشوه التوزيع ، مما تسبب في اختناقات. يمكن أن يساعد وضع ذاكرة التخزين المؤقت أمام قاعدة البيانات في امتصاص الأحمال والمسامير غير المتكافئة في حركة المرور.
يمكن أن تكون ذاكرة التخزين المؤقت على جانب العميل (OS أو متصفح) ، جانب الخادم ، أو في طبقة ذاكرة التخزين المؤقت المميزة.
تعتبر CDNs نوع من ذاكرة التخزين المؤقت.
يمكن أن يقدم الوكلاء العكسيين وذاكرة التخزين المؤقت مثل الورنيش محتوى ثابتًا وديناميكيًا مباشرة. يمكن لخوادم الويب أيضًا ذاكرة التخزين المؤقت ، وإعادة الاستجابات دون الحاجة إلى الاتصال خوادم التطبيق.
تتضمن قاعدة البيانات الخاصة بك عادةً مستوى من التخزين المؤقت في تكوين افتراضي ، محسّن لحالة الاستخدام العامة. يمكن لتبديل هذه الإعدادات لأنماط الاستخدام المحددة زيادة الأداء.
تعتبر التخزين المؤقت في الذاكرة مثل memcached و redis متاجر القيمة الرئيسية بين التطبيق الخاص بك وتخزين البيانات الخاص بك. نظرًا لأن البيانات محتفظ بها في ذاكرة الوصول العشوائي ، فهي أسرع بكثير من قواعد البيانات النموذجية حيث يتم تخزين البيانات على القرص. RAM محدودة أكثر من القرص ، لذا يمكن أن تساعد خوارزميات إبطال ذاكرة التخزين المؤقت مثل الأقل استخدامًا مؤخرًا (LRU) في إبطال الإدخالات "الباردة" والحفاظ على البيانات "الساخنة" في ذاكرة الوصول العشوائي.
Redis لديه الميزات الإضافية التالية:
هناك مستويات متعددة يمكنك تخزينها التي تنقسم إلى فئتين عامتين: استفسارات قاعدة البيانات والكائنات :
بشكل عام ، يجب أن تحاول تجنب التخزين المؤقت القائم على الملفات ، لأنه يجعل الاستنساخ والتقسيم التلقائي أكثر صعوبة.
كلما قمت بالاستعلام عن قاعدة البيانات ، تجزئة الاستعلام كمفتاح وتخزين النتيجة إلى ذاكرة التخزين المؤقت. هذا النهج يعاني من قضايا انتهاء الصلاحية:
راجع بياناتك ككائن ، على غرار ما تفعله برمز التطبيق الخاص بك. اطلب من التطبيق تجميع مجموعة البيانات من قاعدة البيانات إلى مثيل فئة أو بنية (بنية) بيانات:
اقتراحات ما يجب ذاكرة التخزين المؤقت:
نظرًا لأنه يمكنك فقط تخزين كمية محدودة من البيانات في ذاكرة التخزين المؤقت ، فستحتاج إلى تحديد استراتيجية تحديث ذاكرة التخزين المؤقت بشكل أفضل لحالة الاستخدام الخاصة بك.
المصدر: من ذاكرة التخزين المؤقت إلى شبكة البيانات في الذاكرة
التطبيق مسؤول عن القراءة والكتابة من التخزين. لا تتفاعل ذاكرة التخزين المؤقت مع التخزين مباشرة. التطبيق يفعل ما يلي:
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 عموما بهذه الطريقة.
القراءات اللاحقة للبيانات المضافة إلى ذاكرة التخزين المؤقت سريعة. يشار إلى ذاكرة التخزين المؤقت أيضًا باسم التحميل كسول. يتم تخزين البيانات المطلوبة فقط ، والتي تتجنب ملء ذاكرة التخزين المؤقت بالبيانات التي لم يتم طلبها.
المصدر: قابلية التوسع ، التوافر ، الاستقرار ، الأنماط
يستخدم التطبيق ذاكرة التخزين المؤقت كمتجر البيانات الرئيسي ، وقراءة البيانات وكتابةها ، في حين أن ذاكرة التخزين المؤقت مسؤولة عن القراءة والكتابة إلى قاعدة البيانات:
رمز التطبيق:
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 )تعد الكتابة عملية بطيئة بشكل عام بسبب عملية الكتابة ، ولكن القراءات اللاحقة للبيانات المكتوبة فقط سريعة. يكون المستخدمون بشكل عام أكثر تسامحًا مع الكمون عند تحديث البيانات من قراءة البيانات. البيانات في ذاكرة التخزين المؤقت ليست قديمة.
المصدر: قابلية التوسع ، التوافر ، الاستقرار ، الأنماط
في الكتابة ، يقوم التطبيق بما يلي:
المصدر: من ذاكرة التخزين المؤقت إلى شبكة البيانات في الذاكرة
يمكنك تكوين ذاكرة التخزين المؤقت لتحديث أي إدخال ذاكرة التخزين المؤقت التي تم الوصول إليها مؤخرًا تلقائيًا قبل انتهاء صلاحيتها.
يمكن أن يؤدي التحديث إلى الانتعاش إلى انخفاض الكمون مقابل القراءة إذا كان بإمكان ذاكرة التخزين المؤقت أن تتنبأ بدقة بالعناصر التي من المحتمل أن تكون هناك حاجة إليها في المستقبل.
المصدر: مقدمة لأنظمة الهندسة المعمارية للمقياس
تساعد سير العمل غير المتزامن في تقليل أوقات الطلب للعمليات باهظة الثمن التي يمكن تنفيذها في الخط. يمكنهم أيضًا المساعدة من خلال القيام بالعمل الذي يستغرق وقتًا طويلاً مسبقًا ، مثل التجميع الدوري للبيانات.
تتلقى قوائم قوائم الرسائل الرسائل ، والاحتفاظ بها ، وتسليم الرسائل. إذا كانت العملية بطيئة للغاية في أداء الخط ، فيمكنك استخدام قائمة انتظار الرسائل باستخدام سير العمل التالي:
لم يتم حظر المستخدم ويتم معالجة المهمة في الخلفية. خلال هذا الوقت ، قد يقوم العميل اختياريًا بكمية صغيرة من المعالجة لجعل الأمر يبدو أن المهمة قد اكتملت. على سبيل المثال ، إذا نشرت تغريدة ، فقد يتم نشر تغريدة على الفور على الجدول الزمني الخاص بك ، ولكن قد يستغرق الأمر بعض الوقت قبل أن يتم تسليم تغريدة إلى جميع متابعيك.
يعد Redis مفيدًا كوسيط للرسائل البسيطة ولكن يمكن فقد الرسائل.
تحظى RabbitMQ بشعبية ولكنها تتطلب منك التكيف مع بروتوكول "AMQP" وإدارة العقد الخاصة بك.
يتم استضافة Amazon SQS ولكن يمكن أن يكون لها الكمون العالي ولديه إمكانية تسليم الرسائل مرتين.
تتلقى قوائم انتظار المهام مهام وبياناتها ذات الصلة ، وتديرها ، ثم تقدم نتائجها. يمكنهم دعم الجدولة ويمكن استخدامها لتشغيل وظائف كثيفة الحوسبة في الخلفية.
الكرفس لديه دعم للجدولة ولديه دعم Python في المقام الأول.
إذا بدأت قوائم الانتظار في النمو بشكل ملحوظ ، فقد يصبح حجم قائمة الانتظار أكبر من الذاكرة ، مما يؤدي إلى تفتيت ذاكرة التخزين المؤقت ، وقراءات القرص ، وحتى الأداء الأبطأ. يمكن أن يساعد ضغط الظهر من خلال الحد من حجم قائمة الانتظار ، وبالتالي الحفاظ على ارتفاع معدل الإنتاجية وأوقات استجابة جيدة للوظائف الموجودة بالفعل في قائمة الانتظار. بمجرد ملء قائمة الانتظار ، يحصل العملاء على خادم مشغول أو رمز الحالة HTTP 503 للمحاولة مرة أخرى لاحقًا. يمكن للعملاء إعادة بناء الطلب في وقت لاحق ، ربما مع دعم الأسي.
المصدر: نموذج طبقة OSI 7
HTTP هي طريقة لترميز ونقل البيانات بين العميل والخادم. إنه بروتوكول طلب/استجابة: يقوم العملاء بإصدار الطلبات ويصدر الخوادم ردودًا مع معلومات محتوى ومعلومات عن حالة الإكمال حول الطلب. HTTP مكافحة بذاتها ، مما يتيح الطلبات والاستجابات للتدفق من خلال العديد من أجهزة التوجيه والخوادم المتوسطة التي تؤدي موازنة التحميل ، والتخزين المؤقت ، والتشفير ، والضغط.
يتكون طلب HTTP الأساسي من الفعل (الطريقة) ومورد (نقطة نهاية). فيما يلي أفعال HTTP الشائعة:
| فعل | وصف | idempotent* | آمن | قابلة للتخزين مؤقت |
|---|---|---|---|---|
| يحصل | يقرأ مورد | نعم | نعم | نعم |
| بريد | ينشئ مورد أو تشغيل عملية تعالج البيانات | لا | لا | نعم إذا كانت الاستجابة تحتوي على معلومات النضارة |
| يضع | يخلق أو استبدال مورد | نعم | لا | لا |
| رقعة | يقوم جزئيًا بتحديث مورد | لا | لا | نعم إذا كانت الاستجابة تحتوي على معلومات النضارة |
| يمسح | يحذف مورد | نعم | لا | لا |
*يمكن أن يسمى عدة مرات دون نتائج مختلفة.
HTTP هو بروتوكول طبقة التطبيق يعتمد على بروتوكولات المستوى الأدنى مثل TCP و UDP .
المصدر: كيفية صنع لعبة متعددة اللاعبين
TCP هو بروتوكول موجه نحو الاتصال عبر شبكة IP. يتم إنشاء الاتصال وإنهائه باستخدام مصافحة. جميع الحزم المرسلة مضمونة للوصول إلى الوجهة بالترتيب الأصلي وبدون فساد من خلال:
إذا لم يتلقى المرسل استجابة صحيحة ، فسيتم إعادة تقديم الحزم. إذا كانت هناك مهلة متعددة ، يتم إسقاط الاتصال. TCP أيضا ينفذ التحكم في التدفق والتحكم في الازدحام. هذه الضمانات تسبب تأخيرات وتؤدي بشكل عام إلى انتقال أقل كفاءة من UDP.
لضمان إنتاجية عالية ، يمكن لخوادم الويب أن تبقي عددًا كبيرًا من اتصالات TCP مفتوحة ، مما يؤدي إلى استخدام ذاكرة عالية. قد يكون من المكلف أن يكون لديك عدد كبير من الاتصالات المفتوحة بين مؤشرات ترابط خادم الويب والقول ، خادم memcached. يمكن أن يساعد تجميع الاتصال بالإضافة إلى التبديل إلى UDP عند الاقتضاء.
يعد TCP مفيدًا للتطبيقات التي تتطلب موثوقية عالية ولكنها أقل أهمية. تتضمن بعض الأمثلة خوادم الويب ومعلومات قاعدة البيانات و SMTP و FTP و SSH.
استخدم TCP عبر UDP عندما:
المصدر: كيفية صنع لعبة متعددة اللاعبين
UDP بدون اتصال. يتم ضمان بيانات البيانات (مماثلة للحزم) فقط على مستوى بيانات البيانات. قد تصل بيانات البيانات إلى وجهتها خارج الطلب أم لا على الإطلاق. UDP لا يدعم السيطرة على الازدحام. بدون ضمانات دعم TCP ، يكون UDP أكثر كفاءة بشكل عام.
يمكن لـ UDP البث ، وإرسال بيانات البيانات إلى جميع الأجهزة على الشبكة الفرعية. هذا مفيد مع DHCP لأن العميل لم يتلق بعد عنوان IP ، وبالتالي يمنع طريقة لدفق TCP بدون عنوان IP.
UDP أقل موثوقية ولكنه يعمل بشكل جيد في حالات الاستخدام في الوقت الفعلي مثل VoIP ، ودردشة الفيديو ، والبث ، والألعاب المتعددة في الوقت الفعلي.
استخدم UDP عبر TCP عندما:
المصدر: كسر مقابلة تصميم النظام
في RPC ، يتسبب العميل في تنفيذ إجراء على مساحة عنوان مختلفة ، وعادة ما يكون خادمًا عن بُعد. يتم ترميز الإجراء كما لو كانت مكالمة إجراء محلية ، حيث تخلص من تفاصيل كيفية التواصل مع الخادم من برنامج العميل. عادة ما تكون المكالمات عن بُعد أبطأ وأقل موثوقية من المكالمات المحلية ، لذلك من المفيد التمييز بين المكالمات RPC والمكالمات المحلية. تشمل أطر عمل RPC الشهيرة Protobuf و Thrift و Avro.
RPC هو بروتوكول استجابة الطلب:
عينة من مكالمات RPC:
GET /someoperation?data=anId
POST /anotheroperation
{
"data":"anId";
"anotherdata": "another value"
}
يركز RPC على فضح السلوكيات. غالبًا ما يتم استخدام RPCs لأسباب أداء مع الاتصالات الداخلية ، حيث يمكنك المكالمات الأصلية اليدوية لتناسب حالات الاستخدام بشكل أفضل.
اختر مكتبة أصلية (AKA SDK) عندما:
تميل واجهات برمجة تطبيقات HTTP التالية إلى استخدامها في كثير من الأحيان في واجهات برمجة التطبيقات العامة.
REST هو نمط معماري يفرض نموذج العميل/الخادم حيث يعمل العميل على مجموعة من الموارد التي يديرها الخادم. يوفر الخادم تمثيلًا للموارد والإجراءات التي يمكن أن تعالج أو الحصول على تمثيل جديد للموارد. يجب أن يكون كل التواصل عديمي الجنسية وقابلة للتخطيط.
هناك أربع صفات لواجهة مريحة:
عينة من مكالمات الراحة:
GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}
يركز REST على فضح البيانات. يقلل من الاقتران بين العميل/الخادم وغالبًا ما يتم استخدامه في واجهات برمجة تطبيقات HTTP العامة. يستخدم REST طريقة أكثر عامة وموحدة لفضح الموارد من خلال URIs ، والتمثيل من خلال الرؤوس ، والإجراءات من خلال الأفعال مثل GET ، POST ، PUT ، DELETE ، والتصحيح. كونه عديمي الجنسية ، فإن REST أمر رائع للتوسع الأفقي وتقسيمه.
| عملية | RPC | استراحة |
|---|---|---|
| اشتراك | بعد /الاشتراك | ما بعد /أشخاص |
| استقالة | بعد /استقالة { "personid": "1234" } | حذف /أشخاص /1234 |
| اقرأ شخص | الحصول على /rewperson؟ personId = 1234 | الحصول على /أشخاص /1234 |
| اقرأ قائمة عناصر الشخص | الحصول على /readuSeRsImSlist؟ personId = 1234 | الحصول على /أشخاص/1234/عناصر |
| أضف عنصرًا إلى عناصر الشخص | post /addItemTousErSitemSlist { "personid": "1234" ؛ "itemid": "456" } | Post /Peersons/1234/العناصر { "itemid": "456" } |
| تحديث عنصر | post /modifyItem { "itemid": "456" ؛ "المفتاح": "القيمة" } | وضع /العناصر /456 { "المفتاح": "القيمة" } |
| حذف عنصر | post /removeItem { "itemid": "456" } | حذف /عناصر /456 |
المصدر: هل تعرف حقًا لماذا تفضل الراحة على RPC
يمكن أن يستخدم هذا القسم بعض التحديثات. النظر في المساهمة!
الأمن موضوع واسع. ما لم تكن لديك خبرة كبيرة ، أو خلفية أمنية ، أو تتقدم لشغل منصب يتطلب معرفة الأمن ، ربما لن تحتاج إلى معرفة أكثر من الأساسيات:
في بعض الأحيان يُطلب منك القيام بتقديرات "عودة إلى المستشفى". على سبيل المثال ، قد تحتاج إلى تحديد المدة التي سيستغرقها لإنشاء 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
Latency Comparison Numbers
--------------------------
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
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
مقاييس مفيدة على أساس الأرقام أعلاه:
أسئلة مقابلة تصميم النظام الشائعة ، مع روابط للموارد حول كيفية حل كل منها.
| سؤال | مراجع) |
|---|---|
| تصميم خدمة مزامنة الملفات مثل Dropbox | youtube.com |
| تصميم محرك بحث مثل Google | queue.acm.org stackexchange.com Ardendertat.com ستانفورد |
| تصميم زاحف ويب قابل للتطوير مثل Google | Quora.com |
| تصميم مستندات Google | code.google.com neil.fraser.name |
| صمم متجرًا رئيسيًا مثل Redis | SlideShare.net |
| تصميم نظام ذاكرة التخزين المؤقت مثل memcached | SlideShare.net |
| تصميم نظام توصية مثل Amazon's | hulu.com ijcai13.org |
| تصميم نظام Tinyurl مثل bitly | N00TC0D3R.BlogSpot.com |
| صمم تطبيق دردشة مثل WhatsApp | Highscalability.com |
| صمم نظام مشاركة الصور مثل Instagram | Highscalability.com Highscalability.com |
| صمم وظيفة تغذية أخبار Facebook | Quora.com Quora.com SlideShare.net |
| صمم وظيفة الجدول الزمني على Facebook | facebook.com Highscalability.com |
| صمم وظيفة الدردشة فيسبوك | erlang-factory.com facebook.com |
| صمم وظيفة بحث الرسم البياني مثل Facebook's | facebook.com facebook.com facebook.com |
| تصميم شبكة توصيل المحتوى مثل CloudFlare | FIGSHARE.com |
| تصميم نظام موضوع تتجه مثل Twitter's | Michael-Noll.com Snikolov .wordpress.com |
| تصميم نظام توليد معرف عشوائي | blog.twitter.com github.com |
| إرجاع طلبات أفضل K خلال فترة زمنية | cs.ucsb.edu wpi.edu |
| تصميم نظام يخدم البيانات من مراكز بيانات متعددة | Highscalability.com |
| تصميم لعبة بطاقة متعددة اللاعبين عبر الإنترنت | indieflashblog.com BuildNewgames.com |
| تصميم نظام جمع القمامة | Stuffwithstuff.com واشنطن |
| تصميم محدد معدل API | https://stripe.com/blog/ |
| تصميم بورصة (مثل Nasdaq أو Binance) | جين ستريت تنفيذ Golang اذهب للتنفيذ |
| أضف سؤال تصميم النظام | يساهم |
مقالات حول كيفية تصميم أنظمة العالم الحقيقي.
المصدر: الجداول الزمنية على تويتر على نطاق واسع
لا تركز على التفاصيل الدقيقة للمقالات التالية ، بدلاً من ذلك:
| يكتب | نظام | مراجع) |
|---|---|---|
| معالجة البيانات | MapReduce - معالجة البيانات الموزعة من Google | Research.Google.com |
| معالجة البيانات | Spark - معالجة البيانات الموزعة من Databricks | SlideShare.net |
| معالجة البيانات | العاصفة - معالجة البيانات الموزعة من Twitter | SlideShare.net |
| متجر البيانات | BigTable - قاعدة بيانات موجهة نحو الأعمدة الموزعة من Google | هارفارد |
| متجر البيانات | HBase - تنفيذ المصدر المفتوح لـ BigTable | SlideShare.net |
| متجر البيانات | Cassandra - قاعدة بيانات موجهة نحو الأعمدة الموزعة من Facebook | SlideShare.net |
| متجر البيانات | DynamoDB - قاعدة بيانات موجهة نحو المستندات من Amazon | هارفارد |
| متجر البيانات | MongoDB - قاعدة بيانات موجهة نحو المستندات | SlideShare.net |
| متجر البيانات | 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 |
| متنوعات | Chubby - Lock service for loosely-coupled distributed systems from Google | research.google.com |
| متنوعات | Dapper - Distributed systems tracing infrastructure | research.google.com |
| متنوعات | Kafka - Pub/sub message queue from LinkedIn | SlideShare.net |
| متنوعات | Zookeeper - Centralized infrastructure and services enabling synchronization | SlideShare.net |
| Add an architecture | يساهم |
| شركة | مراجع) |
|---|---|
| أمازون | Amazon architecture |
| Cinchcast | Producing 1,500 hours of audio every day |
| DataSift | Realtime datamining At 120,000 tweets per second |
| دروببوإكس | How we've scaled Dropbox |
| إسبن | Operating At 100,000 duh nuh nuhs per second |
| جوجل | Google architecture |
| انستغرام | 14 million users, terabytes of photos What powers Instagram |
| Justin.tv | Justin.Tv's live video broadcasting architecture |
| فيسبوك | 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 architecture |
| صندوق البريد | From 0 to one million users in 6 weeks |
| نيتفليكس | A 360 Degree View Of The Entire Netflix Stack Netflix: What Happens When You Press Play? |
| بينتريست | 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 |
| قوة المبيعات | How they handle 1.3 billion transactions a day |
| Stack Overflow | Stack Overflow architecture |
| موقع TripAdvisor | 40M visitors, 200M dynamic page views, 30TB data |
| نعرفكم | 15 billion page views a month |
| تغريد | 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 |
| اوبر | How Uber scales their real-time market platform Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories |
| واتساب | The WhatsApp architecture Facebook bought for $19 billion |
| يوتيوب | YouTube scalability YouTube architecture |
Architectures for companies you are interviewing with.
Questions you encounter might be from the same domain.
Looking to add a blog? To avoid duplicating work, consider adding your company blog to the following repo:
Interested in adding a section or helping complete one in-progress? يساهم!
Credits and sources are provided throughout this repo.
شكر خاص ل:
Feel free to contact me to discuss any issues, questions, or comments.
My contact info can be found on my GitHub page.
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/
