18 أبريل 2025·7 دقيقة
جيم غراي، معالجة المعاملات، ولماذا لا تزال مبادئ ACID مهمة
نظرة عملية على أفكار جيم غراي في معالجة المعاملات ولماذا تستمر مبادئ ACID في جعل البنوك، التجارة، وأنظمة SaaS موثوقة.
نظرة عملية على أفكار جيم غراي في معالجة المعاملات ولماذا تستمر مبادئ ACID في جعل البنوك، التجارة، وأنظمة SaaS موثوقة.
كان جيم غراي عالِم حاسوب مهووسًا بسؤال يبدو بسيطًا: عندما يستخدم الكثير من الناس النظام في نفس الوقت — والفشل أمر لا مفر منه — كيف تبقي النتائج صحيحة؟
عمله في معالجة المعاملات ساعد على تحويل قواعد البيانات من "أحيانًا صحيحة إذا كنت محظوظًا" إلى بنى تحتية يمكنك فعلاً بناء عمل تجاري عليها. الأفكار التي روّج لها — خصوصًا خصائص ACID — تظهر في كل مكان، حتى لو لم تذكر كلمة "معاملة" في اجتماع منتج.
النظام الموثوق هو الذي يمكن للمستخدمين أن يعتمدوا على نتائجه، وليس فقط على الشاشات.
بعبارة أخرى: أرصدة صحيحة، طلبات صحيحة، ولا سجلات مفقودة.
حتى المنتجات الحديثة التي تستخدم الطوابير والميكروسيرفيسز ومزودي الدفع الخارجيين لا تزال تعتمد على تفكير المعاملات في لحظات حاسمة.
سنحافظ على المفاهيم عملية: ما الذي تحميه ACID، أين تختبئ الأخطاء عادة (العزل والتزامن)، وكيف تجعل السجلات والاسترداد الأعطال قابلة للتحمل.
سنغطي أيضًا الموازنات الحديثة — أين ترسم حدود ACID، متى تستحق المعاملات الموزعة التعقيد، ومتى تقدم أنماط مثل الساغا، والمحاولات، والإيدمبوتنسي تناسقًا "جيدًا بما فيه الكفاية" دون إفراط في التصميم.
المعاملة هي طريقة للتعامل مع إجراء تجاري متعدد الخطوات كوحدة "نعم/لا" واحدة. إذا نجح كل شيء، تُلزَم؛ إذا حدث أي خطأ، تُلغى كما لو لم تحدث.
تخيّل نقل 50$ من الحساب الجاري إلى التوفير. هذا ليس تغييرًا واحدًا؛ هو على الأقل اثنان:
إذا كان نظامك يجري "تحديثات خطوة واحدة" فقط، فقد ينجح في الطرح ثم يفشل قبل الإضافة. الآن العميل ناقصه 50$ — وتبدأ تذاكر الدعم.
إتمام الشراء المعتاد يشمل إنشاء الطلب، حجز المخزون، تفويض الدفع، وتسجيل الإيصال. كل خطوة تمس جداول مختلفة (أو حتى خدمات مختلفة). بدون تفكير المعاملة، قد ينتهي بك الأمر بطلب معنَّم "مدفوع" لكن لا مخزون محجوز — أو مخزون محجوز لطلب لم يُنشأ أصلاً.
الفشل نادرًا ما يحدث في لحظات مريحة. نقاط الكسر الشائعة:
توجد معالجة المعاملات لضمان وعد بسيط: إما أن تؤثر كل خطوات الإجراء التجاري معًا، أو لا تؤثر إطلاقًا. هذا الوعد هو الأساس للثقة — سواء كنت تنقل مالًا، تضع طلبًا، أو تغيّر خطة اشتراك.
ACID هو قائمة تحقق من الحمايات التي تجعل "المعاملة" تبدو موثوقة. ليس مصطلح تسويقي؛ إنه مجموعة وعود حول ما يحدث عندما تغيّر بيانات مهمة.
تعني الذرية أن المعاملة إما تكتمل بالكامل أو لا تترك أثرًا.
فكّر في تحويل بنكي: تخصم 100$ من الحساب A وتقيد 100$ في الحساب B. إذا تحطّم النظام بعد الخصم وقبل القيد، تضمن الذرية أن تتحقق إما التراجع عن الخصم أو إتمام التحويل بالكامل. لا يوجد حالة نهاية صحيحة يحدث فيها جانب واحد فقط.
التناسق يعني أن قواعد بياناتك (القيود والثوابت) تبقى صحيحة بعد كل معاملة ملتزمة.
أمثلة: لا يمكن أن يصبح الرصيد سالبًا إذا كان منتجك يمنع السحب على المكشوف؛ مجموع الخصومات والقيود في تحويل يجب أن يتطابق؛ مجموع الطلب يجب أن يساوي عناصر السطر زائد الضريبة. التناسق جزء منه وظيفة قاعدة البيانات (القيود)، وجزء آخر وظيفة التطبيق (قواعد العمل).
يحمي العزل عندما تحدث معاملات متعددة في نفس الوقت.
مثال: عميلان يحاولان شراء الوحدة الأخيرة من عنصر. بدون عزل مناسب، كلاهما قد "يرى" المخزون = 1 وكلاهما ينجح، تاركًا المخزون عند -1 أو مجبرًا على تصحيح يدوي فوضوي.
يعني الدوام أنه بمجرد رؤية "ملتزم"، لن يختفي النتيجة بعد تعطل أو فقدان للطاقة. إذا قال الإيصال إن التحويل نجح، يجب أن يظهر الدفتر المحاسبي ذلك بعد إعادة التشغيل.
"ACID" ليس مفتاح تشغيل/إيقاف واحد. أنظمة ومستويات عزل مختلفة تقدم ضمانات مختلفة، وغالبًا تختار أي الحمايات تنطبق على أي عمليات.
عندما يتكلم الناس عن "المعاملات"، البنوك هي المثال الأوضح: المستخدمون يتوقعون أن تكون الأرصدة صحيحة دائمًا. تطبيق بنكي يمكن أن يكون أبطأ قليلًا؛ لا يمكن أن يكون خاطئًا. خطأ واحد في الرصيد يمكن أن يطلق رسوم سحب على المكشوف، دفعات مفقودة، وسلسلة طويلة من العمل اللاحق.
التحويل البنكي البسيط ليس إجراءً واحدًا — هو عدة خطوات يجب أن تنجح أو تفشل معًا:
تفكير ACID يعامل ذلك كوحدة واحدة. إذا فشلت أي خطوة — زلة شبكة، تعطل خدمة، خطأ تحقق — يجب ألا "ينجح جزئيًا". وإلا ستحصل على مال مفقود من A دون الظهور في B، أو مال في B دون قيد مطابق، أو بلا سجل تدقيق يشرح ما حدث.
في العديد من المنتجات، يمكن تصحيح عدم التناسق لاحقًا في الإصدار التالي. في البنوك، "الإصلاح لاحقًا" يتحول إلى نزاعات، تعرّض تنظيمي، وعمليات يدوية. تزداد تذاكر الدعم، ويُستدعى المهندسون لمكالمات الحوادث، وتقضي فرق العمليات ساعات في المصالحات.
حتى لو أمكنك تصحيح الأرقام، ستحتاج لا تزال إلى شرح التاريخ.
لهذا تعتمد البنوك على دفاتر الحسابات وسجلات الإضافة فقط: بدلًا من الكتابة فوق التاريخ، يسجلون سلسلة من الخصومات والقيود التي تضيف بعضها البعض. السجلات الثابتة ومسارات التدقيق الواضحة تجعل الاسترداد والتحقيق ممكنين.
المصالحة — مقارنة مصادر حقائق مستقلة — تعمل كشبَك أمان عندما يحدث خطأ، وتساعد الفرق في تحديد متى وأين حدث اختلاف.
الصواب يشتري الثقة. كما أنه يقلل حجم الدعم ويسرّع الحل: عندما يحدث خطأ، مسار تدقيق نظيف وإدخالات دفتر متسقة تسمح بالإجابة على "ماذا حدث؟" بسرعة، وإصلاحه دون تخمين.
التجارة الإلكترونية تبدو بسيطة حتى تصل إلى ذروة المرور: نفس العنصر الأخير في عشر سلات، العملاء يعيدون التحميل، ومزود الدفع يتعطل مؤقتًا. هنا يظهر تفكير معالجة المعاملات العملي وغير المثير.
الإتمام المعتاد يمس حالات متعددة: حجز المخزون، إنشاء الطلب، والقبض على الدفع. تحت تزامن عالٍ، كل خطوة يمكن أن تكون صحيحة بمفردها ومع ذلك تنتج نتيجة سيئة إجمالًا.
إذا نقصت المخزون بدون عزل، يمكن لعمليتي دفع أن تقرأا "1 متبقي" وكلاهما ينجح — مرحبًا بالبيع الزائد. إذا قبضت الدفع ثم فشلت في إنشاء الطلب، فشحن العميل بدون شيء يفي به.
ACID يساعد أكثر على حدود قاعدة البيانات: غلّف إنشاء الطلب وحجز المخزون في معاملة قاعدة بيانات واحدة حتى يلتزما معًا أو يتراجعا معًا. يمكنك أيضًا فرض الصواب عبر قيود (مثلاً "المخزون لا يمكن أن ينخفض عن صفر") حتى ترفض قاعدة البيانات الحالات المستحيلة حتى لو أخطأ كود التطبيق.
الشبكات تفقد الاستجابات، المستخدمون ينقرون مرتين، والمهام الخلفية تُعيد المحاولة. لهذا السبب معالَجة "مرة واحدة بالضبط" صعبة عبر الأنظمة. يصبح الهدف: مرة واحدة على الأكثر لتحريك المال، ومحاولات آمنة في كل مكان آخر.
استخدم مفاتيح إيدمبوتنسي مع مزود الدفع واحفظ سجلًا دائمًا "لنية الدفع" مرتبطًا بطلبك. حتى لو أعاد خدمتك المحاولة، لن تُحاسَب مرتين.
المرتجعات، الاستردادات الجزئية، والاعتراضات هي حقائق تجارية وليست حواف. تجعل حدود المعاملة الواضحة الأمور أسهل: يمكنك ربط كل تعديل بثقة إلى طلب، ودفع، ومسار تدقيق — لذا المصالحة قابلة للشرح عندما يحدث خطأ.
تعيش شركات SaaS على وعد: ما يدفعه العميل هو ما يمكنه استخدامه، فورًا وبشكل متوقع. يبدو ذلك بسيطًا حتى تخلط ترقيات/تخفيضات الخطط، التعديل منتصف الدورة، الاستردادات، وأحداث الدفع اللامتزامنة. يساعد تفكير على طريقة ACID في إبقاء "حقيقة الفوترة" و"حقيقة المنتج" متوافقتين.
تغيير الخطة غالبًا ما يطلق سلسلة من الإجراءات: إنشاء أو تعديل فاتورة، تسجيل التعديل (proration)، محاولة التحصيل، وتحديث الحقوق (ميزات، مقاعد، حدود). عامل هذه كواحد وحدة عمل حيث النجاح الجزئي غير مقبول.
إذا أنشئت فاتورة للترقية لكن لم تُحدَّث الحقوق (أو العكس)، إما يخسر العملاء وصولًا دفعوا ثمنه أو يحصلون على وصول لم يدفعوا مقابله.
نمط عملي هو حفظ قرار الفوترة (الخطة الجديدة، تاريخ السريان، سطور التعديل) وقرار الحقوق معًا، ثم تشغيل عمليات لاحقة من ذلك السجل الملتزم. إذا وصلت تأكيدات الدفع لاحقًا، يمكنك تحريك الحالة بأمان دون إعادة كتابة التاريخ.
في أنظمة متعددة المستأجرين، العزل ليس مسألة أكاديمية: نشاط أحد العملاء الكثيف يجب ألا يعيق أو يفسد بيانات آخر. استخدم مفاتيح نطاق المستأجر، حدود معاملة واضحة لكل مستأجر، ومستويات عزل مختارة بعناية حتى لا يخلق تدفق تجديدات Tenant A قراءات غير متسقة لـ Tenant B.
تبدأ تذاكر الدعم عادة بـ "لماذا تم تحميلي؟" أو "لماذا لا أستطيع الوصول إلى X؟" حافظ على سجل تدقيق قابل للإضافة فقط بمن الذي غيّر ماذا ومتى (مستخدم، مسؤول، أتمتة)، واربطه بالفواتير وتحولات الحقوق.
هذا يمنع الانجراف الصامت — حيث تقول الفواتير "Pro" لكن الحقوق لا تزال "Basic" — ويجعل المصالحة استعلامًا، لا تحقيقًا.
العزل هو حرف الـ I في ACID، وهو المكان الذي كثيرًا ما تفشل فيه الأنظمة بطرق دقيقة ومكلفة. الفكرة الأساسية بسيطة: كثير من المستخدمين يتصرفون في الوقت نفسه، لكن كل معاملة يجب أن تتصرف كما لو أنها نفذت بمفردها.
تخيّل متجرًا به صرافان وعنصر أخير على الرف. إذا تحقق كلا الصرافين من المخزون في نفس الوقت ورأيا "1 متاح"، قد يبيع كل منهما العنصر. لم يحدث تعطل، لكن النتيجة خاطئة — مثل الإنفاق المزدوج.
تواجه قواعد البيانات نفس المشكلة عندما تقرأ معاملتان وتحدّثان نفس الصفوف بالتزامن.
تختار معظم الأنظمة مستوى عزل كتجارة بين الأمان والإنتاجية:
إذا كان الخطأ يسبب خسارة مالية أو تعرّضًا قانونيًا أو عدم اتساق ظاهر للعملاء، انجِر نحو عزل أقوى (أو قفل/قيود صريحة). إذا أسوأ سيناريو هو خلل واجهة مؤقت، قد يكفي مستوى أضعف.
العزل الأعلى قد يقلل الإنتاجية لأن القاعدة تحتاج إلى مزيد من التنسيق — انتظار، قفل، أو إلغاء/إعادة المحاولة — لمنع التداخلات غير الآمنة. التكلفة حقيقية، لكن كذلك تكلفة البيانات غير الصحيحة.
عندما يتعطل النظام، السؤال الأهم ليس "لماذا تعطل؟" بل "ما الحالة التي ينبغي أن نكون عليها بعد إعادة التشغيل؟" عمل جيم غراي في معالجة المعاملات جعل الإجابة عملية: الدوام يتحقق من خلال سجلات واسترداد منضبط.
سجل المعاملات (غالبًا يُدعى WAL) هو سجل قابل للإضافة فقط للتغييرات. إنه مركزي للاسترداد لأنه يحفظ النية وترتيب التحديثات حتى لو كانت ملفات البيانات نصف مكتوبة عند فقدان الطاقة.
أثناء إعادة التشغيل، يمكن لقاعدة البيانات:
لهذا السبب يمكن أن يظل "لقد التزمنا" صحيحًا حتى عندما لا يغلق الخادم بشكل نظيف.
التسجيل قبل الكتابة يعني: يُفرَغ السجل إلى تخزين دائم قبل أن يُسمح بكتابة صفحات البيانات. عمليًا، يُرتبط "الالتزام" بضمان أن سجلات المعاملة ذات الصلة على القرص بأمان (أو بطريقة أخرى دائمة).
إذا وقع انهيار بعد الالتزام مباشرةً، يمكن للاسترداد إعادة تشغيل السجل وإعادة بناء الحالة الملتزم بها. إذا وقع الانهيار قبل الالتزام، يساعد السجل على التراجع.
النسخة الاحتياطية هي لقطة (نسخة في نقطة زمنية). السجلات هي تاريخ (ما تغيّر بعد تلك اللقطة). تساعد النسخ الاحتياطية في حالات الفقد الكارثي (نشر خاطئ، حذف جدول، برمجيات فدية). تساعد السجلات على استعادة العمل الملتزم حديثًا وتدعم الاستعادة إلى نقطة زمنية: استعد النسخة الاحتياطية ثم أعد تشغيل السجلات حتى لحظة مختارة.
النسخة الاحتياطية التي لم تُجرَ لها استعادة هي أمل، ليست خطة. جدولة اختبارات استعادة منتظمة في بيئة مرحلة، تحقق من فحوص سلامة البيانات، ووقت مدة الاسترداد فعليًا. إذا لم تلبِ احتياجات RTO/RPO، عدّل الاحتفاظ، أو إرسال السجلات، أو تكرار النسخ الاحتياطية قبل أن يفرض حادث الدرس.
تعمل ACID أفضل عندما تستطيع قاعدة بيانات واحدة أن تقوم بدور "مصدر الحقيقة" للمعاملة. اللحظة التي تنشر فيها إجراءًا تجاريًا عبر خدمات متعددة (المدفوعات، المخزون، البريد الإلكتروني، التحليلات)، تدخل إلى مجال الأنظمة الموزعة — حيث لا تبدو الأعطال كـ "نجاح" أو "خطأ" نظيف.
في إعداد موزع، يجب أن تفترض أعطالًا جزئية: قد يلتزم طرف بينما يتعطل آخر، أو تختفي الشبكة وتخفي النتيجة الحقيقية. الأسوأ من ذلك، المهل غامضة — هل الجانب الآخر فشل أم أنه بطيء؟
تنتج عن هذه اللايقين عمليات الشحن المزدوج، البيع الزائد، والحقوق المفقودة.
تحاول المصادقة ذات المرحلتين (Two-phase commit) جعل قواعد بيانات متعددة تلتزم "كواحدة".
غالبًا ما يتجنب الفرق 2PC لأنه قد يكون بطيئًا، يحتفظ بالأقفال لفترة أطول (يضر بالإنتاجية)، ويمكن أن يصبح المنسق عنق زجاجة. كما يقترن الأنظمة بقوة: جميع المشاركين يجب أن يتحدثوا البروتوكول ويبقوا متاحين.
النهج الشائع هو الحفاظ على حدود ACID صغيرة وإدارة العمل عبر الخدمات صراحةً:
ضع أقوى الضمانات (ACID) داخل قاعدة بيانات واحدة كلما أمكن، وتعامل مع كل ما وراء تلك الحدود كتنسيق مع محاولات، مصالحة، وسلوك واضح لـ "ماذا يحدث إذا فشلت هذه الخطوة؟".
نادراً ما تظهر الأعطال كـ "لم يحدث شيء". في أغلب الأحيان، ينجح الطلب جزئيًا، ينتهي مهلة العميل، ويعاود شخص ما (متصفح، تطبيق هاتف، مجدول وظائف، أو نظام شريك). دون احتياطات، تخلق المحاولات أسوأ أنواع الأخطاء: كود يبدو صحيحًا لكنه أحيانًا يخصم مرتين، يرسل مرتين، أو يمنح وصولًا مرتين.
الإيدمبوتنسي هي الخاصية التي تجعل تنفيذ نفس العملية عدة مرات يعطي نفس النتيجة النهائية كما لو نُفِّذ مرة واحدة. للأنظمة المواجهة للمستخدم، هي "محاولات آمنة بدون تأثير مزدوج".
قاعدة مفيدة: GET يجب أن يكون طبيعيًا إيدمبوتنت؛ العديد من POST ليست كذلك ما لم تصممها لذلك.
عادةً تجمع بين عدة آليات:
Idempotency-Key: ...). يخزن الخادم النتيجة مربوطًا بذلك المفتاح ويعيد نفس النتيجة عند التكرار.order_id).تعمل هذه أفضل عندما يكون فحص التفريد والتأثير داخل نفس معاملة قاعدة البيانات.
المهلة لا تعني أن المعاملة تراجعت؛ قد تكون التزمت لكن الرد ضاع. لهذا يجب أن تفترض منطق المحاولات أن الخادم قد يكون نجح.
نمط شائع: اكتب سجل إيدمبوتنسي أولًا (أو اقفله)، نفّذ الآثار الجانبية، ثم علمه مُكتملًا — كل ذلك ضمن معاملة عندما يكون ممكنًا. إذا لم تستطع إدراج كل شيء في معاملة واحدة (مثلاً استدعاء بوابة دفع)، احفظ "نية" دائمة وصالح للمصالحة لاحقًا.
عندما "يبدو" النظام هشًا، السبب الجذري غالبًا فكر المعاملة المكسور. الأعراض النموذجية تشمل طلبات شبحية تظهر بدون دفع مطابق، مخزون سالب بعد عمليات دفع متزامنة، ومجاميع غير متطابقة حيث لا تتفق الدفاتر والفواتير والتحليلات.
ابدأ بكتابة ثوابتك — الحقائق التي يجب أن تكون صحيحة دائمًا. أمثلة: "لا ينخفض المخزون عن الصفر"، "الطلب إما مدفوع أو غير مدفوع (ليس كلاهما)"، "كل تغيير في الرصيد له قيد دفتر مقابل".
بعد ذلك حدد حدود المعاملة حول أصغر وحدة يجب أن تكون ذرية لحماية تلك الثوابت. إذا لمسة إجراء مستخدم واحد عدة صفوف/جداول، قرر ما الذي يجب أن يلتزم معًا وما يمكن تأجيله بأمان.
أخيرًا، اختر كيف ستتعامل مع الصراعات تحت الحمل:
أخطاء التزامن نادرًا ما تظهر في اختبارات المسار السعيد. أضف اختبارات تخلق ضغطًا:
لا يمكنك حماية ما لا تقيسه. إشارات مفيدة تشمل الانسدادات (deadlocks)، زمن انتظار القفل، معدلات التراجع (خاصة الطفرات بعد النشر)، وفروق المصالحة بين جداول مصدر الحقيقة (دفتر الحسابات مقابل الأرصدة، الطلبات مقابل المدفوعات). هذه المقاييس غالبًا ما تحذرك قبل أسابيع من أن العملاء سيبلغوا عن "المال المفقود" أو المخزون المفقود.
جيم غراي كان عالِم حاسوب ساهم في جعل معالجة المعاملات عملية ومفهومة على نطاق واسع. إرثه هو عقلية أن العمليات متعددة الخطوات المهمة (نقل الأموال، إتمام الشراء، تغييرات الاشتراك) يجب أن تُنتج نَتائج صحيحة حتى في ظروف التزامن والفشل.
بمصطلحات المنتج اليومية: حالات "الحالة الغامضة" أقل، وحرائق المصالحات أقل، وضمانات أوضح لما يعنيه "تم الالتزام" فعلاً.
المعاملة تجمع تحديثات متعددة في وحدة "كلها أو لا شيء". تقوم بالالتزام عندما تنجح كل الخطوات؛ وتقوم بالتراجع عندما يفشل أي جزء.
أمثلة نموذجية:
ACID مجموعة ضمانات تجعل المعاملات موثوقة:
هذا ليس مفتاح تشغيل/إيقاف واحد — تختار أين تحتاج هذه الضمانات ومدى قوتها.
معظم أخطاء "يحدث فقط في الإنتاج" تأتي من عزل ضعيف تحت الحمل.
أنماط الفشل الشائعة:
حل عملي: اختر مستوى عزل بناءً على مخاطرة الأعمال، واستخدم قيود/قفل كحماية إضافية عند الحاجة.
ابدأ بكتابة الثوابت (invariants) باللغة البسيطة — ما الذي يجب أن يكون دائمًا صحيحًا — ثم احمِها في أصغر نطاق معاملة ممكن.
آليات تعمل جيدًا معًا:
عامل القيود كشبَك أمان عندما يخفق كود التطبيق تحت التزامن.
سجّل المقدمات قبل الكتابة (WAL) هو كيف تجعل قواعد البيانات "الالتزام" يصمد بعد الأعطال.
عمليًا:
لهذا السبب قابلية الالتزام للدوام تتحقق عبر سجلات المعاملات.
النسخ الاحتياطي لقطة زمنية؛ السجلات هي تاريخ التغييرات بعد تلك اللقطة.
وضع عملي للتعافي:
إذا لم تختبر الاستعادة، فخطة الاستعادة مجرد أمل.
المعاملات الموزعة تحاول جعل أنظمة متعددة تلزم نفسها كواحدة، لكن الفشل الجزئي وعدم اليقين حول المهلات يجعل الأمر صعبًا.
اثنان من العيوب العملية لـ 2PC:
استخدمه فقط عندما تحتاج فعلاً لذرة عبر الأنظمة وتستطيع تحمل التعقيد التشغيلي.
فضل حدود ACID صغيرة محليًا وتنسيقًا صريحًا بين الخدمات.
أنماط شائعة:
هذا يعطي سلوكًا متوقعًا تحت المحاولات المتكررة والأعطال دون تحوّل كل سير عمل إلى قفل عالمي.
افترض أن المهلة قد تعني "نجحت لكنك لم تسمع النتيجة". صمم المحاولات لتكون آمنة.
أدوات تمنع التكرار:
الممارسة الأفضل: احتفظ بفحص إزالة التكرار وتغيير الحالة داخل نفس معاملة قاعدة البيانات كلما أمكن.