التوسّع وموازنة الأحمال

توسيع نطاق القراءة باستخدام النسخ المتماثلة

18 دقيقة الدرس 7 من 10

توسيع نطاق القراءة باستخدام النسخ المتماثلة

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

اختناق العقدة المنفردة

لكل خادم قاعدة بيانات حدٌّ أقصى: أنوية المعالج، وذاكرة الوصول العشوائي لمجموعة المخزن المؤقت، وعرض نطاق إدخال/إخراج القرص، وإنتاجية الشبكة. حين تستنزف استعلامات القراءة هذه الموارد، يتباطأ كل استعلام — بما فيها عمليات الكتابة. يمكنك إضافة فهارس وضبط الاستعلامات وترقية الأجهزة، لكن في نهاية المطاف ستصل إلى سقف. الخطوة التالية هي توزيع عبء القراءة عبر عدة نسخ من قاعدة البيانات.

قاعدة الإبهام: عقدة MySQL أو PostgreSQL منفردة مضبوطة جيداً على عتاد حديث تستطيع التعامل مع ما يقارب 5,000–15,000 استعلام قراءة بسيط في الثانية. بعد ذلك تحتاج إلى نسخ متماثلة — أو بنية مختلفة جذرياً.

كيف تعمل النسخ المتماثلة

النسخ المتماثل لقاعدة البيانات هو عملية النسخ المستمر للبيانات من عقدة واحدة — العقدة الأساسية (تُعرف أيضاً بالقائد أو المصدر) — إلى عقدة أو أكثر تُسمى النسخ المتماثلة (تُعرف أيضاً بالتابعين أو الاحتياطيين). العقدة الأساسية تقبل عمليات القراءة والكتابة معاً. النسخ المتماثلة تقبل القراءة فقط.

آلية النسخ المتماثل تختلف حسب محرك قاعدة البيانات لكن المفهوم واحد في كل مكان:

  1. تصل عملية كتابة إلى العقدة الأساسية. تُسجّل العقدة الأساسية التغيير في تخزينها الخاص وتدوّنه في سجل النسخ المتماثل (يُسمى binlog في MySQL، وWAL — سجل الكتابة المسبق — في PostgreSQL).
  2. تحافظ كل نسخة متماثلة على اتصال بالعقدة الأساسية وتبث ذلك السجل باستمرار.
  3. تطبّق النسخة المتماثلة نفس العمليات على نسختها الخاصة من البيانات، وتبقى متزامنة.
  4. تُخدَّم عمليات القراءة الموجهة إلى نسخة متماثلة كلياً من تخزينها المحلي — العقدة الأساسية لا تُشارك فيها إطلاقاً.
Primary-replica replication topology with read/write split Application Writes Reads Primary DB Reads + Writes Read LB / Proxy Round-robin to replicas Replica 1 Reads only Replica 2 Reads only Replica 3 Reads only WAL / binlog
تقسيم القراءة والكتابة: التطبيق يُرسل عمليات الكتابة إلى العقدة الأساسية ويوزع عمليات القراءة عبر النسخ المتماثلة من خلال وكيل أو موازن تحميل للقراءة.

النسخ المتماثل المتزامن مقابل غير المتزامن

مدى سرعة لحاق النسخة المتماثلة بالعقدة الأساسية يحكمه وضع النسخ المتماثل:

  • غير المتزامن (الافتراضي في معظم الأنظمة): تُسجّل العقدة الأساسية عملية الكتابة وتُخطر العميل فوراً، دون انتظار أي نسخة متماثلة لتطبيق التغيير. النسخ المتماثلة تلحق في الخلفية — عادةً خلال ميلي ثانية على شبكة المنطقة المحلية، لكن ربما ثوانٍ أو دقائق تحت حِمل ثقيل أو شبكة بطيئة. هذا الخيار يمنح أعلى إنتاجية لكنه يُدخل تأخر النسخ المتماثل.
  • المتزامن (semi-sync في MySQL، synchronous standby في PostgreSQL): تنتظر العقدة الأساسية تأكيد نسخة متماثلة واحدة على الأقل باستلام الكتابة قبل إخطار العميل. هذا يمنع فقدان البيانات عند فشل العقدة الأساسية لكنه يُضيف زمن استجابة للكتابة يعادل رحلة شبكة واحدة على الأقل.
  • شبه المتزامن: حل وسط عملي — نسخة متماثلة واحدة يجب أن تُؤكد، والباقي غير متزامن. يُستخدم بكثرة في إعدادات MySQL عالية التوفر.
تأخر النسخ المتماثل يُشكّل خطراً على الاتساق. إذا كتبت سجلاً ثم قرأته فوراً من نسخة متماثلة لم تلحق بعد، ستحصل على بيانات قديمة — أو ما هو أسوأ: نتيجة غير موجود. هذا يُسمى عدم اتساق قراءة ما كتبته. وجّه دائماً القراءات التي يجب أن تكون حديثة (مثل القراءة فوراً بعد إرسال المستخدم لنموذج) مباشرةً إلى العقدة الأساسية.

تطبيق فصل القراءة والكتابة

تُوفر معظم البنى التقنية الحديثة إحدى هذه الآليات على الأقل لفصل اتصالات القراءة والكتابة:

  • التوجيه على مستوى التطبيق: إطار ORM أو مكتبة قاعدة البيانات لديك يدعم سلاسل اتصال متعددة. الكتابة تستخدم اتصال write؛ القراءة تستخدم تجمع اتصالات read. إعداد اتصالات القراءة/الكتابة في Laravel مثال نموذجي — تُدرج مضيفاً أو أكثر لـ read ومضيفاً لـ write؛ يوجّه الإطار تلقائياً.
  • التوجيه على مستوى الوكيل: وكيل وسيط مثل ProxySQL (MySQL) أو PgBouncer + pgpool-II (PostgreSQL) يجلس بين تطبيقك وقاعدة البيانات. يفحص عبارات SQL ويوجّه عبارات SELECT إلى النسخ المتماثلة وINSERT/UPDATE/DELETE/BEGIN إلى العقدة الأساسية. التطبيق يرى سلسلة اتصال واحدة فقط.
  • النسخ المتماثلة المُدارة سحابياً: Amazon RDS وGoogle Cloud SQL وAzure Database جميعها تُقدم نسخاً متماثلة للقراءة كميزة بنقرة واحدة. AWS Aurora تتجاوز ذلك بتوفير نقطة نهاية reader واحدة تُوازن التحميل عبر جميع النسخ المتماثلة تلقائياً.
أفضل ممارسة: استخدم وكيلاً (ProxySQL، RDS Proxy) في الإنتاج بدلاً من التوجيه على مستوى التطبيق. الوكيل يتعامل مع تبديل الأدوار عند الفشل — إذا فشلت العقدة الأساسية وتمت ترقية نسخة متماثلة، يُحدّث الوكيل جدول التوجيه الخاص به وكود تطبيقك لا يتغير إطلاقاً.

كم عدد النسخ المتماثلة التي تحتاجها؟

ابدأ بالأرقام. لنفترض أن عقدتك الأساسية تتعامل مع 8,000 استعلام قراءة في الثانية (QPS) وتريد البقاء تحت 60% استخدام للمعالج كهامش أمان. عند 60% تكون عقدتك الأساسية مريحة عند 5,000 QPS تقريباً. إذا كانت كل نسخة متماثلة لها نفس سعة العتاد:

  • إجمالي حمل القراءة: 8,000 QPS
  • السعة لكل عقدة عند 60%: 5,000 QPS
  • النسخ المتماثلة المطلوبة: ⌈8,000 / 5,000⌉ = نسختان متماثلتان، تاركتين العقدة الأساسية للكتابة فقط

عملياً، أضف نسخة متماثلة إضافية واحدة على الأقل كاحتياطي حار ولاستيعاب ارتفاعات حركة المرور. المنصات الكبيرة مثل GitHub وShopify تشغّل عشرات النسخ المتماثلة لكل شريحة — ليس فقط لإنتاجية القراءة، بل أيضاً للقرب الجغرافي (وضع نسخة متماثلة في أوروبا لخدمة المستخدمين الأوروبيين بزمن استجابة أقل) ولأعباء التحليل (تشغيل تقارير GROUP BY الثقيلة على نسخة متماثلة حتى لا تُؤثر أبداً على العقدة الأساسية).

Capacity planning: read load distribution across primary and replicas No Replicas With 2 Read Replicas Primary DB CPU: 90% ⚠ 8,000 QPS (reads) + all writes Slow queries, timeouts, outage risk Primary DB CPU: 25% Writes only Replica 1 CPU: 48% 4,000 QPS Replica 2 CPU: 48% 4,000 QPS Reads split evenly, primary free for writes ✓
يساراً: عقدة أساسية مُثقَلة. يميناً: نفس حمل الكتابة على العقدة الأساسية و8,000 QPS من القراءة مُوزَّعة عبر نسختين متماثلتين — كل عقدة تبقى تحت حدها الأقصى بمريح.

تأخر النسخ المتماثل: القياس والإدارة

تأخر النسخ المتماثل هو الزمن الفاصل بين تسجيل الكتابة على العقدة الأساسية وظهورها على النسخة المتماثلة. يمكنك مراقبته مباشرة:

-- MySQL: ثوانٍ خلف العقدة الأساسية SHOW REPLICA STATUS\G -- ابحث عن: Seconds_Behind_Source: 0 -- PostgreSQL: التأخر بالبايت والزمن SELECT client_addr, write_lag, flush_lag, replay_lag FROM pg_stat_replication;

استراتيجيات للحفاظ على التأخر منخفضاً:

  • النسخ المتماثل المتوازي: MySQL 8.0+ وPostgreSQL 10+ يستطيعان تطبيق سجل النسخ المتماثل باستخدام خيوط متعددة بالتوازي، مما يُقلل التأخر بشكل كبير تحت معدلات الكتابة العالية.
  • تحجيم النسخ المتماثلة: امنح النسخ المتماثلة نفس مقدار الذاكرة العشوائية (أو أكثر) للعقدة الأساسية حتى تكون ذاكرة التخزين المؤقت دافئة بالتساوي.
  • تجنب استعلامات التحليل الثقيلة على النسخ المتماثلة تحت التأخر الكبير — استعلام SELECT طويل الأمد يمكنه الإمساك بأقفال تُعيق النسخ المتماثل.
  • راقب التأخر كمقياس SLO — أنذر عند تجاوز 5 ثوانٍ، وأرسل تنبيهاً عند تجاوز 30 ثانية.

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

النسخة المتماثلة ليست مجرد أداة لتوسيع نطاق القراءة — إنها مسار الاسترداد عند فشل العقدة الأساسية. في إعداد عالي التوفر، تُعيَّن إحدى النسخ المتماثلة كـاحتياطي حار. عند توقف العقدة الأساسية، تُرقّي عملية تبديل أدوار آلية الاحتياطي إلى عقدة أساسية في غضون ثوانٍ، وتُحدّث جدول توجيه DNS أو الوكيل، وتُعيد النسخ المتماثلة الأخرى الاتصال بالعقدة الأساسية الجديدة.

الأدوات التي تُؤتمت هذا: Orchestrator (MySQL)، Patroni (PostgreSQL)، Amazon RDS Multi-AZ (مُدار بالكامل، تبديل أدوار تلقائي في ~60 ثانية). النسخ المتماثلة المُدارة سحابياً مع تبديل أدوار تلقائي أصبحت الآن المعيار لأي نظام إنتاجي لا يتحمل توقفاً لدقائق متعددة.

النسخ المتماثلة ليست نسخاً احتياطية. ستطبّق النسخة المتماثلة بأمانة أمر DROP TABLE أو صف بيانات تالف كُتب على العقدة الأساسية. احتفظ دائماً بنسخة احتياطية دورية منفصلة (مثل mysqldump، pg_dump، أو نسخة احتياطية قائمة على اللقطات) بالإضافة إلى نسخك المتماثلة.

المقايضات في لمحة

  • فائدة — إنتاجية القراءة: توسع أفقي خطي لعمليات القراءة. أضف نسخة متماثلة، أضف 5,000–15,000 QPS من سعة القراءة.
  • فائدة — التوزيع الجغرافي: نسخة متماثلة في كل منطقة تخدم المستخدمين المحليين بزمن استجابة لقاعدة البيانات أقل من 10 ميلي ثانية بدلاً من رحلات عبر المحيط.
  • فائدة — التوفر العالي: النسخ المتماثلة تُضاعف كاحتياطيات، محوّلةً أعطال الأجهزة إلى ثوانٍ من التوقف بدلاً من ساعات.
  • تكلفة — قابلية توسع الكتابة: النسخ المتماثل لا يُساعد الكتابات. كل كتابة لا تزال تذهب إلى عقدة أساسية واحدة. لأعباء الكتابة الكثيفة تحتاج إلى التجزئة (الدرس 8).
  • تكلفة — الاتساق: النسخ المتماثل غير المتزامن يعني أن النسخ المتماثلة قد تتأخر. يجب تصميم التطبيقات لتتحمل الاتساق النهائي في مسارات القراءة، أو توجيه القراءات الحساسة إلى العقدة الأساسية.
  • تكلفة — تعقيد التشغيل: المزيد من العقد يعني مزيداً من المراقبة ومنطق تبديل الأدوار وإدارة الاتصالات. استخدم وكيلاً أو خدمة مُدارة لاستيعاب هذا التعقيد.
ابدأ بسيطاً: عقدة أساسية واحدة + نسخة متماثلة واحدة للقراءة تُعالج 90% من احتياجات توسع القراءة للمنتجات في مراحلها الأولى. لا تحتاج إلى أسطول من النسخ المتماثلة حتى تُصبح إنتاجية الاستعلام على عقدة منفردة عائقاً حقيقياً — وهذه اللحظة قابلة للقياس باستخدام SHOW STATUS LIKE 'Threads_running' أو ما يعادله.
الدرس السابق توسيع طبقة التطبيق
الدرس التالي التجزئة من أجل التوسع
العودة للدورة