كيف توسّع MySQL عندما تنمو الحركة مئة ضعف؟

Question

IT Interview Practice · Accepted Answer

وسّع على مراحل: **read replicas + التخزين المؤقت للقراءات أولاً، ثم التجزئة (Vitess) للكتابات** — وأضِف تجميع الاتصالات (connection pooling) قبل أي شيء، فهو أرخص 10x. القراءات والكتابات تتوسّع بشكل مختلف، فلا تلجأ إلى التجزئة في اليوم الأول.

```text
        ┌─▶ Cache (Redis) ── hit ──▶ return
App ─▶ Pool(PgBouncer/ProxySQL)      miss ▼
        │                    ┌─▶ Read replica 1 ┐
        ├──── reads ─────────┼─▶ Read replica 2 ┼─ (async replication)
        │                    └─▶ Read replica N ┘
        └──── writes ──▶ Primary ──▶ (later) Vitess shards ─▶ Primary A / Primary B
```

## الخطوة 0: تجميع الاتصالات

كل اتصال MySQL يكلّف ذاكرة وخيطاً. عند حركة مئة ضعف ستستنفد `max_connections` قبل الـ CPU بكثير. مُجمِّع مثل **ProxySQL** أو **PgBouncer** يُعدِّد (multiplexes) آلاف اتصالات التطبيق على بضع مئات من اتصالات قاعدة البيانات. إنه تغيير إعدادات لا إعادة هندسة — افعله أولاً.

## الخطوة 1: خزّن القراءات في الكاش

معظم أحمال العمل ثقيلة القراءة (غالباً أكثر من 90%). ضع **Redis** في المقدمة للصفوف الساخنة — ملفّات المستخدمين، صفحات المنتجات. إصابة الكاش (cache hit) لا تلمس MySQL أبداً. استخدم cache-aside: اقرأ الكاش ← فقدان ← اقرأ قاعدة البيانات ← عبّئ الكاش. هذا وحده يمكن أن يمتصّ غالبية الـ 100x.

## الخطوة 2: read replicas

أضِف **read replicas غير متزامنة (async)** ووجّه استعلامات SELECT إليها، والكتابات إلى الـ primary. هذا يوسّع القراءات أفقياً: N replica ≈ N× سعة قراءة. المأزق هو **تأخّر النسخ (replication lag)** — قد يتأخّر replica بأجزاء من الثانية إلى ثوانٍ، فقراءة كتاباتك الخاصة (read-your-own-writes) تحتاج عناية (وجّه قراءات ذلك المستخدم إلى الـ primary، أو اقرأ من الكاش).

## الخطوة 3: جزّئ الكتابات

الـ replicas لا تساعد الكتابات — كل كتابة تصيب الـ primary الوحيد. عندما يُشبع الـ throughput الكتابي صندوقاً واحداً، **جزّئ**. **Vitess** (المبني في YouTube) يجلس أمام MySQL ويقوم بالتجزئة وتوجيه الاستعلامات وإعادة التجزئة عبر الإنترنت دون إعادة كتابة التطبيق. جزّئ حسب `user_id` كي تبقى معظم الاستعلامات على جزء واحد.

## منظور المقابلة

يراقب المُحاورون **الترتيب**: المرشّحون الذين يجزّئون فوراً يكشفون أنهم لا يعرفون أن الـ replicas/الكاش تحلّ توسيع القراءة بثمن أرخص بكثير. الجيد: "أضِف replicas وكاشاً." الرائع: تفصل مسار القراءة عن مسار الكتابة، وتسمّي تأخّر النسخ كتكلفة للـ replicas، ولا تُدخل التجزئة إلا عندما تكون *الكتابات* — لا القراءات — هي عنق الزجاجة.

**فخّ شائع:** "فقط أضِف read replicas" بينما عنق الزجاجة الحقيقي هو throughput الكتابة. الـ replicas تجعله *أسوأ* (حمل نسخ أكبر على الـ primary).

## المقايضات وأنماط الأعطال

- **تأخّر النسخ:** قراءات قديمة؛ ثبّت القراءات الحرجة على الـ primary أو استخدم نسخاً شبه متزامن (semi-sync).
- **تدافع الكاش (Cache stampede):** فقدانات كثيرة تصيب قاعدة البيانات معاً عند الانتهاء — استخدم أقفالاً أو TTLs متدرّجة.
- **تعقيد التجزئة:** يفقد الوصلات والمعاملات العابرة للأجزاء؛ لا تدفع ثمنه إلا عندما تفرضه الكتابات.
- **التحويل عند الفشل (Failover):** موت الـ primary يحتاج ترقية آلية (Orchestrator)؛ replica مُرقّى قديم قد يفقد كتابات حديثة.

الخطوة 0: تجميع الاتصالات

الخطوة 1: خزّن القراءات في الكاش

الخطوة 2: read replicas

الخطوة 3: جزّئ الكتابات

منظور المقابلة

المقايضات وأنماط الأعطال

أسئلة ذات صلة