الالتزام (إدارة البيانات)

يُعدّ بروتوكول الالتزام ثنائي المرحلة النهج الأكثر شيوعًا وشمولًا للمعاملات الموزعة، إذ يتضمن مرحلتين: مرحلة التحضير ومرحلة الالتزام. ^{[ 1 ]} صُمم هذا البروتوكول لتمكين منسق قاعدة البيانات من تحديد ما إذا كانت جميع العُقد المشاركة متفقة. في مرحلة التحضير، يُرسل منسق قاعدة البيانات طلبًا بالاستعداد للالتزام إلى جميع العُقد المشاركة في المعاملة. أما مرحلة الالتزام، فهي التزام شامل بعد أن تصبح جميع العُقد المشاركة جاهزة، وفي حال عدم التوصل إلى اتفاق، تتراجع جميع العُقد عن المعاملة وتُلغي جميع العمليات السابقة.

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

بروتوكول الالتزام ثلاثي المراحل هو بروتوكول مُحسَّن غير مانع يعتمد على بروتوكول الالتزام ثنائي المراحل (2PC)، وينقسم إلى ثلاث مراحل: التحضير، ما قبل الالتزام، والالتزام. في البداية، تُرسل كل عقدة طلب "تحضير". بعد التأكيد، تُضاف مرحلة "ما قبل الإرسال". عند هذه النقطة، تكون كل عقدة قد أنجزت معظم أعمال التحضير وتنتظر التأكيد النهائي. أخيرًا، في مرحلة الالتزام الرسمي، وبعد أن تُرسل جميع العقد طلب "التزام"، تُستكمل المعاملة ويتم الالتزام بها. بالمقارنة مع بروتوكول الالتزام ثنائي المراحل (2PC)، يُحسِّن هذا البروتوكول آلية المهلة الزمنية، ويتجنب مشكلة الحظر الناتجة عن نقطة فشل واحدة، ويُحسِّن موثوقية النظام. ^{[ 3 ]}

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

الالتزام المفترض (PC) هو الوضع الافتراضي الذي يفترض نجاح المعاملة وإشعار التراجع ما لم يُصادف خلل. يقلل هذا الالتزام من حجم الرسائل وتكاليف التسجيل للالتزامات العادية. أما الإلغاء المفترض (PA) فيفترض أن الحالة الافتراضية للمعاملة هي التراجع، ولن يتم الالتزام بها إلا بعد موافقة جميع العُقد صراحةً. ^{[ 2 ]} ينطبق هذا الالتزام على المعاملات التي لا يتم تحديثها بشكل متكرر أو التي يكون احتمال نجاح التزامها منخفضًا. كان نظام إدارة قواعد البيانات الموزعة IBM R* أول من اقترح وطبّق بروتوكولي الالتزام المفترض والإلغاء المفترض، حيث تعامل مع إدارة المعاملات الموزعة بكفاءة عالية، وأصبح مثالًا كلاسيكيًا في مجال إدارة معاملات قواعد البيانات. ^{[ 2 ]}

مع ازدياد انتشار الإنترنت، تواجه بروتوكولات الالتزام السابقة تحديات جديدة، لا سيما في بيئات الأجهزة المحمولة ذات الشبكات غير المستقرة. إذ يمكن أن تؤثر فترات انتظار المعاملات الطويلة جدًا سلبًا على تجربة المستخدم. يسمح بروتوكول الالتزام التفاؤلي للمعاملة بالوصول مؤقتًا إلى البيانات غير الملتزم بها قبل الالتزام لتجنب فترات الانتظار. ^{[ 7 ]} يُناسب هذا النوع من الالتزام بيئات التنافس الشديد، ولكن في حال فشل المعاملة، يلزم تنفيذ معاملات تعويضية إضافية لتحقيق الذرية الدلالية وضمان اتساق البيانات النهائي. ^{[ 6 ]} بمجرد أن يكتشف نظام التعويض فشل المعاملة، فإنه يُنفذ على الفور معاملة خاصة أخرى ويتراجع عن العملية المؤقتة السابقة لاستعادة البيانات إلى حالتها المتسقة قبل المعاملة. يستخدم بروتوكول الالتزام التفاؤلي، الذي طوره ليفي وآخرون (1991)، معاملات تعويضية لحل مشكلة الانتظار غير المحدد التي قد تواجهها بروتوكولات الالتزام التقليدية ثنائية المرحلة، ويُحسّن أداء النظام.

يُعدّ تسجيل البيانات أحد أهم وسائل استعادة البيانات بعد الأعطال. إذ تُسجّل كل عقدة مشاركة في قاعدة البيانات كل خطوة من خطوات المعاملة في الوقت الفعلي، بما في ذلك بدء المعاملة، وتحديث البيانات، وإتمامها، وإنهاء المعاملة. تُسمى هذه السجلات "سجلات البيانات". عندما يتعطل النظام أو يتوقف بشكل غير طبيعي، تصبح البيانات غير متناسقة وفوضوية. في هذه الحالة، تلعب سجلات البيانات دورًا هامًا. إذ يُمكن لنظام قاعدة البيانات استعادة حالته المتناسقة قبل العطل بسرعة من خلال قراءة سجلات البيانات المسجلة قبل حدوثه. تنقسم طريقة الاستعادة هذه إلى إعادة التنفيذ والتراجع. لضمان حفظ البيانات المُحدّثة بشكل صحيح، يستخدم النظام تقنية تُعرف باسم "إعادة التنفيذ" لإعادة تنفيذ خطوات المعاملة المُوثّقة في السجل بعد التحقق من إتمامها. ^{[ 2 ]} بينما يستخدم النظام ميزة تُعرف باسم "التراجع" للتأكد من التراجع الكامل عن جميع الإجراءات في حال حدوث خطأ في إتمام المعاملة. ^{[ 2 ]} يُستخدم تسجيل البيانات على نطاق واسع في العديد من أنظمة قواعد البيانات الرئيسية، بما في ذلك قاعدة بيانات IBM R*، مما يضمن موثوقية البيانات بشكل فعّال.

في بروتوكول الالتزام التفاؤلي، قد تستخدم المعاملة البيانات قبل إتمامها، مما يُحسّن الكفاءة، ولكن فقط في حال إتمامها بنجاح. عندما تفشل المعاملة أو تُجهض، قد تكون البيانات المُعدّلة غير متسقة. لذلك، يُطرح مفهوم المعاملات التعويضية. ^{[ 7 ]}

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

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

تُوفّر آلية المهلة الزمنية حلاً لمشكلة التعطيل. يتم تحديد حد أقصى للمهلة الزمنية في هذه الآلية. عندما يتجاوز وقت انتظار المعاملة الوقت المحدد مسبقًا، يُحدد النظام تلقائيًا فشل المعاملة، ويتراجع عنها، ويُحرر موارد البيانات المُستخدمة، مما يمنع فعليًا طول وقت انتظار النظام ككل. تُستخدم آلية المهلة الزمنية عادةً في بروتوكول الالتزام ثلاثي المراحل (3PC)، مما يُقلل بشكل فعال من مشكلة طول وقت الانتظار والتعطيل في المعاملات الموزعة، ويتجنب ظاهرة استهلاك موارد النظام لفترة طويلة. ^{[ 3 ]} تُنفذ آلية المهلة الزمنية عادةً بالتزامن مع آلية الاستعلام عن الحالة للكشف عما إذا كانت العقدة لا تزال نشطة، مما يزيد من قدرة النظام على تحمل الأعطال.

تتطلب المعاملات التي يُجريها النظام المصرفي عادةً تدفقات مالية بين حسابات متعددة، ويجب أن تكون كل معاملة دقيقة للغاية، لا سيما في عمليات التحويل والدفع عبر المناطق. أي خطأ في البيانات أو في نقاط الربط سيؤدي إلى خسارة الأموال. على سبيل المثال، عند تحويل الأموال إلى صديق عبر الخدمات المصرفية عبر الهاتف المحمول ، يعمل نظام معالجة البنك فعليًا على عدة خوادم قواعد بيانات في الوقت نفسه لإتمام المعاملة.

يضمن بروتوكول الالتزام نجاح كل عملية تحويل مصرفي بشكل كامل، وعدم تنفيذها نهائيًا. تحافظ هذه الآلية على دقة العمليات المصرفية وتمنع فقدان الأموال أو بيانات الحسابات. يُستخدم بروتوكول الالتزام ثنائي المرحلة (2PC) بشكل شائع في الأنظمة المصرفية حول العالم، وهو حل قياسي معترف به من قبل البنوك والأنظمة المالية لضمان دقة وموثوقية المعاملات، لا سيما في معاملات التحويل عبر الحدود. ^{[ 1 ]} من خلال هذا الاتفاق، يمكن للبنك تجنب الاختلافات في أرصدة حسابات المستخدمين والحد بشكل كبير من مخاطر فقدان ممتلكات العملاء.

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

مع ذلك، غالبًا ما تواجه الأجهزة الإلكترونية انقطاعات أو عدم استقرار في الشبكة، ولذا تُستخدم بروتوكولات الالتزام التفاؤلي على نطاق واسع في هذا السياق. يسمح هذا البروتوكول للمعاملات باستخدام البيانات المؤقتة أولًا، ثم تعويض التغييرات التي أُجريت قبل التراجع عن المعاملة في حال فشل التحقق. تُمكّن هذه الطريقة من إرسال البيانات بنجاح حتى في ظل ظروف الشبكة الضعيفة، مما يقلل وقت الانتظار بشكل فعال، ويضمن سلاسة سير المعاملات، ويُحسّن تجربة المستخدم ورضاه بشكل ملحوظ. ^{[ 4 ]}

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

يتجنب بروتوكول إرسال البيانات مشكلة البيع الزائد الناتجة عن عدم تزامن البيانات، وذلك من خلال التحكم المتزامن في معلومات البيانات على خوادم متعددة. يستخدم نظام إدارة قواعد البيانات R* من IBM بروتوكول الالتزام المفترض للتعامل مع خدمات الحجز هذه بكفاءة، مما يضمن دقة وكفاءة حجز العملاء. ^{[ 2 ]}

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

Commit protocol, combined with the Consensus Mechanism in the blockchain, provides the necessary data security for decentralized applications such as cryptocurrency transactions and Smart Contracts.^[8] In addition, this combination ensures that the results of transaction execution in the blockchain network are consistent across all nodes, thus becoming an essential infrastructure for the digital economy.^[6] For example, the special commit protocol adopted by the Hyperledger Fabric platform directly emphyses the consensus mechanism into the transaction verification process to enhance the robustness against malicious nodes and network partitions.^[6]