ليه التزامن مشكلة؟

1. الـ Transaction

مثال: تحويل 100 جنيه من حساب علي لحساب منى عبارة عن عمليتين: خصم من علي، وإضافة لمنى. لو السيرفر وقع بينهم، الفلوس تختفي. فبنحطهم في Transaction:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;  -- علي
UPDATE accounts SET balance = balance + 100 WHERE id = 2;  -- منى
COMMIT;

الـ Transaction ليها 4 ضمانات مشهورة باسم ACID:

الموضوع ده كله عن حرف واحد: الـ I.

الـ Transaction بتحل مشكلة “السيرفر وقع في النص”. الـ Isolation بتحل مشكلة “حد تاني شغال معايا في نفس الوقت”.

2. الـ Schedule: التنفيذ المتداخل

كل Transaction عبارة عن سلسلة عمليات صغيرة: قراية عنصر (R(x))، وكتابة عنصر (W(x))، وفي الآخر COMMIT أو ABORT. لما فيه أكتر من Transaction شغالين، الداتابيز بتنفّذ عملياتهم بترتيب معين.

مثال لترانزاكشنين، كل واحدة بتقرا x وتكتبه:

السؤال المنطقي: طب ما نشغّلهم دايماً Serial ونرتاح؟ المشكلة إن ده بيقتل الأداء:

• الـ I/O بطيء: Transaction مستنية قراية من الـ Disk (مللي ثواني) والـ CPU واقف. أثناء ما هي مستنية، Transaction تانية ممكن تشتغل.
• الترانزاكشنز مش بتلمس نفس الداتا غالباً: واحد بيشتري موبايل وواحد بيشتري كتاب. مفيش أي سبب واحد فيهم يستنى التاني.
• فيه CPUs كتير: سيرفر فيه 32 core. لو شغّلنا Transaction واحدة بس في الوقت، بنستخدم 1 من 32.

فالداتابيز لازم تداخل العمليات عشان تخدم آلاف الطلبات في الثانية. والتداخل ده هو مصدر كل المشاكل.

التداخل (Interleaving) مش اختيار، هو ضرورة عشان الأداء. والـ Concurrency Control هو اللي بيخلّي التداخل ده آمن.

3. أول مشكلة: Lost Update

متجر فيه موبايل واحد بس في المخزن (stock = 1). اتنين بيدوسوا “اشتري” في نفس اللحظة. كود الشراء بسيط ومنطقي: اقرا المخزون، لو أكبر من صفر اخصم واحد.

لاحظ إن كل Transaction لوحدها كودها صح 100%. المشكلة مش في الكود، المشكلة في التداخل: سارة بنت قرارها على قيمة بقت قديمة (Stale) قبل ما تكتب.

وفيه 3 طرق تمنعها، وهنشرح كل واحدة بالتفصيل في الموضوع:

-- 1) خلّي الداتابيز تعمل الحسبة بنفسها في UPDATE واحد (ذرّي)
UPDATE products SET stock = stock - 1 WHERE id = 7 AND stock > 0;
-- لو رجع 0 rows يبقى المخزون خلص

-- 2) اقفل الصف وإنت بتقراه، فأي حد تاني عايز يقفله يستنى (Pessimistic)
SELECT stock FROM products WHERE id = 7 FOR UPDATE;

-- 3) اكتب بشرط إن محدش غيّر الصف من ساعة ما قريته (Optimistic)
UPDATE products SET stock = 0, version = version + 1
WHERE id = 7 AND version = 41;  -- لو 0 rows يبقى حد سبقك: اقرا تاني وجرّب

الـ Lost Update بتحصل في أي كود بيقرا قيمة، ويحسب عليها في الأبلكيشن، وبعدين يكتبها. وده أكتر Pattern منتشر في أي Backend.

4. الـ Concurrency Control بيعمل إيه؟

يعني فيه هدفين بيشدّوا عكس بعض:

• الصحة (Correctness): النتيجة لازم تساوي نتيجة تشغيل الترانزاكشنز بترتيب ما ورا بعض. ده اسمه Serializability، وليه درس كامل.
• الأداء (Throughput): أكبر عدد ترانزاكشنز في الثانية، وأقل وقت استنا.

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

وفيه تقنية تالتة بتتحط فوق الاتنين وموجودة في كل الداتابيز الحديثة: MVCC. بدل ما الصف يبقى ليه نسخة واحدة، بيبقى ليه كذا نسخة، فاللي بيقرا بيشوف نسخة قديمة ثابتة ومش محتاج يستنى اللي بيكتب. MySQL (InnoDB) و PostgreSQL الاتنين بيستخدموا MVCC للقراية + Locks للكتابة.

الـ Concurrency Control بيدوّر على أكبر توازي ممكن من غير ما النتيجة تختلف عن تشغيل الترانزاكشنز ورا بعض. والفرق بين كل التقنيات هو: بتمنع التعارض قبل ما يحصل، ولا بتكتشفه بعد ما يحصل.

5. أسئلة الإنترفيو