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