From 76abfa412248db2cb37aa1648937a21e455f56aa Mon Sep 17 00:00:00 2001 From: MohamedMetwalli5 Date: Wed, 26 Feb 2025 17:06:17 +0200 Subject: [PATCH] Add Arabic Translation --- README-ar.md | 1781 +++++++++++++++++++++++++++++++++++++++++++++ README-ja.md | 2 +- README-zh-Hans.md | 2 +- README-zh-TW.md | 2 +- TRANSLATIONS.md | 13 +- 5 files changed, 1790 insertions(+), 10 deletions(-) create mode 100644 README-ar.md diff --git a/README-ar.md b/README-ar.md new file mode 100644 index 00000000..288ffd73 --- /dev/null +++ b/README-ar.md @@ -0,0 +1,1781 @@ +*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) ∙ [العَرَبِيَّة‎](README-ar.md) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [إضافة ترجمة](https://github.com/donnemartin/system-design-primer/issues/28)* + +**ساعد في [ترجمة](TRANSLATIONS.md) هذا المستند!** + +# دليل تصميم النظم (System Design Primer) + +

+ +
+

+ +## الهدف + +> تعلم أساسيات تصميم الأنظمة عالية المستوى (large-scale systems). +> +> التحضير لمقابلات تصميم النظم (system design interviews). +### تعلم كيفية تصميم الأنظمة واسعة النطاق + +إن تعلم كيفية تصميم الأنظمة القابلة للتطوير (scalable systems) سيساعدك في تطوير مهاراتك كمهندس برمجيات. + +تصميم النظم (system design) هو مجال واسع النطاق. هناك **كم هائل من المصادر المتوفرة على الإنترنت** حول مبادئ تصميم النظم. + +هذا الـ repository عبارة عن **مجموعة منظمة** من المصادر لمساعدتك في تعلم كيفية بناء أنظمة على نطاق واسع (large-scale systems). + +### تعلم من مجتمع المصادر المفتوحة (Open Source) + +هذا مشروع open source يتم تحديثه بشكل مستمر. + +نرحب بـ [المساهمات](#contributing)! +### التحضير لمقابلة تصميم النظم (System Design Interview) + +بالإضافة إلى مقابلات البرمجة (coding interviews)، يُعد تصميم النظم **عنصراً أساسياً** في **عملية المقابلة التقنية** لدى العديد من شركات التقنية. + +**تدرب على الأسئلة الشائعة في مقابلات تصميم النظم** و**قارن** إجاباتك مع **الحلول المرجعية** التي تشمل: المناقشات التقنية والكود والمخططات التوضيحية. + +مواضيع تكميلية للتحضير للمقابلة: + +* [دليل الدراسة](#study-guide) +* [كيفية التعامل مع أسئلة مقابلة تصميم النظم](#how-to-approach-a-system-design-interview-question) +* [أسئلة مقابلة تصميم النظم **مع الحلول**](#system-design-interview-questions-with-solutions) +* [أسئلة مقابلة التصميم كائني التوجه (Object-Oriented Design) **مع الحلول**](#object-oriented-design-interview-questions-with-solutions) +* [أسئلة إضافية في مقابلات تصميم النظم](#additional-system-design-interview-questions) +## بطاقات Anki التعليمية + +

+ +
+

+ +تستخدم [بطاقات Anki](https://apps.ankiweb.net/) التكرار المتباعد (spaced repetition) لمساعدتك في حفظ المفاهيم الأساسية لتصميم النظم. + +* [مجموعة System Design](https://github.com/donnemartin/system-design-primer/tree/master/resources/flash_cards/System%20Design.apkg) +* [مجموعة System Design Exercises](https://github.com/donnemartin/system-design-primer/tree/master/resources/flash_cards/System%20Design%20Exercises.apkg) +* [مجموعة Object-Oriented Design](https://github.com/donnemartin/system-design-primer/tree/master/resources/flash_cards/OO%20Design.apkg) + +مثالية للمراجعة أثناء التنقل. + +### مورد للبرمجة: Interactive Coding Challenges + +هل تبحث عن موارد للمساعدة في التحضير لـ [**مقابلات البرمجة**](https://github.com/donnemartin/interactive-coding-challenges)؟ + +

+ +
+

+ +تفقد المستودع المرافق [**Interactive Coding Challenges**](https://github.com/donnemartin/interactive-coding-challenges)، والذي يتضمن مجموعة Anki إضافية: + +* [مجموعة Coding](https://github.com/donnemartin/interactive-coding-challenges/tree/master/anki_cards/Coding.apkg) +## المساهمة + +> تعلم من المجتمع. + +نرحب بتقديم pull requests للمساعدة في: + +* تصحيح الأخطاء +* تحسين المحتوى +* إضافة أقسام جديدة +* [الترجمة](https://github.com/donnemartin/system-design-primer/issues/28) + +المحتوى الذي يحتاج إلى تحسين سيتم تمييزه [تحت التطوير](#under-development). + +يرجى مراجعة [دليل المساهمة](CONTRIBUTING.md). + +## فهرس موضوعات تصميم النظم + +> ملخصات موضوعات تصميم النظم المختلفة، متضمنة المزايا والعيوب. **كل شيء عبارة عن trade-off**. +> +> كل قسم يحتوي على روابط لمصادر أكثر تفصيلاً. + +

+ +
+

+ +* [موضوعات تصميم النظم: ابدأ من هنا](#system-design-topics-start-here) + * [الخطوة 1: مراجعة محاضرة scalability](#step-1-review-the-scalability-video-lecture) + * [الخطوة 2: مراجعة مقالة scalability](#step-2-review-the-scalability-article) + * [الخطوات التالية](#next-steps) +* [Performance مقابل Scalability](#performance-vs-scalability) +* [Latency مقابل Throughput](#latency-vs-throughput) +* [Availability مقابل Consistency](#availability-vs-consistency) + * [نظرية CAP](#cap-theorem) + * [CP - Consistency و Partition Tolerance](#cp---consistency-and-partition-tolerance) + * [AP - Availability و Partition Tolerance](#ap---availability-and-partition-tolerance) +* [أنماط Consistency](#consistency-patterns) + * [Weak Consistency](#weak-consistency) + * [Eventual Consistency](#eventual-consistency) + * [Strong Consistency](#strong-consistency) +* [أنماط Availability](#availability-patterns) + * [Failover](#fail-over) + * [Replication](#replication) + * [Availability بالأرقام](#availability-in-numbers) +* [Domain Name System](#domain-name-system) +* [Content Delivery Network](#content-delivery-network) + * [Push CDNs](#push-cdns) + * [Pull CDNs](#pull-cdns) +* [Load Balancer](#load-balancer) + * [Active-passive](#active-passive) + * [Active-active](#active-active) + * [Layer 4 load balancing](#layer-4-load-balancing) + * [Layer 7 load balancing](#layer-7-load-balancing) + * [Horizontal scaling](#horizontal-scaling) +* [Reverse Proxy (Web Server)](#reverse-proxy-web-server) + * [Load Balancer مقابل Reverse Proxy](#load-balancer-vs-reverse-proxy) +* [طبقة التطبيق](#application-layer) + * [Microservices](#microservices) + * [Service Discovery](#service-discovery) +* [قواعد البيانات](#database) + * [Relational Database Management System (RDBMS)](#relational-database-management-system-rdbms) + * [Master-slave replication](#master-slave-replication) + * [Master-master replication](#master-master-replication) + * [Federation](#federation) + +## دليل الدراسة + +> المواضيع المقترحة للمراجعة بناءً على الجدول الزمني لمقابلتك (قصير، متوسط، طويل). + +![Imgur](images/OfVllex.png) + +**س: هل يجب أن أعرف كل شيء هنا للمقابلة؟** + +**ج: لا، لست بحاجة لمعرفة كل شيء هنا للتحضير للمقابلة**. + +ما يُسأل عنه في المقابلة يعتمد على متغيرات مثل: + +* مقدار خبرتك +* خلفيتك التقنية +* المناصب التي تتقدم لها +* الشركات التي تجري معها المقابلات +* الحظ + +عادةً ما يُتوقع من المرشحين ذوي الخبرة معرفة المزيد عن تصميم النظم. قد يُتوقع من المهندسين المعماريين أو قادة الفرق معرفة أكثر من المساهمين الفرديين. من المحتمل أن تجري شركات التقنية الكبرى جولة أو أكثر من مقابلات التصميم. + +ابدأ بشكل واسع ثم تعمق في بعض المجالات. من المفيد معرفة القليل عن مواضيع تصميم النظم المختلفة. عدّل الدليل التالي بناءً على جدولك الزمني، وخبرتك، والمناصب التي تتقدم لها، والشركات التي تجري معها المقابلات. + +* **جدول زمني قصير** - اهدف إلى **الاتساع** في مواضيع تصميم النظم. تدرب عن طريق حل **بعض** أسئلة المقابلات. +* **جدول زمني متوسط** - اهدف إلى **الاتساع** و**بعض العمق** في مواضيع تصميم النظم. تدرب عن طريق حل **العديد** من أسئلة المقابلات. +* **جدول زمني طويل** - اهدف إلى **الاتساع** و**مزيد من العمق** في مواضيع تصميم النظم. تدرب عن طريق حل **معظم** أسئلة المقابلات. + +| | قصير | متوسط | طويل | +|---|---|---|---| +| اقرأ [مواضيع تصميم النظم](#index-of-system-design-topics) للحصول على فهم واسع لكيفية عمل النظم | :+1: | :+1: | :+1: | +| اقرأ بعض المقالات في [مدونات هندسة الشركات](#company-engineering-blogs) للشركات التي تجري معها المقابلات | :+1: | :+1: | :+1: | +| اقرأ بعض [البنى الحقيقية للأنظمة](#real-world-architectures) | :+1: | :+1: | :+1: | +| راجع [كيفية مقاربة سؤال مقابلة تصميم النظم](#how-to-approach-a-system-design-interview-question) | :+1: | :+1: | :+1: | +| اعمل على [أسئلة مقابلة تصميم النظم مع الحلول](#system-design-interview-questions-with-solutions) | بعضها | العديد | معظمها | +| اعمل على [أسئلة مقابلة التصميم الموجه للكائنات مع الحلول](#object-oriented-design-interview-questions-with-solutions) | بعضها | العديد | معظمها | +| راجع [أسئلة إضافية لمقابلة تصميم النظم](#additional-system-design-interview-questions) | بعضها | العديد | معظمها | + +## كيفية مقاربة سؤال مقابلة تصميم النظم + +> كيفية معالجة سؤال مقابلة تصميم النظم. + +مقابلة تصميم النظم هي **محادثة مفتوحة**. يُتوقع منك قيادتها. + +يمكنك استخدام الخطوات التالية لتوجيه المناقشة. للمساعدة في ترسيخ هذه العملية، اعمل على قسم [أسئلة مقابلة تصميم النظم مع الحلول](#system-design-interview-questions-with-solutions) باستخدام الخطوات التالية. + +### الخطوة 1: حدد حالات الاستخدام والقيود والافتراضات + +اجمع المتطلبات وحدد نطاق المشكلة. اطرح أسئلة لتوضيح حالات الاستخدام والقيود. ناقش الافتراضات. + +* من سيستخدمه؟ +* كيف سيستخدمونه؟ +* كم عدد المستخدمين؟ +* ما الذي يفعله النظام؟ +* ما هي مدخلات ومخرجات النظام؟ +* كم حجم البيانات التي نتوقع التعامل معها؟ +* كم عدد الطلبات في الثانية التي نتوقعها؟ +* ما هي النسبة المتوقعة للقراءة مقابل الكتابة؟ + +### الخطوة 2: إنشاء تصميم عالي المستوى + +حدد تصميماً عالي المستوى مع جميع المكونات المهمة. + +* ارسم المكونات الرئيسية والروابط +* برر أفكارك + +### الخطوة 3: تصميم المكونات الأساسية + +تعمق في تفاصيل كل مكون أساسي. على سبيل المثال، إذا طُلب منك [تصميم خدمة تقصير الروابط](solutions/system_design/pastebin/README.md)، ناقش: + +* توليد وتخزين hash للرابط الكامل + * [MD5](solutions/system_design/pastebin/README.md) و [Base62](solutions/system_design/pastebin/README.md) + * تصادمات الـ hash + * SQL أو NoSQL + * مخطط قاعدة البيانات +* ترجمة الرابط المختصر إلى الرابط الكامل + * البحث في قاعدة البيانات +* تصميم API والتصميم الموجه للكائنات + +### الخطوة 4: تطوير التصميم + +حدد وعالج نقاط الاختناق، مع مراعاة القيود. على سبيل المثال، هل تحتاج إلى ما يلي لمعالجة مشاكل قابلية التطوير؟ + +* موازن التحميل +* التطوير الأفقي +* التخزين المؤقت +* تجزئة قاعدة البيانات + +ناقش الحلول المحتملة والمقايضات. كل شيء هو مقايضة. عالج نقاط الاختناق باستخدام [مبادئ تصميم النظم القابلة للتطوير](#index-of-system-design-topics). + +### حسابات تقريبية + +قد يُطلب منك إجراء بعض التقديرات يدوياً. راجع [الملحق](#appendix) للموارد التالية: + +* [استخدام الحسابات التقريبية](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html) +* [جدول قوى الاثنين](#powers-of-two-table) +* [أرقام زمن الاستجابة التي يجب أن يعرفها كل مبرمج](#latency-numbers-every-programmer-should-know) + +### المصادر وقراءات إضافية + +راجع الروابط التالية للحصول على فكرة أفضل عما يمكن توقعه: + +* [كيفية التفوق في مقابلة تصميم النظم](https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/) +* [مقابلة تصميم النظام](http://www.hiredintech.com/system-design) +* [مقدمة لمقابلات البنية والنظم](https://www.youtube.com/watch?v=ZgdS0EUmn70) +* [قالب تصميم النظام](https://leetcode.com/discuss/career/229177/My-System-Design-Template) + +## أسئلة مقابلة تصميم النظم مع الحلول + +> أسئلة شائعة لمقابلات تصميم النظم مع مناقشات نموذجية وشيفرة ومخططات. +> +> الحلول مرتبطة بالمحتوى في مجلد `solutions/`. + +| السؤال | | +|---|---| +| تصميم Pastebin.com (أو Bit.ly) | [الحل](solutions/system_design/pastebin/README.md) | +| تصميم الجدول الزمني والبحث في Twitter (أو خلاصة Facebook والبحث) | [الحل](solutions/system_design/twitter/README.md) | +| تصميم متصفح ويب | [الحل](solutions/system_design/web_crawler/README.md) | +| تصميم Mint.com | [الحل](solutions/system_design/mint/README.md) | +| تصميم هياكل البيانات لشبكة اجتماعية | [الحل](solutions/system_design/social_graph/README.md) | +| تصميم مخزن key-value لمحرك بحث | [الحل](solutions/system_design/query_cache/README.md) | +| تصميم ميزة تصنيف المبيعات حسب الفئة في Amazon | [الحل](solutions/system_design/sales_rank/README.md) | +| تصميم نظام يتطور لملايين المستخدمين على AWS | [الحل](solutions/system_design/scaling_aws/README.md) | +| أضف سؤال تصميم نظام | [ساهم](#contributing) | +### تصميم Pastebin.com (أو Bit.ly) + +[عرض التمرين والحل](solutions/system_design/pastebin/README.md) + +![Imgur](images/4edXG0T.png) + +### تصميم الجدول الزمني والبحث في Twitter (أو خلاصة Facebook والبحث) + +[عرض التمرين والحل](solutions/system_design/twitter/README.md) + +![Imgur](images/jrUBAF7.png) + +### تصميم متصفح ويب + +[عرض التمرين والحل](solutions/system_design/web_crawler/README.md) + +![Imgur](images/bWxPtQA.png) + +### تصميم Mint.com + +[عرض التمرين والحل](solutions/system_design/mint/README.md) + +![Imgur](images/V5q57vU.png) + +### تصميم هياكل البيانات لشبكة اجتماعية + +[عرض التمرين والحل](solutions/system_design/social_graph/README.md) + +![Imgur](images/cdCv5g7.png) + +### تصميم مخزن key-value لمحرك بحث + +[عرض التمرين والحل](solutions/system_design/query_cache/README.md) + +![Imgur](images/4j99mhe.png) + +### تصميم ميزة تصنيف المبيعات حسب الفئة في Amazon + +[عرض التمرين والحل](solutions/system_design/sales_rank/README.md) + +![Imgur](images/MzExP06.png) + +### تصميم نظام يتطور لملايين المستخدمين على AWS + +[عرض التمرين والحل](solutions/system_design/scaling_aws/README.md) + +![Imgur](images/jj3A5N8.png) + +## أسئلة مقابلة التصميم الموجه للكائنات مع الحلول + +> أسئلة شائعة لمقابلات التصميم الموجه للكائنات مع مناقشات نموذجية وشيفرة ومخططات. +> +> الحلول مرتبطة بالمحتوى في مجلد `solutions/`. + +>**ملاحظة: هذا القسم تحت التطوير** + +| السؤال | | +|---|---| +| تصميم hash map | [الحل](solutions/object_oriented_design/hash_table/hash_map.ipynb) | +| تصميم ذاكرة التخزين المؤقت الأقل استخداماً مؤخراً | [الحل](solutions/object_oriented_design/lru_cache/lru_cache.ipynb) | +| تصميم مركز اتصال | [الحل](solutions/object_oriented_design/call_center/call_center.ipynb) | +| تصميم مجموعة بطاقات | [الحل](solutions/object_oriented_design/deck_of_cards/deck_of_cards.ipynb) | +| تصميم موقف سيارات | [الحل](solutions/object_oriented_design/parking_lot/parking_lot.ipynb) | +| تصميم خادم دردشة | [الحل](solutions/object_oriented_design/online_chat/online_chat.ipynb) | +| تصميم مصفوفة دائرية | [ساهم](#contributing) | +| أضف سؤال تصميم موجه للكائنات | [ساهم](#contributing) | + +## مواضيع تصميم النظم: ابدأ هنا + +هل أنت جديد في تصميم النظم؟ + +أولاً، ستحتاج إلى فهم أساسي للمبادئ الشائعة، والتعرف على ماهيتها، وكيفية استخدامها، ومزاياها وعيوبها. + +### الخطوة 1: مراجعة محاضرة قابلية التطوير + +[محاضرة قابلية التطوير في هارفارد](https://www.youtube.com/watch?v=-W9F__D3oY4) + +* المواضيع المغطاة: + * التطوير العمودي + * التطوير الأفقي + * التخزين المؤقت + * موازنة التحميل + * النسخ المتماثل لقاعدة البيانات + * تجزئة قاعدة البيانات + +### الخطوة 2: مراجعة مقالة قابلية التطوير + +[قابلية التطوير](https://web.archive.org/web/20221030091841/http://www.lecloud.net/tagged/scalability/chrono) + +* المواضيع المغطاة: + * [النسخ المتماثلة](https://web.archive.org/web/20220530193911/https://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones) + * [قواعد البيانات](https://web.archive.org/web/20220602114024/https://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database) + * [ذاكرة التخزين المؤقت](https://web.archive.org/web/20230126233752/https://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache) + * [اللاتزامن](https://web.archive.org/web/20220926171507/https://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism) + +### الخطوات التالية + +بعد ذلك، سننظر في المقايضات عالية المستوى: + +* **الأداء** مقابل **قابلية التطوير** +* **زمن الاستجابة** مقابل **الإنتاجية** +* **التوافر** مقابل **الاتساق** + +ضع في اعتبارك أن **كل شيء هو مقايضة**. + +ثم سنتعمق في مواضيع أكثر تحديداً مثل DNS وشبكات CDN وموازنات التحميل. + +## الأداء مقابل قابلية التطوير + +تكون الخدمة **قابلة للتطوير** إذا أدت إلى زيادة في **الأداء** بشكل يتناسب مع الموارد المضافة. بشكل عام، تعني زيادة الأداء خدمة المزيد من وحدات العمل، ولكن يمكن أن تكون أيضاً للتعامل مع وحدات عمل أكبر، مثل عندما تنمو مجموعات البيانات.1 + +طريقة أخرى للنظر إلى الأداء مقابل قابلية التطوير: + +* إذا كان لديك مشكلة في **الأداء**، فإن نظامك بطيء لمستخدم واحد. +* إذا كان لديك مشكلة في **قابلية التطوير**، فإن نظامك سريع لمستخدم واحد ولكنه بطيء تحت الحمل الثقيل. + +### المصادر وقراءات إضافية + +* [كلمة عن قابلية التطوير](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html) +* [أنماط قابلية التطوير والتوافر والاستقرار](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/) + +## زمن الاستجابة مقابل الإنتاجية + +**زمن الاستجابة** هو الوقت المستغرق لتنفيذ إجراء ما أو إنتاج نتيجة ما. + +**الإنتاجية** هي عدد هذه الإجراءات أو النتائج في وحدة الزمن. + +بشكل عام، يجب أن تهدف إلى **أقصى إنتاجية** مع **زمن استجابة مقبول**. + +### المصادر وقراءات إضافية + +* [فهم زمن الاستجابة مقابل الإنتاجية](https://community.cadence.com/cadence_blogs_8/b/fv/posts/understanding-latency-vs-throughput) +## التوافر مقابل الاتساق + +### نظرية CAP + +

+ +
+ المصدر: مراجعة نظرية CAP +

+ +في نظام الحوسبة الموزع، يمكنك فقط دعم اثنين من الضمانات التالية: + +* **الاتساق** - كل عملية قراءة تستقبل أحدث عملية كتابة أو خطأ +* **التوافر** - كل طلب يتلقى استجابة، دون ضمان أنها تحتوي على أحدث نسخة من المعلومات +* **تحمل التجزئة** - يستمر النظام في العمل رغم التجزئة العشوائية بسبب أعطال الشبكة + +*الشبكات ليست موثوقة، لذا ستحتاج إلى دعم تحمل التجزئة. ستحتاج إلى المفاضلة بين الاتساق والتوافر.* + +#### CP - الاتساق وتحمل التجزئة + +قد يؤدي انتظار استجابة من العقدة المجزأة إلى خطأ انتهاء المهلة. CP هو خيار جيد إذا كانت متطلبات عملك تتطلب عمليات قراءة وكتابة ذرية. + +#### AP - التوافر وتحمل التجزئة + +تقوم الاستجابات بإرجاع النسخة المتاحة بشكل أسرع من البيانات المتوفرة على أي عقدة، والتي قد لا تكون الأحدث. قد تستغرق عمليات الكتابة بعض الوقت للانتشار عند حل التجزئة. + +AP هو خيار جيد إذا كانت متطلبات العمل تسمح بـ [الاتساق النهائي](#eventual-consistency) أو عندما يحتاج النظام إلى مواصلة العمل رغم الأخطاء الخارجية. + +### المصادر وقراءات إضافية + +* [مراجعة نظرية CAP](http://robertgreiner.com/2014/08/cap-theorem-revisited/) +* [مقدمة مبسطة لنظرية CAP](http://ksat.me/a-plain-english-introduction-to-cap-theorem) +* [الأسئلة الشائعة حول CAP](https://github.com/henryr/cap-faq) +* [نظرية CAP](https://www.youtube.com/watch?v=k-Yaq8AHlFA) + +## أنماط الاتساق + +مع وجود نسخ متعددة من نفس البيانات، نواجه خيارات حول كيفية مزامنتها حتى يكون لدى العملاء رؤية متسقة للبيانات. تذكر تعريف الاتساق من [نظرية CAP](#cap-theorem) - كل عملية قراءة تستقبل أحدث عملية كتابة أو خطأ. + +### الاتساق الضعيف + +بعد الكتابة، قد ترى عمليات القراءة التغيير أو لا تراه. يتم اتباع نهج أفضل جهد. + +يظهر هذا النهج في أنظمة مثل memcached. يعمل الاتساق الضعيف بشكل جيد في حالات الاستخدام في الوقت الفعلي مثل VoIP ودردشة الفيديو والألعاب متعددة اللاعبين في الوقت الفعلي. على سبيل المثال، إذا كنت في مكالمة هاتفية وفقدت الاتصال لبضع ثوانٍ، عندما تستعيد الاتصال لن تسمع ما قيل أثناء فقدان الاتصال. + +### الاتساق النهائي + +بعد الكتابة، سترى عمليات القراءة التغيير في النهاية (عادةً خلال مللي ثانية). يتم نسخ البيانات بشكل غير متزامن. + +يظهر هذا النهج في أنظمة مثل DNS والبريد الإلكتروني. يعمل الاتساق النهائي بشكل جيد في الأنظمة عالية التوافر. + +### الاتساق القوي + +بعد الكتابة، سترى عمليات القراءة التغيير. يتم نسخ البيانات بشكل متزامن. + +يظهر هذا النهج في أنظمة الملفات وأنظمة RDBMS. يعمل الاتساق القوي بشكل جيد في الأنظمة التي تحتاج إلى المعاملات. + +### المصادر وقراءات إضافية + +* [المعاملات عبر مراكز البيانات](http://snarfed.org/transactions_across_datacenters_io.html) + +## أنماط التوافر + +هناك نمطان متكاملان لدعم التوافر العالي: **التحول عند الفشل** و**النسخ المتماثل**. + +### التحول عند الفشل + +#### نشط-سلبي + +في التحول عند الفشل نشط-سلبي، يتم إرسال نبضات القلب بين الخادم النشط والخادم السلبي في وضع الانتظار. إذا تم قطع نبضات القلب، يتولى الخادم السلبي عنوان IP الخاص بالخادم النشط ويستأنف الخدمة. + +يتحدد طول وقت التوقف بما إذا كان الخادم السلبي يعمل بالفعل في وضع الانتظار 'الساخن' أو ما إذا كان يحتاج إلى بدء التشغيل من وضع الانتظار 'البارد'. يتعامل الخادم النشط فقط مع حركة المرور. + +يمكن أيضًا الإشارة إلى التحول عند الفشل نشط-سلبي باسم التحول عند الفشل رئيسي-تابع. + +#### نشط-نشط + +في نشط-نشط، كلا الخادمين يديران حركة المرور، موزعين الحمل بينهما. + +إذا كانت الخوادم مواجهة للجمهور، فسيحتاج DNS إلى معرفة عناوين IP العامة لكلا الخادمين. إذا كانت الخوادم داخلية، فسيحتاج منطق التطبيق إلى معرفة كلا الخادمين. + +يمكن أيضًا الإشارة إلى التحول عند الفشل نشط-نشط باسم التحول عند الفشل رئيسي-رئيسي. + +### عيوب التحول عند الفشل + +* يضيف التحول عند الفشل المزيد من الأجهزة وتعقيدات إضافية. +* هناك احتمال لفقدان البيانات إذا فشل النظام النشط قبل أن يتمكن من نسخ أي بيانات مكتوبة حديثًا إلى النظام السلبي. + +### النسخ المتماثل + +#### رئيسي-تابع ورئيسي-رئيسي + +تتم مناقشة هذا الموضوع بشكل أكبر في قسم [قاعدة البيانات](#database): + +* [النسخ المتماثل رئيسي-تابع](#master-slave-replication) +* [النسخ المتماثل رئيسي-رئيسي](#master-master-replication) + +### التوافر بالأرقام + +غالبًا ما يتم قياس التوافر من خلال وقت التشغيل (أو وقت التوقف) كنسبة مئوية من الوقت الذي تكون فيه الخدمة متاحة. يتم قياس التوافر عمومًا بعدد الـ 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% على التوالي: + +``` +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%. +## نظام أسماء النطاقات (Domain Name System) + +

+ +
+ المصدر: عرض تقديمي عن أمان DNS +

+ +يقوم نظام أسماء النطاقات (DNS) بترجمة اسم النطاق مثل www.example.com إلى عنوان IP. + +نظام DNS هرمي، مع وجود عدد قليل من الخوادم الموثوقة في المستوى الأعلى. يوفر جهاز التوجيه (router) أو مزود خدمة الإنترنت (ISP) الخاص بك معلومات حول خادم (أو خوادم) DNS التي يجب الاتصال بها عند إجراء عملية البحث. تقوم خوادم DNS في المستويات الأدنى بتخزين التعيينات مؤقتًا، والتي قد تصبح قديمة بسبب تأخيرات انتشار DNS. يمكن أيضًا تخزين نتائج DNS مؤقتًا بواسطة المتصفح أو نظام التشغيل لفترة زمنية معينة، يحددها [وقت الصلاحية (TTL)](https://en.wikipedia.org/wiki/Time_to_live). + +* **سجل NS (خادم الأسماء)** - يحدد خوادم DNS للنطاق/النطاق الفرعي الخاص بك. +* **سجل MX (تبادل البريد)** - يحدد خوادم البريد لقبول الرسائل. +* **سجل A (العنوان)** - يوجه اسمًا إلى عنوان IP. +* **سجل CNAME (الاسم القانوني)** - يوجه اسمًا إلى اسم آخر أو `CNAME` (example.com إلى www.example.com) أو إلى سجل `A`. + +توفر خدمات مثل [CloudFlare](https://www.cloudflare.com/dns/) و [Route 53](https://aws.amazon.com/route53/) خدمات DNS مُدارة. يمكن لبعض خدمات DNS توجيه حركة المرور من خلال طرق مختلفة: + +* [التوزيع الدائري المرجح (Weighted round robin)](https://www.jscape.com/blog/load-balancing-algorithms) + * منع حركة المرور من الذهاب إلى الخوادم قيد الصيانة + * الموازنة بين المجموعات المتفاوتة الحجم + * اختبار A/B +* [التوجيه المبني على زمن الاستجابة (Latency-based)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html) +* [التوجيه المبني على الموقع الجغرافي (Geolocation-based)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html) + +### عيوب نظام DNS + +* يؤدي الوصول إلى خادم DNS إلى تأخير طفيف، على الرغم من تخفيف ذلك من خلال التخزين المؤقت الموضح أعلاه. +* يمكن أن تكون إدارة خادم DNS معقدة وتتم إدارتها عموماً من قبل [الحكومات ومزودي خدمة الإنترنت والشركات الكبرى](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729). +* تعرضت خدمات DNS مؤخراً [لهجمات DDoS](http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/)، مما منع المستخدمين من الوصول إلى مواقع مثل Twitter دون معرفة عنوان (عناوين) IP الخاصة به. + +### المصادر وقراءات إضافية + +* [بنية DNS](https://technet.microsoft.com/en-us/library/dd197427(v=ws.10).aspx) +* [ويكيبيديا](https://en.wikipedia.org/wiki/Domain_Name_System) +* [مقالات DNS](https://support.dnsimple.com/categories/dns/) + +## شبكة توصيل المحتوى (CDN) + +

+ +
+ المصدر: لماذا نستخدم CDN +

+ +شبكة توصيل المحتوى (CDN) هي شبكة عالمية موزعة من الخوادم الوسيطة، تقدم المحتوى من مواقع أقرب إلى المستخدم. عادةً، يتم تقديم الملفات الثابتة مثل HTML/CSS/JS والصور ومقاطع الفيديو من CDN، على الرغم من أن بعض شبكات CDN مثل CloudFront من Amazon تدعم المحتوى الديناميكي. سيخبر حل DNS للموقع العملاء بالخادم الذي يجب الاتصال به. + +يمكن أن يؤدي تقديم المحتوى من شبكات CDN إلى تحسين الأداء بشكل كبير بطريقتين: + +* يتلقى المستخدمون المحتوى من مراكز البيانات القريبة منهم +* لا تحتاج خوادمك إلى خدمة الطلبات التي تلبيها CDN + +### شبكات CDN للدفع (Push CDNs) + +تتلقى شبكات CDN للدفع محتوى جديداً كلما حدثت تغييرات على خادمك. أنت تتحمل المسؤولية الكاملة عن توفير المحتوى، والرفع مباشرة إلى CDN وإعادة كتابة عناوين URL للإشارة إلى CDN. يمكنك تكوين متى ينتهي المحتوى ومتى يتم تحديثه. يتم رفع المحتوى فقط عندما يكون جديداً أو تم تغييره، مما يقلل حركة المرور، ولكن يزيد التخزين إلى أقصى حد. + +المواقع التي لديها قدر قليل من حركة المرور أو المواقع التي لا يتم تحديث محتواها بشكل متكرر تعمل بشكل جيد مع شبكات CDN للدفع. يتم وضع المحتوى على شبكات CDN مرة واحدة، بدلاً من إعادة سحبه على فترات منتظمة. + +### شبكات CDN للسحب (Pull CDNs) + +تقوم شبكات CDN للسحب بجلب المحتوى الجديد من خادمك عندما يطلب المستخدم الأول هذا المحتوى. تترك المحتوى على خادمك وتقوم بإعادة كتابة عناوين URL للإشارة إلى CDN. يؤدي هذا إلى طلب أبطأ حتى يتم تخزين المحتوى مؤقتًا على CDN. + +يحدد [وقت الصلاحية (TTL)](https://en.wikipedia.org/wiki/Time_to_live) المدة التي يتم فيها تخزين المحتوى مؤقتًا. تقلل شبكات CDN للسحب من مساحة التخزين على CDN، ولكنها قد تخلق حركة مرور زائدة إذا انتهت صلاحية الملفات وتم سحبها قبل تغييرها فعلياً. + +تعمل المواقع ذات حركة المرور الكثيفة بشكل جيد مع شبكات CDN للسحب، حيث يتم توزيع حركة المرور بشكل أكثر توازناً مع بقاء المحتوى المطلوب مؤخراً فقط على CDN. + +### عيوب CDN + +* قد تكون تكاليف CDN كبيرة اعتماداً على حركة المرور، على الرغم من أنه يجب موازنة ذلك مع التكاليف الإضافية التي قد تتكبدها عند عدم استخدام CDN. +* قد يصبح المحتوى قديماً إذا تم تحديثه قبل انتهاء صلاحية TTL. +* تتطلب شبكات CDN تغيير عناوين URL للمحتوى الثابت للإشارة إلى CDN. + +### المصادر وقراءات إضافية + +* [توصيل المحتوى الموزع عالمياً](https://figshare.com/articles/Globally_distributed_content_delivery/6605972) +* [الفروق بين شبكات CDN للدفع والسحب](http://www.travelblogadvice.com/technical/the-differences-between-push-and-pull-cdns/) +* [ويكيبيديا](https://en.wikipedia.org/wiki/Content_delivery_network) + +## موازن التحميل (Load Balancer) + +

+ +
+ المصدر: أنماط تصميم النظم القابلة للتطوير +

+ +يقوم موازن التحميل بتوزيع طلبات العملاء الواردة على موارد الحوسبة مثل خوادم التطبيقات وقواعد البيانات. في كل حالة، يقوم موازن التحميل بإرجاع الاستجابة من مورد الحوسبة إلى العميل المناسب. موازنات التحميل فعالة في: + +* منع الطلبات من الذهاب إلى الخوادم غير الصحية +* منع التحميل الزائد على الموارد +* المساعدة في القضاء على نقطة الفشل الوحيدة + +يمكن تنفيذ موازنات التحميل باستخدام الأجهزة (مكلفة) أو البرمجيات مثل HAProxy. + +تشمل المزايا الإضافية: + +* **إنهاء SSL** - فك تشفير الطلبات الواردة وتشفير استجابات الخادم بحيث لا تحتاج الخوادم الخلفية إلى تنفيذ هذه العمليات المكلفة محتملاً + * يزيل الحاجة إلى تثبيت [شهادات X.509](https://en.wikipedia.org/wiki/X.509) على كل خادم +* **استمرارية الجلسة** - إصدار ملفات تعريف الارتباط (cookies) وتوجيه طلبات عميل محدد إلى نفس النسخة إذا كانت تطبيقات الويب لا تتتبع الجلسات + +للحماية من الأعطال، من الشائع إعداد موازنات تحميل متعددة، إما في وضع [نشط-سلبي](#active-passive) أو [نشط-نشط](#active-active). + +يمكن لموازنات التحميل توجيه حركة المرور بناءً على مقاييس مختلفة، بما في ذلك: + +* عشوائي +* الأقل تحميلاً +* الجلسات/ملفات تعريف الارتباط +* [التوزيع الدائري أو التوزيع الدائري المرجح](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb) +* [موازنة التحميل في الطبقة 4](#layer-4-load-balancing) +* [موازنة التحميل في الطبقة 7](#layer-7-load-balancing) + +### موازنة التحميل في الطبقة 4 + +تنظر موازنات التحميل في الطبقة 4 إلى المعلومات في [طبقة النقل](#communication) لتقرر كيفية توزيع الطلبات. عموماً، يتضمن هذا عناوين IP المصدر والوجهة والمنافذ في الرأس، ولكن ليس محتويات الحزمة. تقوم موازنات التحميل في الطبقة 4 بإعادة توجيه حزم الشبكة من وإلى الخادم الأعلى، مع تنفيذ [ترجمة عناوين الشبكة (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/). + +### موازنة التحميل في الطبقة 7 + +تنظر موازنات التحميل في الطبقة 7 إلى [طبقة التطبيق](#communication) لتقرر كيفية توزيع الطلبات. يمكن أن يتضمن هذا محتويات الرأس والرسالة وملفات تعريف الارتباط. تقوم موازنات التحميل في الطبقة 7 بإنهاء حركة الشبكة، وقراءة الرسالة، واتخاذ قرار موازنة التحميل، ثم فتح اتصال مع الخادم المحدد. على سبيل المثال، يمكن لموازن التحميل في الطبقة 7 توجيه حركة الفيديو إلى خوادم تستضيف الفيديوهات بينما يوجه حركة فواتير المستخدمين الأكثر حساسية إلى خوادم محصنة أمنياً. + +على حساب المرونة، تتطلب موازنة التحميل في الطبقة 4 وقتاً وموارد حوسبة أقل من الطبقة 7، على الرغم من أن تأثير الأداء يمكن أن يكون ضئيلاً على الأجهزة السلعية الحديثة. + +### التطوير الأفقي + +يمكن أن تساعد موازنات التحميل أيضاً في التطوير الأفقي، مما يحسن الأداء والتوافر. التطوير باستخدام الأجهزة السلعية أكثر فعالية من حيث التكلفة ويؤدي إلى توافر أعلى من تطوير خادم واحد على أجهزة أكثر تكلفة، وهو ما يسمى **التطوير الرأسي**. كما أنه من الأسهل توظيف المواهب التي تعمل على الأجهزة السلعية مقارنة بأنظمة المؤسسات المتخصصة. + +#### عيوب التطوير الأفقي + +* يقدم التطوير الأفقي تعقيداً ويتضمن استنساخ الخوادم + * يجب أن تكون الخوادم بدون حالة: يجب ألا تحتوي على أي بيانات متعلقة بالمستخدم مثل الجلسات أو صور الملف الشخصي + * يمكن تخزين الجلسات في مخزن بيانات مركزي مثل [قاعدة البيانات](#database) (SQL، NoSQL) أو [ذاكرة التخزين المؤقت](#cache) المستمرة (Redis، Memcached) +* تحتاج الخوادم السفلية مثل ذاكرة التخزين المؤقت وقواعد البيانات إلى التعامل مع المزيد من الاتصالات المتزامنة مع توسع الخوادم العلوية + +### عيوب موازن التحميل + +* يمكن أن يصبح موازن التحميل نقطة اختناق في الأداء إذا لم يكن لديه موارد كافية أو إذا لم يتم تكوينه بشكل صحيح. +* يؤدي إدخال موازن تحميل للمساعدة في القضاء على نقطة الفشل الوحيدة إلى زيادة التعقيد. +* موازن التحميل الواحد هو نقطة فشل وحيدة، وتكوين موازنات تحميل متعددة يزيد من التعقيد. + +### المصادر وقراءات إضافية + +* [بنية NGINX](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/) +* [دليل بنية HAProxy](http://www.haproxy.org/download/1.2/doc/architecture.txt) +* [قابلية التطوير](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones) +* [ويكيبيديا](https://en.wikipedia.org/wiki/Load_balancing_(computing)) +* [موازنة التحميل في الطبقة 4](https://www.nginx.com/resources/glossary/layer-4-load-balancing/) +* [موازنة التحميل في الطبقة 7](https://www.nginx.com/resources/glossary/layer-7-load-balancing/) +* [تكوين مستمع ELB](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html) + +## الوكيل العكسي (خادم الويب) + +

+ +
+ المصدر: ويكيبيديا +
+

+ +الوكيل العكسي هو خادم ويب يقوم بمركزة الخدمات الداخلية وتوفير واجهات موحدة للجمهور. يتم توجيه الطلبات من العملاء إلى خادم يمكنه تلبيتها قبل أن يقوم الوكيل العكسي بإرجاع استجابة الخادم إلى العميل. + +تشمل المزايا الإضافية: + +* **تحسين الأمان** - إخفاء معلومات عن الخوادم الخلفية، حظر عناوين IP، تحديد عدد الاتصالات لكل عميل +* **زيادة قابلية التطوير والمرونة** - يرى العملاء فقط عنوان IP للوكيل العكسي، مما يتيح لك تطوير الخوادم أو تغيير إعداداتها +* **إنهاء SSL** - فك تشفير الطلبات الواردة وتشفير استجابات الخادم بحيث لا تحتاج الخوادم الخلفية إلى تنفيذ هذه العمليات المكلفة محتملاً + * يزيل الحاجة إلى تثبيت [شهادات X.509](https://en.wikipedia.org/wiki/X.509) على كل خادم +* **الضغط** - ضغط استجابات الخادم +* **التخزين المؤقت** - إرجاع الاستجابة للطلبات المخزنة مؤقتاً +* **المحتوى الثابت** - تقديم المحتوى الثابت مباشرة + * HTML/CSS/JS + * الصور + * الفيديوهات + * إلخ + +### موازن التحميل مقابل الوكيل العكسي + +* يكون نشر موازن التحميل مفيداً عندما يكون لديك خوادم متعددة. غالباً ما يوجه موازن التحميل حركة المرور إلى مجموعة من الخوادم التي تؤدي نفس الوظيفة. +* يمكن أن يكون الوكيل العكسي مفيداً حتى مع خادم ويب واحد أو خادم تطبيق واحد، مما يتيح المزايا الموضحة في القسم السابق. +* يمكن للحلول مثل NGINX وHAProxy دعم كل من الوكيل العكسي في الطبقة 7 وموازنة التحميل. + +### عيوب الوكيل العكسي + +* إدخال وكيل عكسي يؤدي إلى زيادة التعقيد. +* الوكيل العكسي الواحد هو نقطة فشل وحيدة، وتكوين وكلاء عكسيين متعددين (مثل [التجاوز عند الفشل](https://en.wikipedia.org/wiki/Failover)) يزيد من التعقيد. + +### المصادر وقراءات إضافية + +* [الوكيل العكسي مقابل موازن التحميل](https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/) +* [بنية NGINX](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/) +* [دليل بنية HAProxy](http://www.haproxy.org/download/1.2/doc/architecture.txt) +* [ويكيبيديا](https://en.wikipedia.org/wiki/Reverse_proxy) + +## طبقة التطبيق + +

+ +
+ المصدر: مقدمة في تصميم الأنظمة للتطوير +

+ +فصل طبقة الويب عن طبقة التطبيق (المعروفة أيضاً باسم طبقة المنصة) يتيح لك تطوير وتكوين كلا الطبقتين بشكل مستقل. إضافة API جديد يؤدي إلى إضافة خوادم تطبيق دون الحاجة بالضرورة إلى إضافة خوادم ويب إضافية. يدعم **مبدأ المسؤولية الواحدة** الخدمات الصغيرة والمستقلة التي تعمل معاً. يمكن للفرق الصغيرة مع الخدمات الصغيرة التخطيط بشكل أكثر فعالية للنمو السريع. + +العاملون في طبقة التطبيق يساعدون أيضاً في تمكين [اللاتزامن](#asynchronism). + +### الخدمات المصغرة (Microservices) + +ترتبط بهذا النقاش [الخدمات المصغرة](https://en.wikipedia.org/wiki/Microservices)، والتي يمكن وصفها كمجموعة من الخدمات المستقلة القابلة للنشر، الصغيرة والمعيارية. تعمل كل خدمة كعملية فريدة وتتواصل من خلال آلية خفيفة محددة جيداً لخدمة هدف تجاري. 1 + +على سبيل المثال، يمكن أن يكون لدى Pinterest الخدمات المصغرة التالية: ملف المستخدم، المتابعين، التغذية، البحث، رفع الصور، وغيرها. + +### اكتشاف الخدمة (Service Discovery) + +يمكن لأنظمة مثل [Consul](https://www.consul.io/docs/index.html) و[Etcd](https://coreos.com/etcd/docs/latest) و[Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) مساعدة الخدمات في العثور على بعضها البعض من خلال تتبع الأسماء والعناوين والمنافذ المسجلة. تساعد [فحوصات الصحة](https://www.consul.io/intro/getting-started/checks.html) في التحقق من سلامة الخدمة وغالباً ما تتم باستخدام نقطة نهاية [HTTP](#hypertext-transfer-protocol-http). يحتوي كل من Consul وEtcd على [مخزن للقيم المفتاحية](#key-value-store) مدمج يمكن أن يكون مفيداً لتخزين قيم التكوين والبيانات المشتركة الأخرى. + +### عيوب طبقة التطبيق + +* إضافة طبقة تطبيق مع خدمات مقترنة بشكل فضفاض يتطلب نهجاً مختلفاً من وجهة نظر معمارية وتشغيلية وعملية (مقارنة بالنظام المتكامل). +* يمكن أن تضيف الخدمات المصغرة تعقيداً من حيث النشر والعمليات. + +### المصادر وقراءات إضافية + +* [مقدمة في تصميم الأنظمة للتطوير](http://lethain.com/introduction-to-architecting-systems-for-scale) +* [حل مقابلة تصميم النظام](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) +* [البنية الموجهة للخدمات](https://en.wikipedia.org/wiki/Service-oriented_architecture) +* [مقدمة إلى Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) +* [إليك ما تحتاج معرفته حول بناء الخدمات المصغرة](https://cloudncode.wordpress.com/2016/07/22/msa-getting-started/) + +## قاعدة البيانات (Database) + +

+ +
+ المصدر: التطوير حتى 10 ملايين مستخدم +

+ +### نظام إدارة قواعد البيانات العلائقية (RDBMS) + +قاعدة البيانات العلائقية مثل SQL هي مجموعة من عناصر البيانات المنظمة في جداول. + +**ACID** هي مجموعة من خصائص [المعاملات](https://en.wikipedia.org/wiki/Database_transaction) في قواعد البيانات العلائقية. + +* **الذرية (Atomicity)** - كل معاملة إما تتم بالكامل أو لا تتم مطلقاً +* **الاتساق (Consistency)** - أي معاملة ستنقل قاعدة البيانات من حالة صحيحة إلى أخرى +* **العزل (Isolation)** - تنفيذ المعاملات بالتوازي يؤدي إلى نفس النتائج كما لو تم تنفيذها بشكل متسلسل +* **الديمومة (Durability)** - بمجرد إتمام المعاملة، ستظل كذلك + +هناك العديد من التقنيات لتطوير قاعدة بيانات علائقية: **النسخ المتماثل رئيسي-تابع**، **النسخ المتماثل رئيسي-رئيسي**، **الفيدرالية**، **التجزئة**، **إلغاء التطبيع**، و**تحسين SQL**. + +#### النسخ المتماثل رئيسي-تابع (Master-slave replication) + +يخدم الرئيسي عمليات القراءة والكتابة، مع نسخ عمليات الكتابة إلى تابع واحد أو أكثر، والتي تخدم القراءة فقط. يمكن للتوابع أيضاً النسخ إلى توابع إضافية في شكل شجري. إذا توقف الرئيسي عن العمل، يمكن للنظام الاستمرار في العمل في وضع القراءة فقط حتى يتم ترقية تابع ليصبح رئيسياً أو يتم توفير رئيسي جديد. + +

+ +
+ المصدر: أنماط قابلية التطوير والتوافر والاستقرار +

+ +##### عيوب النسخ المتماثل رئيسي-تابع + +* هناك حاجة إلى منطق إضافي لترقية تابع إلى رئيسي. +* انظر [عيوب: النسخ المتماثل](#disadvantages-replication) للنقاط المتعلقة **بكل من** النسخ المتماثل رئيسي-تابع ورئيسي-رئيسي. + +#### النسخ المتماثل رئيسي-رئيسي (Master-master replication) + +كلا الرئيسيين يخدمان القراءة والكتابة وينسقان مع بعضهما البعض في عمليات الكتابة. إذا توقف أي من الرئيسيين عن العمل، يمكن للنظام الاستمرار في العمل مع كل من القراءة والكتابة. + +

+ +
+ المصدر: أنماط قابلية التطوير والتوافر والاستقرار +

+ +##### عيوب النسخ المتماثل رئيسي-رئيسي + +* ستحتاج إلى موازن تحميل أو ستحتاج إلى إجراء تغييرات في منطق تطبيقك لتحديد مكان الكتابة. +* معظم أنظمة رئيسي-رئيسي إما متسقة بشكل فضفاض (مخالفة لـ ACID) أو لديها زمن استجابة متزايد للكتابة بسبب المزامنة. +* يزداد حل التعارض أهمية مع إضافة المزيد من نقاط الكتابة ومع زيادة زمن الاستجابة. +* انظر [عيوب: النسخ المتماثل](#disadvantages-replication) للنقاط المتعلقة **بكل من** النسخ المتماثل رئيسي-تابع ورئيسي-رئيسي. + +##### عيوب النسخ المتماثل + +* هناك احتمال لفقدان البيانات إذا فشل الرئيسي قبل نسخ أي بيانات جديدة مكتوبة إلى العقد الأخرى. +* يتم إعادة تشغيل عمليات الكتابة على نسخ القراءة. إذا كان هناك الكثير من عمليات الكتابة، يمكن أن تتعثر نسخ القراءة في إعادة تشغيل عمليات الكتابة ولا يمكنها إجراء الكثير من عمليات القراءة. +* كلما زاد عدد توابع القراءة، كلما زاد ما يجب نسخه، مما يؤدي إلى تأخير أكبر في النسخ. +* في بعض الأنظمة، يمكن للكتابة إلى الرئيسي إنشاء مسارات متعددة للكتابة بالتوازي، في حين أن نسخ القراءة تدعم فقط الكتابة بشكل متسلسل مع مسار واحد. +* النسخ المتماثل يضيف المزيد من العتاد والتعقيد. + +##### المصادر وقراءات إضافية: النسخ المتماثل + +* [أنماط قابلية التطوير والتوافر والاستقرار](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/) +* [النسخ المتماثل رئيسي-رئيسي](https://en.wikipedia.org/wiki/Multi-master_replication) + +#### الفيدرالية (Federation) + +

+ +
+ المصدر: التطوير حتى 10 ملايين مستخدم +

+ +الفيدرالية (أو التقسيم الوظيفي) تقسم قواعد البيانات حسب الوظيفة. على سبيل المثال، بدلاً من قاعدة بيانات واحدة متكاملة، يمكن أن يكون لديك ثلاث قواعد بيانات: **المنتديات**، **المستخدمين**، و**المنتجات**، مما يؤدي إلى تقليل حركة القراءة والكتابة لكل قاعدة بيانات وبالتالي تقليل تأخير النسخ. قواعد البيانات الأصغر تؤدي إلى المزيد من البيانات التي يمكن أن تتناسب في الذاكرة، مما يؤدي بدوره إلى المزيد من نجاحات التخزين المؤقت بسبب تحسين موقعية التخزين المؤقت. مع عدم وجود رئيسي مركزي واحد لتسلسل عمليات الكتابة، يمكنك الكتابة بالتوازي، مما يزيد من الإنتاجية. + +##### عيوب الفيدرالية + +* الفيدرالية ليست فعالة إذا كان مخططك يتطلب وظائف أو جداول ضخمة. +* ستحتاج إلى تحديث منطق تطبيقك لتحديد قاعدة البيانات التي يجب القراءة منها والكتابة إليها. +* دمج البيانات من قاعدتي بيانات أكثر تعقيداً مع [رابط الخادم](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers). +* الفيدرالية تضيف المزيد من العتاد والتعقيد الإضافي. + +##### المصادر وقراءات إضافية: الفيدرالية + +* [التطوير حتى 10 ملايين مستخدم الأوائل](https://www.youtube.com/watch?v=kKjm4ehYiMs) + +#### التجزئة (Sharding) + +

+ +
+ المصدر: أنماط قابلية التطوير والتوافر والاستقرار +

+ +التجزئة توزع البيانات عبر قواعد بيانات مختلفة بحيث يمكن لكل قاعدة بيانات إدارة جزء فرعي فقط من البيانات. باستخدام قاعدة بيانات المستخدمين كمثال، مع زيادة عدد المستخدمين، تتم إضافة المزيد من الأجزاء إلى المجموعة. + +مشابهة لمزايا [الفيدرالية](#federation)، تؤدي التجزئة إلى تقليل حركة القراءة والكتابة، وتقليل النسخ المتماثل، وزيادة نجاحات التخزين المؤقت. يتم أيضاً تقليل حجم الفهرس، مما يحسن الأداء عموماً مع استعلامات أسرع. إذا تعطل جزء واحد، تظل الأجزاء الأخرى تعمل، على الرغم من أنك ستحتاج إلى إضافة شكل من أشكال النسخ المتماثل لتجنب فقدان البيانات. مثل الفيدرالية، لا يوجد رئيسي مركزي واحد لتسلسل عمليات الكتابة، مما يتيح لك الكتابة بالتوازي مع زيادة الإنتاجية. + +الطرق الشائعة لتجزئة جدول المستخدمين إما من خلال الحرف الأول من اسم المستخدم الأخير أو الموقع الجغرافي للمستخدم. + +##### عيوب التجزئة + +* ستحتاج إلى تحديث منطق تطبيقك للعمل مع الأجزاء، مما قد يؤدي إلى استعلامات SQL معقدة. +* يمكن أن يصبح توزيع البيانات غير متوازن في جزء معين. على سبيل المثال، قد تؤدي مجموعة من المستخدمين النشطين في جزء واحد إلى زيادة الحمل على ذلك الجزء مقارنة بالآخرين. + * إعادة التوازن تضيف تعقيداً إضافياً. يمكن لدالة التجزئة المبنية على [التجزئة المتناسقة](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html) تقليل كمية البيانات المنقولة. +* ربط البيانات من أجزاء متعددة أكثر تعقيداً. +* التجزئة تضيف المزيد من العتاد والتعقيد الإضافي. + +##### المصادر وقراءات إضافية: التجزئة + +* [قدوم التجزئة](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html) +* [بنية قاعدة بيانات التجزئة](https://en.wikipedia.org/wiki/Shard_(database_architecture)) +* [التجزئة المتناسقة](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html) + +#### إلغاء التطبيع (Denormalization) + +إلغاء التطبيع يحاول تحسين أداء القراءة على حساب بعض أداء الكتابة. يتم كتابة نسخ متكررة من البيانات في جداول متعددة لتجنب عمليات الربط المكلفة. بعض أنظمة RDBMS مثل [PostgreSQL](https://en.wikipedia.org/wiki/PostgreSQL) و Oracle تدعم [العروض المادية](https://en.wikipedia.org/wiki/Materialized_view) التي تتعامل مع عمل تخزين المعلومات المتكررة والحفاظ على اتساق النسخ المتكررة. + +بمجرد أن تصبح البيانات موزعة باستخدام تقنيات مثل [الفيدرالية](#federation) و[التجزئة](#sharding)، تزداد تعقيدات إدارة عمليات الربط عبر مراكز البيانات. قد يتجنب إلغاء التطبيع الحاجة إلى مثل هذه العمليات المعقدة للربط. + +في معظم الأنظمة، يمكن أن تفوق عمليات القراءة عمليات الكتابة بنسبة 100:1 أو حتى 1000:1. القراءة التي تؤدي إلى عملية ربط معقدة في قاعدة البيانات يمكن أن تكون مكلفة للغاية، وتقضي وقتاً كبيراً في عمليات القرص. + +##### عيوب إلغاء التطبيع + +* البيانات مكررة. +* القيود يمكن أن تساعد النسخ المتكررة من المعلومات على البقاء متزامنة، مما يزيد من تعقيد تصميم قاعدة البيانات. +* قاعدة البيانات غير المطبعة تحت حمل كتابة كثيف قد تؤدي أداءً أسوأ من نظيرتها المطبعة. + +##### المصادر وقراءات إضافية: إلغاء التطبيع + +* [إلغاء التطبيع](https://en.wikipedia.org/wiki/Denormalization) + +#### تحسين SQL + +تحسين SQL هو موضوع واسع وقد كُتبت العديد من [الكتب](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning) كمرجع. + +من المهم إجراء **اختبارات الأداء** و**التنميط** لمحاكاة واكتشاف نقاط الاختناق. + +* **اختبارات الأداء** - محاكاة حالات الحمل العالي باستخدام أدوات مثل [ab](http://httpd.apache.org/docs/2.2/programs/ab.html). +* **التنميط** - تمكين أدوات مثل [سجل الاستعلامات البطيئة](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) للمساعدة في تتبع مشاكل الأداء. + +قد تشير اختبارات الأداء والتنميط إلى التحسينات التالية. +##### تحسين المخطط + +* يقوم MySQL بتفريغ البيانات على القرص في كتل متجاورة للوصول السريع. +* استخدم `CHAR` بدلاً من `VARCHAR` للحقول ذات الطول الثابت. + * يتيح `CHAR` الوصول العشوائي السريع بشكل فعال، بينما مع `VARCHAR`، يجب عليك العثور على نهاية السلسلة قبل الانتقال إلى التالية. +* استخدم `TEXT` للكتل النصية الكبيرة مثل منشورات المدونة. يسمح `TEXT` أيضاً بعمليات البحث المنطقي. يؤدي استخدام حقل `TEXT` إلى تخزين مؤشر على القرص يُستخدم لتحديد موقع كتلة النص. +* استخدم `INT` للأرقام الكبيرة حتى 2^32 أو 4 مليار. +* استخدم `DECIMAL` للعملات لتجنب أخطاء تمثيل الفاصلة العائمة. +* تجنب تخزين `BLOBS` الكبيرة، وقم بتخزين موقع الحصول على الكائن بدلاً من ذلك. +* `VARCHAR(255)` هو أكبر عدد من الأحرف التي يمكن عدها في رقم 8 بت، مما يؤدي غالباً إلى تعظيم استخدام البايت في بعض أنظمة RDBMS. +* قم بتعيين قيد `NOT NULL` حيثما أمكن [لتحسين أداء البحث](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search). + +##### استخدام الفهارس الجيدة + +* الأعمدة التي تقوم بالاستعلام عنها (`SELECT`, `GROUP BY`, `ORDER BY`, `JOIN`) يمكن أن تكون أسرع باستخدام الفهارس. +* عادةً ما يتم تمثيل الفهارس كشجرة [B-tree](https://en.wikipedia.org/wiki/B-tree) ذاتية التوازن تحافظ على ترتيب البيانات وتسمح بعمليات البحث والوصول التسلسلي والإدراج والحذف في وقت لوغاريتمي. +* وضع فهرس يمكن أن يحتفظ بالبيانات في الذاكرة، مما يتطلب مساحة أكبر. +* يمكن أن تكون عمليات الكتابة أبطأ أيضاً لأن الفهرس يحتاج إلى التحديث. +* عند تحميل كميات كبيرة من البيانات، قد يكون من الأسرع تعطيل الفهارس، وتحميل البيانات، ثم إعادة بناء الفهارس. + +##### تجنب عمليات الربط المكلفة + +* قم بـ [إلغاء التطبيع](#denormalization) حيث تتطلب متطلبات الأداء ذلك. + +##### تجزئة الجداول + +* قم بتقسيم الجدول عن طريق وضع النقاط الساخنة في جدول منفصل للمساعدة في إبقائها في الذاكرة. + +##### تحسين ذاكرة التخزين المؤقت للاستعلامات + +* في بعض الحالات، قد تؤدي [ذاكرة التخزين المؤقت للاستعلامات](https://dev.mysql.com/doc/refman/5.7/en/query-cache.html) إلى [مشاكل في الأداء](https://www.percona.com/blog/2016/10/12/mysql-5-7-performance-tuning-immediately-after-installation/). + +##### المصادر وقراءات إضافية: تحسين SQL + +* [نصائح لتحسين استعلامات MySQL](http://aiddroid.com/10-tips-optimizing-mysql-queries-dont-suck/) +* [هل هناك سبب وجيه لرؤية VARCHAR(255) مستخدمة بكثرة؟](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l) +* [كيف تؤثر القيم الفارغة على الأداء؟](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search) +* [سجل الاستعلامات البطيئة](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) + +### NoSQL + +NoSQL هي مجموعة من عناصر البيانات ممثلة في **مخزن المفتاح-القيمة**، **مخزن المستندات**، **مخزن الأعمدة العريضة**، أو **قاعدة بيانات الرسوم البيانية**. البيانات غير مطبعة، وعمليات الربط تتم عموماً في كود التطبيق. معظم مخازن NoSQL تفتقر إلى معاملات ACID الحقيقية وتفضل [الاتساق النهائي](#eventual-consistency). + +غالباً ما يستخدم **BASE** لوصف خصائص قواعد بيانات NoSQL. بالمقارنة مع [نظرية CAP](#cap-theorem)، يختار BASE التوافر على حساب الاتساق. + +* **متوفر أساساً** - يضمن النظام التوافر. +* **حالة مرنة** - قد تتغير حالة النظام مع مرور الوقت، حتى بدون مدخلات. +* **اتساق نهائي** - سيصبح النظام متسقاً خلال فترة من الزمن، بشرط عدم تلقي النظام مدخلات خلال تلك الفترة. + +بالإضافة إلى الاختيار بين [SQL أو NoSQL](#sql-or-nosql)، من المفيد فهم أي نوع من قواعد بيانات NoSQL يناسب حالة (حالات) الاستخدام الخاصة بك بشكل أفضل. سنراجع **مخازن المفتاح-القيمة**، **مخازن المستندات**، **مخازن الأعمدة العريضة**، و**قواعد بيانات الرسوم البيانية** في القسم التالي. + +#### مخزن المفتاح-القيمة + +> التجريد: جدول التجزئة + +مخزن المفتاح-القيمة يسمح عموماً بعمليات قراءة وكتابة بتعقيد O(1) وغالباً ما يكون مدعوماً بالذاكرة أو SSD. يمكن لمخازن البيانات الحفاظ على المفاتيح في [ترتيب معجمي](https://en.wikipedia.org/wiki/Lexicographical_order)، مما يسمح باسترجاع نطاقات المفاتيح بكفاءة. مخازن المفتاح-القيمة يمكن أن تسمح بتخزين البيانات الوصفية مع القيمة. + +توفر مخازن المفتاح-القيمة أداءً عالياً وغالباً ما تستخدم لنماذج البيانات البسيطة أو للبيانات سريعة التغير، مثل طبقة التخزين المؤقت في الذاكرة. نظراً لأنها تقدم مجموعة محدودة من العمليات، يتم نقل التعقيد إلى طبقة التطبيق إذا كانت هناك حاجة لعمليات إضافية. + +مخزن المفتاح-القيمة هو الأساس لأنظمة أكثر تعقيداً مثل مخزن المستندات، وفي بعض الحالات، قاعدة بيانات الرسوم البيانية. +##### المصادر وقراءات إضافية: مخزن المفتاح-القيمة + +* [قاعدة بيانات المفتاح-القيمة](https://en.wikipedia.org/wiki/Key-value_database) +* [عيوب مخازن المفتاح-القيمة](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or) +* [بنية Redis](http://qnimate.com/overview-of-redis-architecture/) +* [بنية Memcached](https://adayinthelifeof.nl/2011/02/06/memcache-internals/) + +#### مخزن المستندات + +> التجريد: مخزن مفتاح-قيمة مع تخزين المستندات كقيم + +يتمحور مخزن المستندات حول المستندات (XML، JSON، ثنائي، إلخ)، حيث يخزن المستند جميع المعلومات لكائن معين. توفر مخازن المستندات واجهات برمجة التطبيقات (APIs) أو لغة استعلام للبحث بناءً على البنية الداخلية للمستند نفسه. *ملاحظة: العديد من مخازن المفتاح-القيمة تتضمن ميزات للعمل مع البيانات الوصفية للقيمة، مما يجعل الحدود غير واضحة بين هذين النوعين من التخزين.* + +بناءً على التنفيذ الأساسي، يتم تنظيم المستندات حسب المجموعات، العلامات، البيانات الوصفية، أو المجلدات. على الرغم من أنه يمكن تنظيم المستندات أو تجميعها معاً، قد تحتوي المستندات على حقول مختلفة تماماً عن بعضها البعض. + +بعض مخازن المستندات مثل [MongoDB](https://www.mongodb.com/mongodb-architecture) و[CouchDB](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/) توفر أيضاً لغة شبيهة بـ SQL لتنفيذ استعلامات معقدة. [DynamoDB](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) يدعم كلاً من المفتاح-القيمة والمستندات. + +توفر مخازن المستندات مرونة عالية وغالباً ما تستخدم للعمل مع البيانات التي تتغير بشكل متقطع. + +##### المصادر وقراءات إضافية: مخزن المستندات + +* [قاعدة البيانات الموجهة للمستندات](https://en.wikipedia.org/wiki/Document-oriented_database) +* [بنية MongoDB](https://www.mongodb.com/mongodb-architecture) +* [بنية CouchDB](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/) +* [بنية Elasticsearch](https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up) + +#### مخزن الأعمدة العريضة + +

+ +
+ المصدر: SQL & NoSQL، تاريخ موجز +

+ +> التجريد: خريطة متداخلة `ColumnFamily>` + +الوحدة الأساسية للبيانات في مخزن الأعمدة العريضة هي العمود (زوج اسم/قيمة). يمكن تجميع العمود في عائلات الأعمدة (مماثلة لجدول SQL). عائلات الأعمدة الفائقة تجمع عائلات الأعمدة بشكل أكبر. يمكنك الوصول إلى كل عمود بشكل مستقل باستخدام مفتاح الصف، والأعمدة ذات نفس مفتاح الصف تشكل صفاً. تحتوي كل قيمة على طابع زمني للإصدار وحل التعارضات. + +قدمت Google [Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) كأول مخزن للأعمدة العريضة، والذي أثر على [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، تاريخ موجز](http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html) +* [بنية Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) +* [بنية HBase](https://www.edureka.co/blog/hbase-architecture/) +* [بنية Cassandra](http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archIntro.html) + +#### قاعدة بيانات الرسوم البيانية + +

+ +
+ المصدر: قاعدة بيانات الرسوم البيانية +

+ +> التجريد: رسم بياني + +في قاعدة بيانات الرسوم البيانية، كل عقدة هي سجل وكل قوس هو علاقة بين عقدتين. قواعد بيانات الرسوم البيانية مُحسّنة لتمثيل العلاقات المعقدة مع العديد من المفاتيح الخارجية أو علاقات متعددة-إلى-متعددة. + +توفر قواعد بيانات الرسوم البيانية أداءً عالياً لنماذج البيانات ذات العلاقات المعقدة، مثل الشبكات الاجتماعية. وهي حديثة نسبياً ولم تنتشر بعد على نطاق واسع؛ قد يكون من الصعب العثور على أدوات وموارد تطوير. العديد من الرسوم البيانية لا يمكن الوصول إليها إلا من خلال [REST APIs](#representational-state-transfer-rest). + +##### المصادر وقراءات إضافية: الرسوم البيانية + +* [قاعدة بيانات الرسوم البيانية](https://en.wikipedia.org/wiki/Graph_database) +* [Neo4j](https://neo4j.com/) +* [FlockDB](https://blog.twitter.com/2010/introducing-flockdb) + +#### المصادر وقراءات إضافية: NoSQL + +* [شرح المصطلحات الأساسية](http://stackoverflow.com/questions/3342497/explanation-of-base-terminology) +* [قواعد بيانات NoSQL: مسح وتوجيه القرار](https://medium.com/baqend-blog/nosql-databases-a-survey-and-decision-guidance-ea7823a822d#.wskogqenq) +* [قابلية التوسع](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database) +* [مقدمة إلى NoSQL](https://www.youtube.com/watch?v=qI_g07C_Q5I) +* [أنماط NoSQL](http://horicky.blogspot.com/2009/11/nosql-patterns.html) + +### SQL أم NoSQL + +

+ +
+ المصدر: الانتقال من RDBMS إلى NoSQL +

+ +أسباب اختيار **SQL**: + +* البيانات المنظمة +* المخطط الصارم +* البيانات العلائقية +* الحاجة إلى عمليات ربط معقدة +* المعاملات +* أنماط واضحة للتوسع +* أكثر نضجاً: المطورون، المجتمع، الكود، الأدوات، إلخ +* عمليات البحث باستخدام الفهرس سريعة جداً + +أسباب اختيار **NoSQL**: + +* البيانات شبه المنظمة +* المخطط الديناميكي أو المرن +* البيانات غير العلائقية +* لا حاجة لعمليات ربط معقدة +* تخزين العديد من التيرابايت (أو البيتابايت) من البيانات +* حمل كثيف جداً للبيانات +* معدل إنتاجية عالٍ جداً للعمليات في الثانية + +أمثلة على البيانات المناسبة لـ NoSQL: + +* الاستيعاب السريع لبيانات تدفق النقرات والسجلات +* بيانات لوحة المتصدرين أو النقاط +* البيانات المؤقتة، مثل سلة التسوق +* الجداول التي يتم الوصول إليها بشكل متكرر ('الساخنة') +* جداول البيانات الوصفية/البحث + +##### المصادر وقراءات إضافية: SQL أم NoSQL + +* [التوسع حتى أول 10 ملايين مستخدم](https://www.youtube.com/watch?v=kKjm4ehYiMs) +* [الفروق بين SQL و NoSQL](https://www.sitepoint.com/sql-vs-nosql-differences/) + +## التخزين المؤقت + +

+ +
+ المصدر: أنماط تصميم النظام القابل للتوسع +

+ +يحسن التخزين المؤقت أوقات تحميل الصفحات ويمكن أن يقلل الحمل على خوادمك وقواعد البيانات. في هذا النموذج، سيقوم الموزع أولاً بالبحث عما إذا كان الطلب قد تم من قبل ومحاولة العثور على النتيجة السابقة لإرجاعها، لتوفير التنفيذ الفعلي. + +غالباً ما تستفيد قواعد البيانات من التوزيع المتساوي للقراءات والكتابات عبر أقسامها. العناصر الشائعة يمكن أن تؤدي إلى انحراف التوزيع، مما يسبب اختناقات. وضع ذاكرة تخزين مؤقت أمام قاعدة البيانات يمكن أن يساعد في امتصاص الأحمال غير المتساوية وارتفاعات حركة المرور. + +### التخزين المؤقت على جانب العميل + +يمكن أن يتواجد التخزين المؤقت على جانب العميل (نظام التشغيل أو المتصفح)، [جانب الخادم](#reverse-proxy-web-server)، أو في طبقة تخزين مؤقت منفصلة. + +### التخزين المؤقت CDN + +تعتبر [CDNs](#content-delivery-network) نوعاً من التخزين المؤقت. + +### التخزين المؤقت لخادم الويب + +يمكن [للوكلاء العكسيين](#reverse-proxy-web-server) والتخزين المؤقت مثل [Varnish](https://www.varnish-cache.org/) تقديم المحتوى الثابت والديناميكي مباشرة. يمكن لخوادم الويب أيضاً تخزين الطلبات مؤقتاً، وإرجاع الردود دون الحاجة للاتصال بخوادم التطبيقات. + +### التخزين المؤقت لقاعدة البيانات + +عادةً ما تتضمن قاعدة البياناتك مستوى معين من التخزين المؤقت في التكوين الافتراضي، مُحسّن لحالة استخدام عامة. تعديل هذه الإعدادات لأنماط استخدام محددة يمكن أن يعزز الأداء بشكل أكبر. +### التخزين المؤقت للتطبيق + +تعتبر أنظمة التخزين المؤقت في الذاكرة مثل Memcached و Redis بمثابة مخازن للقيم المفتاحية بين تطبيقك وتخزين البيانات. نظراً لأن البيانات محفوظة في ذاكرة الوصول العشوائي (RAM)، فهي أسرع بكثير من قواعد البيانات النموذجية حيث يتم تخزين البيانات على القرص. الذاكرة العشوائية محدودة مقارنة بالقرص، لذا يمكن لخوارزميات إبطال التخزين المؤقت [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms) مثل [least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)) المساعدة في إبطال الإدخالات "الباردة" والحفاظ على البيانات "الساخنة" في الذاكرة العشوائية. + +يتميز Redis بالمزايا الإضافية التالية: + +* خيار الاستمرارية +* هياكل بيانات مدمجة مثل المجموعات المرتبة والقوائم + +هناك مستويات متعددة يمكنك تخزينها مؤقتاً تندرج تحت فئتين عامتين: **استعلامات قاعدة البيانات** و **الكائنات**: + +* مستوى الصف +* مستوى الاستعلام +* كائنات قابلة للتسلسل مكتملة التكوين +* HTML مكتمل التقديم + +بشكل عام، يجب أن تحاول تجنب التخزين المؤقت القائم على الملفات، لأنه يجعل الاستنساخ والتوسع التلقائي أكثر صعوبة. + +### التخزين المؤقت على مستوى استعلام قاعدة البيانات + +عندما تستعلم من قاعدة البيانات، قم بتجزئة الاستعلام كمفتاح وتخزين النتيجة في ذاكرة التخزين المؤقت. يعاني هذا النهج من مشاكل انتهاء الصلاحية: + +* صعوبة حذف نتيجة مخزنة مؤقتاً مع الاستعلامات المعقدة +* إذا تغير جزء واحد من البيانات مثل خلية جدول، فأنت بحاجة إلى حذف جميع الاستعلامات المخزنة مؤقتاً التي قد تتضمن الخلية المتغيرة + +### التخزين المؤقت على مستوى الكائن + +انظر إلى بياناتك ككائن، مشابه لما تفعله مع كود تطبيقك. اجعل تطبيقك يجمع مجموعة البيانات من قاعدة البيانات في نسخة من الفئة أو هيكل (هياكل) البيانات: + +* إزالة الكائن من التخزين المؤقت إذا تغيرت بياناته الأساسية +* يسمح بالمعالجة غير المتزامنة: العمال يجمعون الكائنات باستهلاك أحدث كائن مخزن مؤقتاً + +اقتراحات لما يمكن تخزينه مؤقتاً: + +* جلسات المستخدم +* صفحات الويب المقدمة بالكامل +* تدفقات النشاط +* بيانات الرسم البياني للمستخدم + +### متى يتم تحديث التخزين المؤقت + +نظراً لأنه يمكنك تخزين كمية محدودة فقط من البيانات في التخزين المؤقت، ستحتاج إلى تحديد استراتيجية تحديث التخزين المؤقت التي تعمل بشكل أفضل لحالة الاستخدام الخاصة بك. + +#### التخزين المؤقت الجانبي (Cache-aside) + +

+ +
+ المصدر: من التخزين المؤقت إلى شبكة بيانات في الذاكرة +

+ +التطبيق مسؤول عن القراءة والكتابة من التخزين. لا يتفاعل التخزين المؤقت مع التخزين مباشرة. يقوم التطبيق بما يلي: + +* البحث عن الإدخال في التخزين المؤقت، مما يؤدي إلى فشل في العثور عليه +* تحميل الإدخال من قاعدة البيانات +* إضافة الإدخال إلى التخزين المؤقت +* إرجاع الإدخال + +```python +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/) بشكل عام بهذه الطريقة. + +عمليات القراءة اللاحقة للبيانات المضافة إلى التخزين المؤقت تكون سريعة. يشار إلى التخزين المؤقت الجانبي أيضاً باسم التحميل الكسول (lazy loading). يتم تخزين البيانات المطلوبة فقط مؤقتاً، مما يتجنب ملء ذاكرة التخزين المؤقت ببيانات غير مطلوبة. + +##### عيوب التخزين المؤقت الجانبي + +* كل فشل في العثور على البيانات في التخزين المؤقت يؤدي إلى ثلاث رحلات، مما قد يسبب تأخيراً ملحوظاً. +* قد تصبح البيانات قديمة إذا تم تحديثها في قاعدة البيانات. يمكن تخفيف هذه المشكلة عن طريق تعيين وقت انتهاء الصلاحية (TTL) الذي يفرض تحديث إدخال التخزين المؤقت، أو باستخدام الكتابة المباشرة (write-through). +* عند فشل العقدة، يتم استبدالها بعقدة جديدة فارغة، مما يزيد زمن الاستجابة. + +#### الكتابة المباشرة (Write-through) + +

+ +
+ المصدر: أنماط قابلية التوسع والتوافر والاستقرار +

+ +يستخدم التطبيق التخزين المؤقت كمخزن البيانات الرئيسي، حيث يقرأ ويكتب البيانات إليه، بينما يكون التخزين المؤقت مسؤولاً عن القراءة والكتابة في قاعدة البيانات: + +* يضيف/يحدث التطبيق الإدخال في التخزين المؤقت +* يكتب التخزين المؤقت الإدخال بشكل متزامن في مخزن البيانات +* العودة + +كود التطبيق: + +```python +set_user(12345, {"foo":"bar"}) +``` + +كود التخزين المؤقت: + +```python +def set_user(user_id, values): + user = db.query("UPDATE Users WHERE id = {0}", user_id, values) + cache.set(user_id, user) +``` + +تعتبر الكتابة المباشرة عملية بطيئة بشكل عام بسبب عملية الكتابة، لكن عمليات القراءة اللاحقة للبيانات المكتوبة حديثاً تكون سريعة. يميل المستخدمون عموماً إلى تحمل التأخير عند تحديث البيانات أكثر من تحملهم له عند قراءتها. البيانات في التخزين المؤقت لا تكون قديمة. + +##### عيوب الكتابة المباشرة + +* عند إنشاء عقدة جديدة بسبب الفشل أو التوسع، لن تقوم العقدة الجديدة بتخزين الإدخالات مؤقتاً حتى يتم تحديث الإدخال في قاعدة البيانات. يمكن تخفيف هذه المشكلة باستخدام التخزين المؤقت الجانبي مع الكتابة المباشرة. +* معظم البيانات المكتوبة قد لا تتم قراءتها أبداً، ويمكن تقليل هذا باستخدام وقت انتهاء الصلاحية (TTL). + +#### الكتابة المؤجلة (write-back) + +

+ +
+ المصدر: أنماط قابلية التوسع والتوافر والاستقرار +

+ +في الكتابة المؤجلة، يقوم التطبيق بما يلي: + +* إضافة/تحديث الإدخال في التخزين المؤقت +* كتابة الإدخال بشكل غير متزامن في مخزن البيانات، مما يحسن أداء الكتابة + +##### عيوب الكتابة المؤجلة + +* قد يحدث فقدان للبيانات إذا تعطل التخزين المؤقت قبل وصول محتوياته إلى مخزن البيانات. +* تنفيذ الكتابة المؤجلة أكثر تعقيداً من تنفيذ التخزين المؤقت الجانبي أو الكتابة المباشرة. + +#### التحديث المسبق (Refresh-ahead) + +

+ +
+ المصدر: من التخزين المؤقت إلى شبكة البيانات في الذاكرة +

+ +يمكنك تكوين التخزين المؤقت لتحديث أي إدخال تم الوصول إليه مؤخراً تلقائياً قبل انتهاء صلاحيته. + +يمكن أن يؤدي التحديث المسبق إلى تقليل زمن الاستجابة مقارنة بالقراءة المباشرة إذا كان التخزين المؤقت قادراً على التنبؤ بدقة بالعناصر التي من المحتمل أن تكون مطلوبة في المستقبل. + +##### عيوب التحديث المسبق + +* عدم التنبؤ بدقة بالعناصر التي من المحتمل أن تكون مطلوبة في المستقبل قد يؤدي إلى انخفاض الأداء مقارنة بعدم استخدام التحديث المسبق. + +### عيوب التخزين المؤقت + +* الحاجة إلى الحفاظ على التناسق بين التخزين المؤقت ومصدر الحقيقة مثل قاعدة البيانات من خلال [إبطال التخزين المؤقت](https://en.wikipedia.org/wiki/Cache_algorithms). +* إبطال التخزين المؤقت مشكلة صعبة، وهناك تعقيد إضافي مرتبط بتوقيت تحديث التخزين المؤقت. +* الحاجة إلى إجراء تغييرات في التطبيق مثل إضافة Redis أو memcached. + +### المصادر وقراءات إضافية + +* [من التخزين المؤقت إلى شبكة البيانات في الذاكرة](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast) +* [أنماط تصميم النظم القابلة للتوسع](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html) +* [مقدمة في تصميم الأنظمة للتوسع](http://lethain.com/introduction-to-architecting-systems-for-scale/) +* [أنماط قابلية التوسع والتوافر والاستقرار](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/) +* [قابلية التوسع](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache) +* [استراتيجيات AWS ElastiCache](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Strategies.html) +* [ويكيبيديا](https://en.wikipedia.org/wiki/Cache_(computing)) + +## اللاتزامن (Asynchronism) + +

+ +
+ المصدر: مقدمة في تصميم الأنظمة للتوسع +

+ +تساعد سير العمل اللاتزامنية في تقليل أوقات الطلب للعمليات المكلفة التي قد تتم بشكل مباشر. كما يمكن أن تساعد في تنفيذ العمل المستهلك للوقت مسبقاً، مثل التجميع الدوري للبيانات. + +### قوائم الرسائل + +تستقبل قوائم الرسائل وتحتفظ وتسلم الرسائل. إذا كانت العملية بطيئة جداً للتنفيذ المباشر، يمكنك استخدام قائمة رسائل مع سير العمل التالي: + +* ينشر التطبيق مهمة في القائمة، ثم يخطر المستخدم بحالة المهمة +* يلتقط العامل المهمة من القائمة، يعالجها، ثم يشير إلى اكتمال المهمة + +لا يتم حظر المستخدم ويتم معالجة المهمة في الخلفية. خلال هذا الوقت، قد يقوم العميل اختيارياً بمعالجة صغيرة لجعل المهمة تبدو وكأنها اكتملت. على سبيل المثال، عند نشر تغريدة، يمكن نشر التغريدة فوراً في جدولك الزمني، لكن قد يستغرق الأمر بعض الوقت قبل أن يتم تسليم تغريدتك فعلياً لجميع متابعيك. + +يعد **[Redis](https://redis.io/)** مفيداً كوسيط رسائل بسيط ولكن يمكن فقدان الرسائل. + +**[RabbitMQ](https://www.rabbitmq.com/)** شائع ولكنه يتطلب منك التكيف مع بروتوكول 'AMQP' وإدارة العقد الخاصة بك. + +**[Amazon SQS](https://aws.amazon.com/sqs/)** مستضاف ولكن يمكن أن يكون له زمن استجابة عالٍ مع احتمال تسليم الرسائل مرتين. + +### قوائم المهام + +تستقبل قوائم المهام المهام وبياناتها المرتبطة، تنفذها، ثم تسلم نتائجها. يمكنها دعم الجدولة ويمكن استخدامها لتشغيل المهام كثيفة الحساب في الخلفية. + +**[Celery](https://docs.celeryproject.org/en/stable/)** يدعم الجدولة وبشكل أساسي لديه دعم لـ Python. + +### الضغط العكسي + +إذا بدأت القوائم في النمو بشكل كبير، يمكن أن يصبح حجم القائمة أكبر من الذاكرة، مما يؤدي إلى فشل في التخزين المؤقت، وقراءات القرص، وحتى أداء أبطأ. يمكن أن يساعد [الضغط العكسي](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) من خلال تحديد حجم القائمة، وبالتالي الحفاظ على معدل إنتاجية عالٍ وأوقات استجابة جيدة للمهام الموجودة بالفعل في القائمة. بمجرد امتلاء القائمة، يحصل العملاء على رمز حالة مشغول أو HTTP 503 للمحاولة لاحقاً. يمكن للعملاء إعادة المحاولة في وقت لاحق، ربما مع [التراجع الأسي](https://en.wikipedia.org/wiki/Exponential_backoff). + +### عيوب اللاتزامن + +* حالات الاستخدام مثل العمليات الحسابية غير المكلفة وسير العمل في الوقت الفعلي قد تكون أكثر ملاءمة للعمليات المتزامنة، حيث أن إدخال القوائم يمكن أن يضيف تأخيرات وتعقيدات. + +### المصادر وقراءات إضافية + +* [إنها كلها لعبة أرقام](https://www.youtube.com/watch?v=1KRYH75wgy4) +* [تطبيق الضغط العكسي عند التحميل الزائد](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) +* [قانون ليتل](https://en.wikipedia.org/wiki/Little%27s_law) +* [ما هو الفرق بين قائمة الرسائل وقائمة المهام؟](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function) + +## الاتصال + +

+ +
+ المصدر: نموذج OSI ذو الطبقات السبع +

+ +### بروتوكول نقل النص التشعبي (HTTP) + +HTTP هو طريقة لترميز ونقل البيانات بين العميل والخادم. إنه بروتوكول طلب/استجابة: يصدر العملاء طلبات ويصدر الخوادم استجابات مع المحتوى ذي الصلة ومعلومات حالة الإكمال حول الطلب. HTTP مستقل بذاته، مما يسمح للطلبات والاستجابات بالتدفق عبر العديد من أجهزة التوجيه والخوادم الوسيطة التي تقوم بموازنة التحميل والتخزين المؤقت والتشفير والضغط. + +يتكون طلب HTTP الأساسي من فعل (طريقة) ومورد (نقطة نهاية). فيما يلي أفعال HTTP الشائعة: + +| الفعل | الوصف | متكافئ* | آمن | قابل للتخزين المؤقت | +|---|---|---|---|---| +| GET | يقرأ مورداً | نعم | نعم | نعم | +| POST | ينشئ مورداً أو يطلق عملية تتعامل مع البيانات | لا | لا | نعم إذا كانت الاستجابة تحتوي على معلومات الحداثة | +| PUT | ينشئ أو يستبدل مورداً | نعم | لا | لا | +| PATCH | يحدث مورداً جزئياً | لا | لا | نعم إذا كانت الاستجابة تحتوي على معلومات الحداثة | +| DELETE | يحذف مورداً | نعم | لا | لا | + +*يمكن استدعاؤه عدة مرات دون نتائج مختلفة. + +HTTP هو بروتوكول طبقة التطبيق يعتمد على بروتوكولات المستوى الأدنى مثل **TCP** و **UDP**. + +#### المصادر وقراءات إضافية: HTTP + +* [ما هو HTTP؟](https://www.nginx.com/resources/glossary/http/) +* [الفرق بين بروتوكول HTTP وبروتوكول TCP](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol) +* [الفرق بين PUT و PATCH](https://laracasts.com/discuss/channels/general-discussion/whats-the-differences-between-put-and-patch?page=1) + +### بروتوكول التحكم بالإرسال (TCP) + +

+ +
+ المصدر: كيفية صنع لعبة متعددة اللاعبين +

+ +TCP هو بروتوكول موجه للاتصال عبر [شبكة IP](https://en.wikipedia.org/wiki/Internet_Protocol). يتم إنشاء الاتصال وإنهاؤه باستخدام [المصافحة](https://en.wikipedia.org/wiki/Handshaking). جميع الحزم المرسلة مضمونة الوصول إلى الوجهة بالترتيب الأصلي وبدون تلف من خلال: + +* أرقام التسلسل و[حقول المجموع الاختباري](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation) لكل حزمة +* حزم [التأكيد](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)) وإعادة الإرسال التلقائي + +إذا لم يتلق المرسل استجابة صحيحة، سيقوم بإعادة إرسال الحزم. في حالة حدوث مهلات متعددة، يتم إسقاط الاتصال. كما ينفذ TCP [التحكم بالتدفق](https://en.wikipedia.org/wiki/Flow_control_(data)) و[التحكم بالازدحام](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control). تتسبب هذه الضمانات في تأخيرات وتؤدي عموماً إلى نقل أقل كفاءة من UDP. + +لضمان إنتاجية عالية، يمكن لخوادم الويب الاحتفاظ بعدد كبير من اتصالات TCP مفتوحة، مما يؤدي إلى استخدام ذاكرة عالٍ. قد يكون من المكلف وجود عدد كبير من الاتصالات المفتوحة بين مؤشرات خادم الويب وخادم [memcached](https://memcached.org/). يمكن أن يساعد [تجميع الاتصالات](https://en.wikipedia.org/wiki/Connection_pool) بالإضافة إلى التحول إلى UDP حيثما أمكن. + +TCP مفيد للتطبيقات التي تتطلب موثوقية عالية ولكنها أقل حساسية للوقت. تشمل بعض الأمثلة خوادم الويب، ومعلومات قواعد البيانات، وSMTP، وFTP، وSSH. + +استخدم TCP بدلاً من UDP عندما: + +* تحتاج إلى وصول جميع البيانات سليمة +* تريد تقديراً تلقائياً لأفضل استخدام لسعة الشبكة + +### بروتوكول حزم المستخدم (UDP) + +

+ +
+ المصدر: كيفية صنع لعبة متعددة اللاعبين +

+ +UDP لا يعتمد على الاتصال. وحدات البيانات (المماثلة للحزم) مضمونة فقط على مستوى وحدة البيانات. قد تصل وحدات البيانات إلى وجهتها خارج الترتيب أو لا تصل على الإطلاق. لا يدعم UDP التحكم بالازدحام. بدون الضمانات التي يدعمها TCP، يكون UDP عموماً أكثر كفاءة. + +يمكن لـ UDP البث، وإرسال وحدات البيانات إلى جميع الأجهزة في الشبكة الفرعية. هذا مفيد مع [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) لأن العميل لم يتلق بعد عنوان IP، مما يمنع طريقة لـ TCP للتدفق بدون عنوان IP. + +UDP أقل موثوقية ولكنه يعمل بشكل جيد في حالات الاستخدام في الوقت الفعلي مثل VoIP، ودردشة الفيديو، والبث المباشر، والألعاب متعددة اللاعبين في الوقت الفعلي. + +استخدم UDP بدلاً من TCP عندما: + +* تحتاج إلى أقل زمن وصول +* البيانات المتأخرة أسوأ من فقدان البيانات +* تريد تنفيذ تصحيح الأخطاء الخاص بك + +#### المصادر وقراءات إضافية: TCP و UDP + +* [البرمجة الشبكية لمبرمجي الألعاب](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/) +* [الاختلافات الرئيسية بين بروتوكولي TCP و UDP](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/) +* [الفرق بين TCP و UDP](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp) +* [بروتوكول التحكم بالإرسال](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) +* [بروتوكول حزم المستخدم](https://en.wikipedia.org/wiki/User_Datagram_Protocol) +* [تحجيم memcache في Facebook](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf) + +### استدعاء الإجراء عن بعد (RPC) + +

+ +
+ المصدر: حل مقابلة تصميم النظام +

+ +في RPC، يتسبب العميل في تنفيذ إجراء في مساحة عنوان مختلفة، عادةً على خادم بعيد. تتم برمجة الإجراء كما لو كان استدعاء إجراء محلي، مع تجريد تفاصيل كيفية التواصل مع الخادم من برنامج العميل. المكالمات البعيدة عادةً أبطأ وأقل موثوقية من المكالمات المحلية لذلك من المفيد التمييز بين مكالمات RPC والمكالمات المحلية. تشمل أطر عمل RPC الشائعة [Protobuf](https://developers.google.com/protocol-buffers/) و[Thrift](https://thrift.apache.org/) و[Avro](https://avro.apache.org/docs/current/). + +RPC هو بروتوكول طلب-استجابة: +* **برنامج العميل (Client program)** - يستدعي إجراء stub العميل. يتم دفع المعاملات إلى المكدس كما في استدعاء الإجراء المحلي. +* **إجراء stub العميل (Client stub procedure)** - يقوم بتنظيم (تعبئة) معرف الإجراء والوسائط في رسالة طلب. +* **وحدة اتصال العميل (Client communication module)** - يقوم نظام التشغيل بإرسال الرسالة من العميل إلى الخادم. +* **وحدة اتصال الخادم (Server communication module)** - يمرر نظام التشغيل الحزم الواردة إلى إجراء stub الخادم. +* **إجراء stub الخادم (Server stub procedure)** - يفك تنظيم النتائج، ويستدعي إجراء الخادم المطابق لمعرف الإجراء ويمرر الوسائط المعطاة. +* استجابة الخادم تكرر الخطوات أعلاه بترتيب عكسي. + +أمثلة على استدعاءات RPC: + +``` +GET /someoperation?data=anId + +POST /anotheroperation +{ + "data":"anId"; + "anotherdata": "another value" +} +``` + +يركز RPC على كشف السلوكيات. غالباً ما يتم استخدام RPCs لأسباب تتعلق بالأداء مع الاتصالات الداخلية، حيث يمكنك صياغة الاستدعاءات الأصلية يدوياً لتناسب حالات الاستخدام الخاصة بك بشكل أفضل. + +اختر مكتبة أصلية (المعروفة أيضاً باسم SDK) عندما: + +* تعرف منصتك المستهدفة. +* تريد التحكم في كيفية الوصول إلى "المنطق" الخاص بك. +* تريد التحكم في كيفية حدوث التحكم في الأخطاء خارج مكتبتك. +* يكون الأداء وتجربة المستخدم النهائي هو اهتمامك الرئيسي. + +تميل واجهات برمجة التطبيقات HTTP التي تتبع **REST** إلى استخدامها بشكل أكثر تكراراً للواجهات العامة. + +#### عيوب RPC + +* عملاء RPC يصبحون مرتبطين بشكل وثيق بتنفيذ الخدمة. +* يجب تحديد واجهة برمجة تطبيقات جديدة لكل عملية أو حالة استخدام جديدة. +* يمكن أن يكون تصحيح أخطاء RPC صعباً. +* قد لا تتمكن من الاستفادة من التقنيات الموجودة مباشرةً. على سبيل المثال، قد يتطلب الأمر جهداً إضافياً لضمان [تخزين استدعاءات RPC بشكل صحيح في ذاكرة التخزين المؤقت](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) على خوادم التخزين المؤقت مثل [Squid](http://www.squid-cache.org/). + +### نقل الحالة التمثيلي (REST) + +REST هو نمط معماري يفرض نموذج العميل/الخادم حيث يعمل العميل على مجموعة من الموارد التي يديرها الخادم. يوفر الخادم تمثيلاً للموارد والإجراءات التي يمكن إما معالجتها أو الحصول على تمثيل جديد للموارد. يجب أن تكون جميع الاتصالات خالية من الحالة وقابلة للتخزين المؤقت. + +هناك أربع خصائص لواجهة RESTful: + +* **تحديد الموارد (URI في HTTP)** - استخدم نفس URI بغض النظر عن أي عملية. +* **التغيير مع التمثيلات (الأفعال في HTTP)** - استخدم الأفعال والترويسات والنص. +* **رسالة خطأ ذاتية الوصف (استجابة الحالة في HTTP)** - استخدم رموز الحالة، لا تعد اختراع العجلة. +* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (واجهة HTML لـ HTTP)** - يجب أن تكون خدمة الويب الخاصة بك قابلة للوصول بالكامل في المتصفح. + +أمثلة على استدعاءات REST: + +``` +GET /someresources/anId + +PUT /someresources/anId +{"anotherdata": "another value"} +``` +يركز REST على عرض البيانات. وهو يقلل من الترابط بين العميل/الخادم ويستخدم غالباً لواجهات برمجة التطبيقات HTTP العامة. يستخدم REST طريقة أكثر عمومية وموحدة لعرض الموارد من خلال URIs، و[التمثيل من خلال الترويسات](https://github.com/for-GET/know-your-http-well/blob/master/headers.md)، والإجراءات من خلال الأفعال مثل GET وPOST وPUT وDELETE وPATCH. كونه خالٍ من الحالة، فإن REST مثالي للتوسع الأفقي والتقسيم. + +#### عيوب REST + +* نظراً لتركيز REST على عرض البيانات، قد لا يكون مناسباً إذا لم تكن الموارد منظمة بشكل طبيعي أو يتم الوصول إليها في تسلسل هرمي بسيط. على سبيل المثال، إرجاع جميع السجلات المحدثة من الساعة الماضية التي تطابق مجموعة معينة من الأحداث لا يمكن التعبير عنها بسهولة كمسار. مع REST، من المحتمل أن يتم تنفيذها بمزيج من مسار URI ومعلمات الاستعلام، وربما نص الطلب. +* يعتمد REST عادةً على عدد قليل من الأفعال (GET وPOST وPUT وDELETE وPATCH) والتي قد لا تناسب حالة الاستخدام الخاصة بك في بعض الأحيان. على سبيل المثال، نقل المستندات منتهية الصلاحية إلى مجلد الأرشيف قد لا يتناسب بشكل واضح مع هذه الأفعال. +* يتطلب جلب الموارد المعقدة ذات التسلسلات الهرمية المتداخلة رحلات متعددة بين العميل والخادم لعرض واجهات فردية، مثل جلب محتوى مقال المدونة والتعليقات على ذلك المقال. بالنسبة للتطبيقات المحمولة التي تعمل في ظروف شبكة متغيرة، تعتبر هذه الرحلات المتعددة غير مرغوب فيها للغاية. +* مع مرور الوقت، قد تتم إضافة المزيد من الحقول إلى استجابة API وستتلقى العملاء القديمة جميع حقول البيانات الجديدة، حتى تلك التي لا تحتاجها، مما يؤدي إلى تضخم حجم البيانات المنقولة ويؤدي إلى زمن استجابة أطول. + +### مقارنة استدعاءات RPC وREST + +| العملية | RPC | REST | +|---|---|---| +| التسجيل | **POST** /signup | **POST** /persons | +| الاستقالة | **POST** /resign
{
"personid": "1234"
} | **DELETE** /persons/1234 | +| قراءة شخص | **GET** /readPerson?personid=1234 | **GET** /persons/1234 | +| قراءة قائمة عناصر شخص | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items | +| إضافة عنصر إلى قائمة عناصر شخص | **POST** /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | **POST** /persons/1234/items
{
"itemid": "456"
} | +| تحديث عنصر | **POST** /modifyItem
{
"itemid": "456";
"key": "value"
} | **PUT** /items/456
{
"key": "value"
} | +| حذف عنصر | **POST** /removeItem
{
"itemid": "456"
} | **DELETE** /items/456 | + +

+ المصدر: هل تعرف حقاً لماذا تفضل REST على RPC +

+ +#### المصادر وقراءات إضافية: REST وRPC + +* [هل تعرف حقاً لماذا تفضل REST على RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/) +* [متى تكون مناهج RPC أكثر ملاءمة من REST؟](http://programmers.stackexchange.com/a/181186) +* [REST مقابل JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc) +* [دحض خرافات RPC وREST](https://web.archive.org/web/20170608193645/http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) +* [ما هي عيوب استخدام REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs) +* [حل مقابلة تصميم النظام](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) +* [Thrift](https://code.facebook.com/posts/1468950976659943/) +* [لماذا REST للاستخدام الداخلي وليس RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508) + +## الأمان + +هذا القسم يحتاج إلى بعض التحديثات. نرحب [بمساهمتك](#contributing)! + +الأمان موضوع واسع. ما لم يكن لديك خبرة كبيرة، أو خلفية في الأمان، أو كنت تتقدم لوظيفة تتطلب معرفة بالأمان، فربما لن تحتاج إلى معرفة أكثر من الأساسيات: + +* التشفير أثناء النقل والتخزين. +* تنقية جميع مدخلات المستخدم أو أي معلمات إدخال معرضة للمستخدم لمنع [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) و [SQL injection](https://en.wikipedia.org/wiki/SQL_injection). +* استخدام الاستعلامات المعلمة لمنع SQL injection. +* استخدام مبدأ [الامتيازات الأدنى](https://en.wikipedia.org/wiki/Principle_of_least_privilege). + +### المصادر وقراءات إضافية + +* [قائمة التحقق من أمان API](https://github.com/shieldfy/API-Security-Checklist) +* [دليل الأمان للمطورين](https://github.com/FallibleInc/security-guide-for-developers) +* [أهم عشرة مخاطر OWASP](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet) + +## الملحق + +قد يُطلب منك أحياناً إجراء تقديرات تقريبية. على سبيل المثال، قد تحتاج إلى تحديد الوقت اللازم لإنشاء 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) + +### أرقام زمن الاستجابة التي يجب أن يعرفها كل مبرمج + +``` +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 +``` + +مقاييس مفيدة مبنية على الأرقام أعلاه: + +* القراءة التسلسلية من القرص الصلب HDD بسرعة 30 ميجابايت/ثانية +* القراءة التسلسلية من شبكة إيثرنت 1 جيجابت/ثانية بسرعة 100 ميجابايت/ثانية +* القراءة التسلسلية من القرص الصلب SSD بسرعة 1 جيجابايت/ثانية +* القراءة التسلسلية من الذاكرة الرئيسية بسرعة 4 جيجابايت/ثانية +* 6-7 رحلات ذهاب وإياب حول العالم في الثانية +* 2,000 رحلة ذهاب وإياب في الثانية داخل مركز البيانات + +#### تصور أرقام زمن الاستجابة + +![](https://camo.githubusercontent.com/77f72259e1eb58596b564d1ad823af1853bc60a3/687474703a2f2f692e696d6775722e636f6d2f6b307431652e706e67) + +#### المصادر وقراءات إضافية + +* [أرقام زمن الاستجابة التي يجب أن يعرفها كل مبرمج - 1](https://gist.github.com/jboner/2841832) +* [أرقام زمن الاستجابة التي يجب أن يعرفها كل مبرمج - 2](https://gist.github.com/hellerbarde/2843375) +* [تصميمات ودروس ونصائح من بناء أنظمة موزعة كبيرة](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) +* [نصائح هندسة البرمجيات من بناء أنظمة موزعة واسعة النطاق](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf) + +### أسئلة إضافية في مقابلات تصميم النظم + +> أسئلة شائعة في مقابلات تصميم النظم، مع روابط لمصادر حول كيفية حل كل منها. + +| السؤال | المرجع/المراجع | +|---|---| +| تصميم خدمة مزامنة ملفات مثل Dropbox | [youtube.com](https://www.youtube.com/watch?v=PE4gwstWhmc) | +| تصميم محرك بحث مثل Google | [queue.acm.org](http://queue.acm.org/detail.cfm?id=988407)
[stackexchange.com](http://programmers.stackexchange.com/questions/38324/interview-question-how-would-you-implement-google-search)
[ardendertat.com](http://www.ardendertat.com/2012/01/11/implementing-search-engines/)
[stanford.edu](http://infolab.stanford.edu/~backrub/google.html) | +| تصميم متصفح ويب قابل للتطوير مثل Google | [quora.com](https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch) | +| تصميم Google Docs | [code.google.com](https://code.google.com/p/google-mobwrite/)
[neil.fraser.name](https://neil.fraser.name/writing/sync/) | +| تصميم مخزن key-value مثل Redis | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) | +| تصميم نظام تخزين مؤقت مثل Memcached | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) | +| تصميم نظام توصيات مثل نظام Amazon | [hulu.com](https://web.archive.org/web/20170406065247/http://tech.hulu.com/blog/2011/09/19/recommendation-system.html)
[ijcai13.org](http://ijcai13.org/files/tutorial_slides/td3.pdf) | +| تصميم نظام URL مختصر مثل Bitly | [n00tc0d3r.blogspot.com](http://n00tc0d3r.blogspot.com/) | +| تصميم تطبيق دردشة مثل WhatsApp | [highscalability.com](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) | +| تصميم نظام مشاركة صور مثل Instagram | [highscalability.com](http://highscalability.com/flickr-architecture)
[highscalability.com](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html) | +| تصميم وظيفة الأخبار في Facebook | [quora.com](http://www.quora.com/What-are-best-practices-for-building-something-like-a-News-Feed)
[quora.com](http://www.quora.com/Activity-Streams/What-are-the-scaling-issues-to-keep-in-mind-while-developing-a-social-network-feed)
[slideshare.net](http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture) | +| تصميم وظيفة الجدول الزمني في Facebook | [facebook.com](https://www.facebook.com/note.php?note_id=10150468255628920)
[highscalability.com](http://highscalability.com/blog/2012/1/23/facebook-timeline-brought-to-you-by-the-power-of-denormaliza.html) | +| تصميم وظيفة الدردشة في Facebook | [erlang-factory.com](http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf)
[facebook.com](https://www.facebook.com/note.php?note_id=14218138919&id=9445547199&index=0) | +| تصميم وظيفة البحث في الرسوم البيانية مثل Facebook | [facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-out-the-infrastructure-for-graph-search/10151347573598920)
[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-indexing-and-ranking-in-graph-search/10151361720763920)
[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-the-natural-language-interface-of-graph-search/10151432733048920) | +| تصميم شبكة توصيل محتوى مثل CloudFlare | [figshare.com](https://figshare.com/articles/Globally_distributed_content_delivery/6605972) | +| تصميم نظام المواضيع الرائجة مثل Twitter | [michael-noll.com](http://www.michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in-storm/)
[snikolov.wordpress.com](http://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/) | +| تصميم نظام توليد معرّف عشوائي | [blog.twitter.com](https://blog.twitter.com/2010/announcing-snowflake)
[github.com](https://github.com/twitter/snowflake/) | +| إرجاع أعلى k طلب خلال فترة زمنية | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/default/files/documents/2005-23.pdf)
[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) | +| تصميم نظام يقدم البيانات من مراكز بيانات متعددة | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) | +| تصميم لعبة ورق متعددة اللاعبين عبر الإنترنت | [indieflashblog.com](https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html)
[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) | +| تصميم نظام جمع النفايات | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)
[washington.edu](http://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) | +| تصميم محدد معدل API | [stripe.com/blog/](https://stripe.com/blog/rate-limiters) | +| تصميم بورصة (مثل NASDAQ أو Binance) | [Jane Street](https://youtu.be/b1e4t2k2KJY)
[تطبيق Golang](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)
[تطبيق Go](http://bhomnick.net/building-a-simple-limit-order-in-go/) | +| إضافة سؤال تصميم نظام | [المساهمة](#contributing) | + +### تصميمات الأنظمة في العالم الحقيقي + +> مقالات حول كيفية تصميم الأنظمة في العالم الحقيقي. + +

+ +
+ المصدر: الجداول الزمنية في Twitter على نطاق واسع +

+ +**لا تركز على التفاصيل الدقيقة في المقالات التالية، بدلاً من ذلك:** + +* حدد المبادئ المشتركة والتقنيات الشائعة والأنماط داخل هذه المقالات +* ادرس المشكلات التي يحلها كل مكون، وأين يعمل بشكل جيد، وأين لا يعمل +* راجع الدروس المستفادة + +|النوع | النظام | المرجع/المراجع | +|---|---|---| +| معالجة البيانات | **MapReduce** - معالجة البيانات الموزعة من Google | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/mapreduce-osdi04.pdf) | +| معالجة البيانات | **Spark** - معالجة البيانات الموزعة من Databricks | [slideshare.net](http://www.slideshare.net/AGrishchenko/apache-spark-architecture) | +| معالجة البيانات | **Storm** - معالجة البيانات الموزعة من Twitter | [slideshare.net](http://www.slideshare.net/previa/storm-16094009) | +| | | | +| مخزن البيانات | **Bigtable** - قاعدة بيانات موزعة موجهة للأعمدة من Google | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) | +| مخزن البيانات | **HBase** - تطبيق مفتوح المصدر لـ Bigtable | [slideshare.net](http://www.slideshare.net/alexbaranau/intro-to-hbase) | +| مخزن البيانات | **Cassandra** - قاعدة بيانات موزعة موجهة للأعمدة من Facebook | [slideshare.net](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666) +| مخزن البيانات | **DynamoDB** - قاعدة بيانات موجهة للمستندات من Amazon | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) | +| مخزن البيانات | **MongoDB** - قاعدة بيانات موجهة للمستندات | [slideshare.net](http://www.slideshare.net/mdirolf/introduction-to-mongodb) | +| مخزن البيانات | **Spanner** - قاعدة بيانات موزعة عالمياً من Google | [research.google.com](http://research.google.com/archive/spanner-osdi2012.pdf) | +| مخزن البيانات | **Memcached** - نظام تخزين مؤقت موزع في الذاكرة | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) | +| مخزن البيانات | **Redis** - نظام تخزين مؤقت موزع في الذاكرة مع الاستمرارية وأنواع القيم | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) | +| | | | +| نظام الملفات | **Google File System (GFS)** - نظام ملفات موزع | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/gfs-sosp2003.pdf) | +| نظام الملفات | **Hadoop File System (HDFS)** - تطبيق مفتوح المصدر لـ GFS | [apache.org](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) | +| | | | +| متنوع | **Chubby** - خدمة قفل للأنظمة الموزعة المترابطة بشكل فضفاض من Google | [research.google.com](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf) | +| متنوع | **Dapper** - بنية تحتية لتتبع الأنظمة الموزعة | [research.google.com](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf) +| متنوع | **Kafka** - نظام رسائل publish/subscribe من LinkedIn | [slideshare.net](http://www.slideshare.net/mumrah/kafka-talk-tri-hug) | +| متنوع | **Zookeeper** - بنية تحتية وخدمات مركزية تمكن المزامنة | [slideshare.net](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) | +| | إضافة تصميم معماري | [المساهمة](#contributing) | + +### تصميمات معمارية للشركات + +| الشركة | المرجع/المراجع | +|---|---| +| Amazon | [بنية Amazon](http://highscalability.com/amazon-architecture) | +| Cinchcast | [إنتاج 1,500 ساعة من الصوت يومياً](http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html) | +| DataSift | [تحليل البيانات في الوقت الفعلي بمعدل 120,000 تغريدة في الثانية](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) | +| Dropbox | [كيف قمنا بتوسيع نطاق Dropbox](https://www.youtube.com/watch?v=PE4gwstWhmc) | +| ESPN | [التشغيل بمعدل 100,000 عملية في الثانية](http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html) | +| Google | [بنية Google](http://highscalability.com/google-architecture) | +| Instagram | [14 مليون مستخدم، تيرابايتات من الصور](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html)
[ما الذي يشغل Instagram](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances) | +| Justin.tv | [بنية بث الفيديو المباشر لـ Justin.Tv](http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html) | +| Facebook | [توسيع نطاق memcached في Facebook](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/key-value/fb-memcached-nsdi-2013.pdf)
[TAO: مخزن البيانات الموزع للرسم البياني الاجتماعي في Facebook](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/data-store/tao-facebook-distributed-datastore-atc-2013.pdf)
[تخزين الصور في Facebook](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Beaver.pdf)
[كيف يبث Facebook Live إلى 800,000 مشاهد في وقت واحد](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html) | +| Flickr | [بنية Flickr](http://highscalability.com/flickr-architecture) | +| Mailbox | [من 0 إلى مليون مستخدم في 6 أسابيع](http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html) | +| Netflix | [نظرة شاملة 360 درجة على كامل بنية Netflix](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)
[Netflix: ماذا يحدث عندما تضغط على زر التشغيل؟](http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html) | +| Pinterest | [من 0 إلى عشرات المليارات من مشاهدات الصفحات شهرياً](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html)
[18 مليون زائر، نمو 10 أضعاف، 12 موظف](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) | +| Playfish | [50 مليون مستخدم شهرياً وفي نمو مستمر](http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html) | +| PlentyOfFish | [بنية PlentyOfFish](http://highscalability.com/plentyoffish-architecture) | +| Salesforce | [كيف يتعاملون مع 1.3 مليار معاملة يومياً](http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html) | +| Stack Overflow | [بنية Stack Overflow](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) | +| TripAdvisor | [40 مليون زائر، 200 مليون مشاهدة صفحة ديناميكية، 30 تيرابايت من البيانات](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html) | +| Tumblr | [15 مليار مشاهدة صفحة شهرياً](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) | +| Twitter | [جعل Twitter أسرع بنسبة 10000 بالمئة](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster)
[تخزين 250 مليون تغريدة يومياً باستخدام MySQL](http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html)
[150 مليون مستخدم نشط، 300 ألف استعلام في الثانية، تدفق بيانات بسرعة 22 ميجابايت/ثانية](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html)
[الجداول الزمنية على نطاق واسع](https://www.infoq.com/presentations/Twitter-Timeline-Scalability)
[البيانات الكبيرة والصغيرة في Twitter](https://www.youtube.com/watch?v=5cKTP36HVgI)
[العمليات في Twitter: التوسع لأكثر من 100 مليون مستخدم](https://www.youtube.com/watch?v=z8LU0Cj6BOU)
[كيف يتعامل Twitter مع 3,000 صورة في الثانية](http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html) | +| Uber | [كيف توسع Uber منصة السوق في الوقت الفعلي](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html)
[الدروس المستفادة من توسيع Uber إلى 2000 مهندس، 1000 خدمة، و8000 مستودع Git](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) | +| WhatsApp | [بنية WhatsApp التي اشتراها Facebook مقابل 19 مليار دولار](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) | +| YouTube | [قابلية توسع YouTube](https://www.youtube.com/watch?v=w5WVu624fY8)
[بنية YouTube](http://highscalability.com/youtube-architecture) | +### مدونات هندسة الشركات + +> البنى المعمارية للشركات التي تجري مقابلات معها. +> +> قد تكون الأسئلة التي تواجهها من نفس المجال. + +* [Airbnb Engineering](http://nerds.airbnb.com/) +* [Atlassian Developers](https://developer.atlassian.com/blog/) +* [AWS Blog](https://aws.amazon.com/blogs/aws/) +* [Bitly Engineering Blog](http://word.bitly.com/) +* [Box Blogs](https://blog.box.com/blog/category/engineering) +* [Cloudera Developer Blog](http://blog.cloudera.com/) +* [Dropbox Tech Blog](https://tech.dropbox.com/) +* [Engineering at Quora](https://www.quora.com/q/quoraengineering) +* [Ebay Tech Blog](http://www.ebaytechblog.com/) +* [Evernote Tech Blog](https://blog.evernote.com/tech/) +* [Etsy Code as Craft](http://codeascraft.com/) +* [Facebook Engineering](https://www.facebook.com/Engineering) +* [Flickr Code](http://code.flickr.net/) +* [Foursquare Engineering Blog](http://engineering.foursquare.com/) +* [GitHub Engineering Blog](https://github.blog/category/engineering) +* [Google Research Blog](http://googleresearch.blogspot.com/) +* [Groupon Engineering Blog](https://engineering.groupon.com/) +* [Heroku Engineering Blog](https://engineering.heroku.com/) +* [Hubspot Engineering Blog](http://product.hubspot.com/blog/topic/engineering) +* [High Scalability](http://highscalability.com/) +* [Instagram Engineering](http://instagram-engineering.tumblr.com/) +* [Intel Software Blog](https://software.intel.com/en-us/blogs/) +* [Jane Street Tech Blog](https://blogs.janestreet.com/category/ocaml/) +* [LinkedIn Engineering](http://engineering.linkedin.com/blog) +* [Microsoft Engineering](https://engineering.microsoft.com/) +* [Microsoft Python Engineering](https://blogs.msdn.microsoft.com/pythonengineering/) +* [Netflix Tech Blog](http://techblog.netflix.com/) +* [Paypal Developer Blog](https://medium.com/paypal-engineering) +* [Pinterest Engineering Blog](https://medium.com/@Pinterest_Engineering) +* [Reddit Blog](http://www.redditblog.com/) +* [Salesforce Engineering Blog](https://developer.salesforce.com/blogs/engineering/) +* [Slack Engineering Blog](https://slack.engineering/) +* [Spotify Labs](https://labs.spotify.com/) +* [Stripe Engineering Blog](https://stripe.com/blog/engineering) +* [Twilio Engineering Blog](http://www.twilio.com/engineering) +* [Twitter Engineering](https://blog.twitter.com/engineering/) +* [Uber Engineering Blog](http://eng.uber.com/) +* [Yahoo Engineering Blog](http://yahooeng.tumblr.com/) +* [Yelp Engineering Blog](http://engineeringblog.yelp.com/) +* [Zynga Engineering Blog](https://www.zynga.com/blogs/engineering) + +#### المصادر وقراءات إضافية + +هل ترغب في إضافة مدونة؟ لتجنب تكرار العمل، يمكنك إضافة مدونة شركتك إلى المستودع التالي: + +* [kilimchoi/engineering-blogs](https://github.com/kilimchoi/engineering-blogs) + +## قيد التطوير + +هل أنت مهتم بإضافة قسم جديد أو المساعدة في إكمال قسم قيد التطوير؟ [ساهم معنا](#contributing)! + +* الحوسبة الموزعة باستخدام MapReduce +* التجزئة المتناسقة (Consistent hashing) +* التجميع والتوزيع (Scatter gather) +* [ساهم معنا](#contributing) + +## شكر وتقدير + +تم توفير الشكر والمصادر في جميع أنحاء هذا المستودع (repository). + +شكر خاص لـ: + +* [Hired in tech](http://www.hiredintech.com/system-design/the-system-design-process/) +* [Cracking the coding interview](https://www.amazon.com/dp/0984782850/) +* [High scalability](http://highscalability.com/) +* [checkcheckzz/system-design-interview](https://github.com/checkcheckzz/system-design-interview) +* [shashank88/system_design](https://github.com/shashank88/system_design) +* [mmcgrana/services-engineering](https://github.com/mmcgrana/services-engineering) +* [System design cheat sheet](https://gist.github.com/vasanthk/485d1c25737e8e72759f) +* [A distributed systems reading list](http://dancres.github.io/Pages/) +* [Cracking the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) + +## معلومات الاتصال + +لا تتردد في التواصل معي لمناقشة أي مشكلات أو أسئلة أو تعليقات. + +يمكنك العثور على معلومات الاتصال الخاصة بي على [صفحتي على GitHub](https://github.com/donnemartin). + +## الترخيص + +*أقدم لك الكود والموارد في هذا الـ repository تحت ترخيص مفتوح المصدر. نظراً لأن هذا repository شخصي، فإن الترخيص الذي تتلقاه للكود والموارد الخاصة بي هو مني وليس من صاحب عملي (Facebook).* + + Copyright 2017 Donne Martin + + Creative Commons Attribution 4.0 International License (CC BY 4.0) + + http://creativecommons.org/licenses/by/4.0/ diff --git a/README-ja.md b/README-ja.md index e8f4719d..79d1ed9c 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1,4 +1,4 @@ -*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) | [العَرَبِيَّة‎](https://github.com/donnemartin/system-design-primer/issues/170) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)* +*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) ∙ [العَرَبِيَّة‎](README-ar.md) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)* # システム設計入門 diff --git a/README-zh-Hans.md b/README-zh-Hans.md index 87898dc4..74589dba 100644 --- a/README-zh-Hans.md +++ b/README-zh-Hans.md @@ -3,7 +3,7 @@ > * 译者：[XatMassacrE](https://github.com/XatMassacrE)、[L9m](https://github.com/L9m)、[Airmacho](https://github.com/Airmacho)、[xiaoyusilen](https://github.com/xiaoyusilen)、[jifaxu](https://github.com/jifaxu)、[根号三](https://github.com/sqrthree) > * 这个 [链接](https://github.com/xitu/system-design-primer/compare/master...donnemartin:master) 用来查看本翻译与英文版是否有差别（如果你没有看到 README.md 发生变化，那就意味着这份翻译文档是最新的）。 -*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) | [العَرَبِيَّة‎](https://github.com/donnemartin/system-design-primer/issues/170) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)* +*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) ∙ [العَرَبِيَّة‎](README-ar.md) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)* # 系统设计入门 diff --git a/README-zh-TW.md b/README-zh-TW.md index c08f740d..bfa40b94 100644 --- a/README-zh-TW.md +++ b/README-zh-TW.md @@ -1,4 +1,4 @@ -*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) | [العَرَبِيَّة‎](https://github.com/donnemartin/system-design-primer/issues/170) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)* +*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) ∙ [العَرَبِيَّة‎](README-ar.md) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)* # 系統設計入門 diff --git a/TRANSLATIONS.md b/TRANSLATIONS.md index 5bfae9af..edf3ad35 100644 --- a/TRANSLATIONS.md +++ b/TRANSLATIONS.md @@ -52,6 +52,12 @@ Languages are grouped by status and are listed in alphabetical order. * Discussion Thread: https://github.com/donnemartin/system-design-primer/issues/87 * Translation Fork: https://github.com/voitau/system-design-primer/blob/master/README-ru.md +### ⏳ Arabic + +* Maintainer(s): [@MohamedMetwalli5](https://github.com/MohamedMetwalli5) 👏 +* Discussion Thread: https://github.com/donnemartin/system-design-primer/issues/170 +* Translation Fork: https://github.com/MohamedMetwalli5/system-design-primer/blob/arabic-translation/README-ar.md + ## Stalled **Notes**: @@ -60,13 +66,6 @@ Languages are grouped by status and are listed in alphabetical order. * If you're listed here as a "Previous Maintainer" but can commit to being an active maintainer, also let us know. * See the [Contributing Guidelines](CONTRIBUTING.md). -### ❗ Arabic - -* Maintainer(s): **Help Wanted** ✋ - * Previous Maintainer(s): [@aymns](https://github.com/aymns) -* Discussion Thread: https://github.com/donnemartin/system-design-primer/issues/170 -* Translation Fork: https://github.com/aymns/system-design-primer/blob/develop/README-ar.md - ### ❗ Bengali * Maintainer(s): **Help Wanted** ✋