حدود المعاملات في قواعد البيانات: ماذا تضع في معاملة واحدة ومتى تقسّم

ماذا ستخرج به من هذا المقال؟

كل دالة تكتب في نظامك تتخذ قرارًا صامتًا: ما الذي يُحسم معًا، وما الذي يُترك للمصادفة. والقرار الخاطئ لا يظهر كاستثناء في السجل، بل كسلوك غريب يصعب تعليله: طلب يتأخر عند الذروة، رصيد لا يطابق كشف الحساب، أو مهمة ليلية تتجمّد فوق جدول مقفل. حدود BEGIN وCOMMIT وحدها تحدّد ذلك.

القاعدة التي تحسمه واضحة: المعاملة وُجدت لتبقي القيود على بياناتك صحيحة، لا لتغلّف الآثار الجانبية. وعليها نبني أمثلة لحدود المعاملة في الخدمات الموزعة، ثم المعاملة التعويضية لِأثرٍ لا يقبل التراجع، ثم مضاعفات القفل والإدخال.

القاعدة الذهبية: المعاملة تصون قيودًا، ولا تغلّف آثارًا

سلامة المعاملة ليست وعدًا للعالم، بل وعدًا بحدودك أنت: مجموعة الكتابات تُقرأ إمّا كاملة أو لا شيء. هذا هو الحد الأقصى لما تقدّمه المعاملة. أما نداء HTTP، أو رسالة إلى وسيط، أو بريد، أو استدعاء مصرف، فهي خارج النطاق ولا تملك مسار تراجع. خادم يوافق ثم ينقطع: المعاملة «تنجح» بينما العالم الخارجي معلّق في حالة لا يعرف أحد حالتها.

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

// داخل المعاملة: قيود على بياناتك وحدها

$db->transaction(function () use ($order, $lines) {

    $orders->insert($order);

    foreach ($lines as $line) {

        $stock->decrementOrFail($line->sku, $line->qty); // لا مخزون سالب

    }

    $outbox->append('order.created', ['order_id' => $order->id]);

});



// خارج المعاملة: آثار لا يملكها محرك قاعدة البيانات

$outbox->relay();                 // نشر الحدث إلى الوسيط

$mailer->send($order->id);       // إشعار المستخدم

$payments->initiate($order->id); // بوابة الدفع — أثر لا يُتراجَع

متى تكون المعاملة فخًا: الفتح الزائد والسقوط الزائد

الخطآن المتقابلان يبدوان متشابهين في مراجعة الكود، ويظهران معًا في الأنظمة كثيرة تغيّر أصحابها.

علامات الفتح الزائد

• نداء شبكي داخلها: زمن غير معروف ومصدر فشل لا تعرف حدوده.


• انتظار بشري: لا تفتح معاملة ثم تطلب من المستخدم بيانات.


• صفوف ساخنة مشتركة: عدّاد أو رصيد خزينة يلمسه كل طلب.


• حجم يتناسب مع المُدخل: عدد الأقفال يكبر مع عدد عناصر الطلب.


• خدمات داخلية متسلسلة: كل طبقة تبدأ معاملة، فتتكاثر بلا داعٍ.

علامات السقوط الزائد

• قيد تجاري ممزّق: قيد الرصيد يبقى صحيحًا فقط إذا حُسم الطرفان معًا؛ فصلهما يخلق حالة وسطى يراها المستخدم.


• قراءة ثم كتابة بلا قفل: تقرأ رصيدًا ثم تكتب بلا FOR UPDATE أو تحقق من نسخة.


• مفتاح تكرارية في معاملة أخرى: إن سُجّل بعيدًا عن الأثر الذي يحميه، فلم يحمِ شيئًا.

السؤال الفاصل: «إن فشل هذا السطر، هل يجب التراجع عن كل ما فوقه؟» إن كان الجواب لا — لأن السطر جذر مستقل — فهو حدّ معاملة. وإن كان نعم، فهو داخله.

حدود المعاملة عبر الخدمات الموزعة

متى تكفي معاملة محلية واحدة

إذا كان كل المشاركين في قاعدة واحدة يديرها مدير المعاملات نفسه، فالجواب المتين معاملة ACID واحدة. تقسيمها معاملتين ليس تحسّنًا معماريًا، بل فتح لباب لحالة وسطى لا يملكها أحد.

ساجا: معاملات محلية مع تعويض

عندما يشارك أكثر من مورد — قاعدتان، أو خدمة داخلية، أو طرف ثالث — لا يمكنك لفّهم في ذرّية واحدة. الحل العملي هو الساجا: كل خطوة معاملة محلية مستقلة، وفشل خطوة يُطلق خطوات تعويض. ولها شكلان: تلقائي (choreography) يتفاعل فيه المشاركون عبر الأحداث ويصلح لعدد صغير فقط، وتنسيقي (orchestration) تمسك فيه خدمة مركزية الحالة وتقرر الخطوة التالية. ويضاف إليه تنفيذ متين (durable execution) يخزّن سجل الخطوات، فيصبح كل commit حدًّا قابلًا للاستئناف.

متى يكون 2PC اختيارًا خاطئًا

المعاملة الموزعة على مرحلتين (XA) تعطي ذرّية حقيقية عبر الموارد، لكن ثمنها تشغيلي: القائد يصبح نقطة فشل وحيد، والأقفال تبقى محتجزة عبر الشبكة، وأقلّ المشاركين توافرًا يفرض على الجميع. الساجا مع Outbox ومفاتيح تكرارية تغطّي الحاجة العملية نفسها بتكلفة صيانة أفضل.

المعاملة التعويضية: تراجعٌ لا يتراجع

التعويض ليس ROLLBACK بمظهر جديد، بل خطوة أمامية جديدة تُعيد الحالة التجارية إلى معنى مقبول دون أن تمحو الأثر الذي سبق. الرسالة التي خرجت لا تعود، والرسوم التي اقتُرضت لا تُلغى، والبيان الصادر يبقى. فالتعويض يصحّح الدلالة لا السجل:

شرطان يعلوان كل تعويض: أن يكون قابلًا للتكرار بلا أثر (idempotent) لأنه سيُعاد بعد انقطاع الشبكة، وأن يكون محميًا بشرط مسبق واضح: كيف تعرف أنه لم يُنفَّذ بعد؟ الجواب المعتاد عمود حالة على الأصل (مثال: compensated_at) مع قيد تفرّد. والأهم: يُكتب التعويض في مسار العمل نفسه، لا في try/catch يبتلع الاستثناء.

مضاعفات القفل والإدخال

القيد الأقوى على المعاملة ليس زمن تنفيذها بل ما تسكه من أقفال وإصدارات. كل قفل يبقى محتجزًا حتى COMMIT، وكتلة تحديثات في نموذج MVCC تترك إصدارات ميتة لا تُنظَّف إلا بعد الالتزام. دفعة من عشرين ألف صف في معاملة واحدة تعني عشرين ألف قفل، وعشرين ألف نسخة ميتة، وانتشار ثنائيات يجب أن يمرّ كاملًا. والنتيجة تضخّم جداول، وتأخّر تنظيف vacuum، وتدهور تدريجي في الإنتاجية يبدو كأنه فشل في بنية تحتية.

القاعدة العملية: عدد الموارد التي تمسك أقفالها يبقى ثابتًا مهما كبر المُدخل. عالج ذلك بالدفعات: التزم، ثم ابدأ دفعة جديدة، مع علامة تقدّم للاستئناف.

-- الدفعة: 20k صف في معاملة واحدة = 20k قفل

UPDATE batch_results

   SET state = 'done'

 WHERE job_id = $1 AND state = 'pending'

 LIMIT 1000;      -- آخر الدفعة، ثم COMMIT، ثم التالية



-- ترتيب ثابت للقفل: يمنع الأمان بين عمليتين متعاكستين

SELECT id, balance FROM accounts

 WHERE id IN ($1, $2)

 ORDER BY id              -- الضمان هنا، لا في الكود

   FOR UPDATE;



-- بديل متفائل: تحقق من النسخة عند الكتابة

UPDATE accounts

   SET balance = balance - $1, version = version + 1

 WHERE id = $2 AND version = $3;  -- صفر صفوف = تعارض

مضاعف الإدخال (input amplification) هو الصورة المقابلة: الدالة ثابتة الحجم لكن مُدخلها ليس. استدعاء يمرّ على ثلاث خدمات داخلية تبدأ كل واحدة معاملتها = ثلاث معاملات بدل واحدة. وطلب بخمسمئة سطر ينفّذ خمسمئة UPDATE داخل معاملة واحدة = خمسمئة قفل. المعالجة: تجميع الكتابة في INSERT متعدد القيم، وإزالة التكرار قبل الحلقة.

وأخيرًا الأمان (deadlock): ليس عطلًا بل آلية حماية تختار ضحية وتُلغي معاملتها. الخطر ليس الحدث بل العاصفة التي تليه: عشرات المعاملات تُعاد محاولتها في اللحظة نفسها فتتضارب مجددًا.

ثلاثة أسئلة تضع الحد الصحيح

عند مراجعة أي دالة تكتب في القاعدة، اطرح ثلاثة أسئلة بالترتيب: هل يجب أن يفشل كل ما في هذه المعاملة معًا إن فشل أحدها؟ إن كان لا، فضع حدًّا عند هذا السطر. هل تحتاج إحدى الخطوات إلى مورد خارج القاعدة؟ عندئذ افصل بالضبط عند تلك الخطوة. وهل عدد الأقفال يبقى ثابتًا مهما كبر حجم الطلب؟

أخطاء شائعة

قائمة تحقق

• لكل دالة كتابة: أجب في جملة واحدة عن سبب ضمّ هذه السطور إلى معاملة واحدة.


• ابحث في مسارات المعاملات عن أي استدعاء شبكة أو ناشر رسائل، وأخرجه بحدّ صريح.


• رتّب الأقفال في الاستعلام نفسه لا في ترتيب تنفيذ الشيفرة.


• قسّم كل عملية جماعية إلى دفعات قابلة لإعادة التنفيذ بعد الانقطاع.


• اجعل كل خطوة تعويضية قابلة للتكرار ومكتوبة في سجل، لا في ذاكرة العملية.


• راقب زمن المعاملة وعدد الأقفال لكل معاملة، قبل أن يراقبك المستخدمون.

الأسئلة الشائعة

كيف أكتشف أن معاملتي أوسع من اللازم دون انتظار الإنتاج؟

راقب زمن المعاملة عند المئين التسعين: إن اقترب من مئات الأجزاء من الألف من الثانية، فأنت تحمل قفلًا تجاريًا طويلًا. وقس عدد الصفوف المُعدَّلة لكل معاملة: إن كان يتبع حجم الطلب، فالحد مشكّل خطأ.

أستخدم ORM يغلّف كل شيء بمعاملة واحدة، كيف أضع حدًا صحيحًا؟

المشكلة ليست الأداة بل مستوى فتح المعاملة. اجعل المعاملة تطابق حالة استخدام كاملة، لا جدولًا واحدًا ولا استعلامًا واحدًا. في أطر مثل Laravel استخدم DB::transaction() حول خدمة حالة الاستخدام، وأبقِ الاستدعاء الشبكي خارج الإغلاق.

هل المعاملة الموزعة (2PC) هي الحل حين تتعدد قواعد البيانات؟

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

الخلاصة

الخطوة التالية

حدود المعاملة تحدد ما الذي يُحسم معًا؛ والسؤال التالي هو كيف ترى هذه المعاملات بعضها بعضًا عندما تتزامن. ابدأ بمستويات العزل: ما الفرق بين READ COMMITTED وREPEATABLE READ وSERIALIZABLE، ولماذا ينتج SERIALIZATION_FAILURE وأنت لم تكتب شيئًا متعارضًا.

كيف تستخدم هذا المقال في عمل حقيقي؟

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

flowchart LR

    A["طلب المستخدم"]

    B["التحقق من المدخلات"]

    C["خدمة الأعمال"]

    D["المعاملات والتخزين"]

    E["الاستجابة والمراقبة"]

    A --> B

    B --> C

    C --> D

    D --> E