🔂 🧖🏽 🥃 لماذا قد تحتاج إلى النسخ المتماثل شبه المتزامن؟ 👜 👌 ⛹🏼

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

المقدمة

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

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

تكرار

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

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

حسب الأدوار في المجموعة (سيد-سيد أو سيد-عبد)
بواسطة الكائنات المعاد توجيهها (المستندة إلى الصف أو المستندة إلى العبارة أو مختلطة)
وفقا لآلية تزامن العقدة

اليوم سنتعامل مع النقطة الثالثة.

كيف يتم الالتزام بالمعاملة

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

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

في قواعد البيانات المختلفة ، قد تنشأ فروق دقيقة في هذه الخوارزمية: على سبيل المثال ، في محرك InnoDB لقاعدة بيانات MySQL هناك سجلان: أحدهما للنسخ المتماثل (السجل الثنائي) والآخر للحفاظ على ACID (سجل التراجع / الإعادة) ، بينما في PostgreSQL هناك سجل واحد تنفيذ كلتا الوظيفتين (كتابة سجل المستقبل = WAL). ولكن أعلاه هو بالضبط المفهوم العام الذي يسمح بتجاهل مثل هذه الفروق الدقيقة.

النسخ المتزامن (المزامنة)

دعنا نضيف المنطق لتكرار التغييرات المستلمة في خوارزمية الالتزام بالمعاملة:

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

مع هذا النهج ، نحصل على عدد من العيوب:

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

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

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

النسخ المتزامن غير المتزامن

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

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

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

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

النسخ المتماثل شبه

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

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

كتابة معاملة في سجل قاعدة البيانات.
تطبيق المعاملة في محرك قاعدة البيانات.
إرسال البيانات إلى النسخ المتماثلة.
تلقي تأكيد من النسخة المتماثلة حول تلقي التغييرات (سيتم تطبيقها "في وقت لاحق").
إعادة التأكيد للعميل حول التطبيق الناجح للمعاملة.

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

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

النسخ المتماثل شبه المفقود

إذا كنت تفكر قليلاً ، يمكنك فقط تغيير خطوات الخوارزمية في الأماكن لإصلاح مشكلة القراءات الوهمية في هذا السيناريو:

كتابة معاملة في سجل قاعدة البيانات.
إرسال بيانات النسخة المتماثلة.
تلقي تأكيد من النسخة المتماثلة حول تلقي التغييرات (سيتم تطبيقها "في وقت لاحق").
تطبيق المعاملة في محرك قاعدة البيانات.
إعادة التأكيد للعميل حول التطبيق الناجح للمعاملة.

الآن نلتزم بالتغييرات فقط إذا تم نسخها.

استنتاج

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

هذا كل شئ. نراكم في الدورة !

لماذا قد تحتاج إلى النسخ المتماثل شبه المتزامن؟