أهلاً بكم. فلاديسلاف رودين على اتصال. أقوم حاليًا بتدريس دورات حول هندسة البرمجيات وهندسة البرمجيات عالية الضغط في OTUS. تحسبا لبدء تدفق الدورة الجديدة قررت أن أكتب قطعة قصيرة من المادة الأصلية التي أريد مشاركتها معك.
مقدمة
نظرًا لحقيقة أن محرك الأقراص الثابتة يمكنه إجراء ما بين 400 إلى 700 عملية فقط في الثانية (وهو ما لا يضاهى مع عدد RPS النموذجي لنظام عالي التحميل)، فإن قاعدة بيانات القرص الكلاسيكية هي عنق الزجاجة في البنية. ولذلك، فمن الضروري إيلاء اهتمام خاص لأنماط القياس لهذا التخزين.
يوجد حاليًا نمطان لقياس قاعدة البيانات: النسخ المتماثل والمشاركة. تسمح لك المشاركة بتوسيع نطاق عملية الكتابة، ونتيجة لذلك، تقليل معدل عدد الدورات لكل عملية كتابة لكل خادم في مجموعتك. يتيح لك النسخ المتماثل القيام بنفس الشيء، ولكن باستخدام عمليات القراءة. هذا هو النمط الذي خصصت له هذه المقالة.
تكرار
إذا نظرت إلى النسخ المتماثل على مستوى عالٍ جدًا، فهذا شيء بسيط: كان لديك خادم واحد، وكانت هناك بيانات عليه، ومن ثم لم يعد هذا الخادم قادرًا على التعامل مع عبء قراءة هذه البيانات. يمكنك إضافة بضعة خوادم أخرى، ومزامنة البيانات عبر جميع الخوادم، ويمكن للمستخدم القراءة من أي خادم في مجموعتك.
على الرغم من بساطته الواضحة، هناك عدة خيارات لتصنيف التطبيقات المختلفة لهذا المخطط:
- حسب الأدوار في المجموعة (السيد والسيد أو السيد والعبد)
- حسب الكائنات المرسلة (المستندة إلى الصف أو القائمة على البيان أو المختلطة)
- وفقا لآلية مزامنة العقدة
اليوم سوف نتعامل مع النقطة 3.
كيف يحدث التزام المعاملة؟
لا يرتبط هذا الموضوع مباشرة بالنسخ المتماثل، ويمكن كتابة مقال منفصل عنه، ولكن بما أن القراءة الإضافية عديمة الفائدة دون فهم آلية التزام المعاملة، دعني أذكرك بالأشياء الأساسية. يتم تنفيذ المعاملة على ثلاث مراحل:
- تسجيل المعاملة في سجل قاعدة البيانات.
- استخدام معاملة في محرك قاعدة البيانات.
- إعادة التأكيد للعميل بأن المعاملة تم تطبيقها بنجاح.
في قواعد بيانات مختلفة، قد تحتوي هذه الخوارزمية على فروق دقيقة: على سبيل المثال، يوجد في محرك InnoDB لقاعدة بيانات MySQL سجلان: أحدهما للنسخ المتماثل (السجل الثنائي)، والآخر للحفاظ على ACID (سجل التراجع/الإعادة)، بينما في PostgreSQL يوجد سجل واحد يؤدي كلتا الوظيفتين (سجل الكتابة المسبق = WAL). ولكن ما تم عرضه أعلاه هو بالتحديد المفهوم العام الذي يسمح بعدم أخذ هذه الفروق الدقيقة في الاعتبار.
النسخ المتزامن (المتزامن).
دعونا نضيف منطقًا لتكرار التغييرات المستلمة على خوارزمية التزام المعاملة:
- تسجيل المعاملة في سجل قاعدة البيانات.
- استخدام معاملة في محرك قاعدة البيانات.
- إرسال البيانات إلى كافة النسخ المتماثلة.
- استلام تأكيد من جميع النسخ المتماثلة بإتمام المعاملة عليها.
- إعادة التأكيد للعميل بأن المعاملة تم تطبيقها بنجاح.
مع هذا النهج نحصل على عدد من العيوب:
- ينتظر العميل تطبيق التغييرات على كافة النسخ المتماثلة.
- ومع زيادة عدد العقد في المجموعة، فإننا نقلل من احتمالية نجاح عملية الكتابة.
إذا كان كل شيء أكثر أو أقل وضوحا فيما يتعلق بالنقطة الأولى، فإن أسباب النقطة الثانية تستحق الشرح. إذا لم نتلق استجابة من عقدة واحدة على الأقل أثناء النسخ المتماثل المتزامن، فإننا نتراجع عن المعاملة. وبالتالي، من خلال زيادة عدد العقد في المجموعة، فإنك تزيد من احتمالية فشل عملية الكتابة.
هل يمكننا انتظار التأكيد من نسبة معينة فقط من العقد، على سبيل المثال، من 51% (النصاب القانوني)؟ نعم، يمكننا ذلك، ولكن في الإصدار الكلاسيكي، يلزم التأكيد من جميع العقد، لأنه بهذه الطريقة يمكننا ضمان الاتساق الكامل للبيانات في المجموعة، وهي ميزة لا شك فيها لهذا النوع من النسخ المتماثل.
النسخ المتماثل غير المتزامن (غير المتزامن).
دعونا تعديل الخوارزمية السابقة. سنرسل البيانات إلى النسخ المتماثلة "في وقت لاحق"، و"في وقت لاحق" سيتم تطبيق التغييرات على النسخ المتماثلة:
- تسجيل المعاملة في سجل قاعدة البيانات.
- استخدام معاملة في محرك قاعدة البيانات.
- إعادة التأكيد للعميل بأن المعاملة تم تطبيقها بنجاح.
- إرسال البيانات إلى النسخ المتماثلة وتطبيق التغييرات عليها.
يؤدي هذا النهج إلى حقيقة أن المجموعة تعمل بسرعة، لأننا لا نبقي العميل في انتظار وصول البيانات إلى النسخ المتماثلة وحتى الالتزام بها.
لكن شرط تفريغ البيانات على النسخ المتماثلة "في وقت لاحق" يمكن أن يؤدي إلى فقدان المعاملة، وفقدان المعاملة المؤكدة من قبل المستخدم، لأنه إذا لم يكن هناك وقت لنسخ البيانات، فسيتم التأكيد للعميل حول نجاح العملية التي تم إرسالها، والعقدة التي وصلت إليها التغييرات تحطمت HDD، نفقد المعاملة، والتي يمكن أن تؤدي إلى عواقب غير سارة للغاية.
النسخ المتماثل شبه المتزامن
وأخيرا نصل إلى النسخ المتماثل شبه المتزامن. هذا النوع من النسخ ليس معروفًا جيدًا أو شائعًا جدًا، لكنه يحظى باهتمام كبير لأنه يمكن أن يجمع بين مزايا النسخ المتزامن وغير المتزامن.
دعونا نحاول الجمع بين الطريقتين السابقتين. لن نحتفظ بالعميل لفترة طويلة، ولكننا سنطلب تكرار البيانات:
- تسجيل المعاملة في سجل قاعدة البيانات.
- استخدام معاملة في محرك قاعدة البيانات.
- إرسال البيانات إلى النسخ المتماثلة.
- تلقي تأكيد من النسخة المتماثلة بأنه تم استلام التغييرات (سيتم تطبيقها "في وقت لاحق").
- إعادة التأكيد للعميل بأن المعاملة تم تطبيقها بنجاح.
يرجى ملاحظة أنه باستخدام هذه الخوارزمية، لا يحدث فقدان المعاملة إلا في حالة فشل العقدة التي تتلقى التغييرات والعقدة المتماثلة. ويعتبر احتمال حدوث مثل هذا الفشل منخفضا، ويتم قبول هذه المخاطر.
ولكن مع هذا النهج هناك خطر محتمل للقراءات الوهمية. لنتخيل السيناريو التالي: في الخطوة 4، لم نتلق تأكيدًا من أي نسخة متماثلة. يجب علينا التراجع عن هذه المعاملة وعدم إعادة التأكيد إلى العميل. نظرًا لأنه تم تطبيق البيانات في الخطوة 2، توجد فجوة زمنية بين نهاية الخطوة 2 والتراجع عن المعاملة، حيث يمكن للمعاملات المتوازية خلالها رؤية التغييرات التي لا ينبغي أن تكون في قاعدة البيانات.
النسخ المتماثل شبه المتزامن بدون خسارة
إذا فكرت قليلاً، يمكنك فقط عكس خطوات الخوارزمية وإصلاح مشكلة القراءات الوهمية في هذا السيناريو:
- تسجيل المعاملة في سجل قاعدة البيانات.
- إرسال البيانات المتماثلة.
- تلقي تأكيد من النسخة المتماثلة بأنه تم استلام التغييرات (سيتم تطبيقها "في وقت لاحق").
- استخدام معاملة في محرك قاعدة البيانات.
- إعادة التأكيد للعميل بأن المعاملة تم تطبيقها بنجاح.
الآن نلتزم بالتغييرات فقط إذا تم تكرارها.
إنتاج
وكما هو الحال دائماً، لا توجد حلول مثالية، بل هناك مجموعة من الحلول، ولكل منها مميزاته وعيوبه، وهي مناسبة لحل فئات مختلفة من المشاكل. وينطبق هذا تمامًا على اختيار آلية لمزامنة البيانات في قاعدة بيانات منسوخة. إن مجموعة المزايا التي يتمتع بها النسخ شبه المتزامن قوية ومثيرة للاهتمام بدرجة كافية بحيث يمكن اعتبارها جديرة بالاهتمام، على الرغم من انتشارها المنخفض.
هذا كل شئ. نراكم في !
المصدر: www.habr.com