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

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

إحدى المشاكل التي يواجهها الشخص الذي يريد ترحيل مشروع إلى نظام موزع أو بدء مشروع عليه هو المنتج الذي يختار.

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

تستند هذه المقالة إلى موادنا المتعلقة بالاتساق وضمانات ACID في الأنظمة الموزعة.

ما هو ولماذا هو مطلوب؟

" اتساق البيانات (أحيانًا اتساق البيانات ) هو اتساق البيانات مع بعضها البعض ، وتكامل البيانات ، والاتساق الداخلي." ( ويكيبيديا )

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

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

على سبيل المثال ، إذا كان لدي نظام من 4 عقد: A و B و C و D ، والتي تخدم المعاملات المصرفية ، وتم فصل العقد C و D عن A و B (على سبيل المثال ، بسبب مشاكل في الشبكة) ، فمن المحتمل جدًا أنني لست الآن لدي حق الوصول إلى جزء من المعاملة. كيف أتصرف في هذه الحالة؟ تتخذ النظم المختلفة مناهج مختلفة.


في المستوى الأعلى ، هناك اتجاهان رئيسيان يتم التعبير عنهما في نظرية CAP.

" إن نظرية CAP (تُعرف أيضًا باسم نظرية بروير ) عبارة إرشادية مفادها أنه في أي تطبيق للحوسبة الموزعة من الممكن تقديم ما لا يزيد عن اثنين من الخصائص الثلاثة التالية:

• تناسق البيانات (تناسق الهندسة) - في جميع عقد الحوسبة في وقت واحد ، لا تتعارض البيانات مع بعضها البعض ؛
• التوافر (Eng .وفرة) - أي طلب لنظام موزع ينتهي باستجابة صحيحة ، ولكن بدون ضمان تطابق إجابات جميع عقد النظام ؛
• تحمل التقسيم - إن تقسيم النظام الموزع إلى عدة أقسام معزولة لا يؤدي إلى استجابة غير صحيحة من كل قسم. "

( ويكيبيديا )

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

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

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

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

غالبًا ما يتم حل مشكلة الاتساق في الأنظمة الموزعة ببساطة عن طريق التخلي عن هذا التناسق.

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

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

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

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

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

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

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

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

لذلك ، الإجابة على السؤال "لماذا هذا ضروري؟": من الضروري إذا كان من المهم لمهمتك أن يكون لديك بيانات حديثة ومتناسقة ، والبديل سيجلب لك خسائر كبيرة أكبر من عدم التوفر المؤقت للخدمة خلال فترة الحادث أو أدائها المنخفض.

كيف تقدم هذا؟

وفقًا لذلك ، فإن أول قرار عليك اتخاذه هو المكان الذي تكون فيه في نظرية CAP ، وتريد الاتساق أو التوفر في حالة وقوع حادث.

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

إذا لم يكن ذلك كافيًا بالنسبة لك ، فإننا نبدأ في الاقتراب من مفهوم معاملات ACID الموزعة بالكامل.

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

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

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

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

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

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

يمنح النهج الثاني مزيدًا من الحرية في التحجيم ، وينقسم بدوره إلى بروتوكولات التزام بمرحلتين ( Wikipedia ) وثلاثية ( Wikipedia ).

ضع في اعتبارك تنفيذًا من مرحلتين يستخدم ، على سبيل المثال ، Apache Ignite.



ينقسم إجراء الالتزام إلى مرحلتين: الإعداد والالتزام.

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

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

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

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

الاستنتاجات

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

علاوة على ذلك ، تقع منتجات هذه الفئة على نقاط مختلفة من مقياس الاتساق ، من منتجات AP الكاملة دون أي معاملات إلى منتجات CP التي توفر بالإضافة إلى معاملات ACID الكاملة. يمكن تكوين بعض المنتجات بطريقة أو بأخرى.

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

عند تقييم المنتجات من هذا الجانب ، يجدر الانتباه إلى ما يلي:

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