حالات التعارض والأقفال وMVCC
كيفية تجنّب قواعد البيانات للتعارضات ومفاضلات الأقفال مقابل اللقطات
حالات التعارض والأقفال وMVCC درس مجاني في SQL Interview Prep على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في SQL Interview Prep، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة SQL Interview Prep 4 دروس في المجموع.
كيف تطبق قواعد البيانات العزل فعليًا
مستويات العزل هي الوعد، أما الأقفال وMVCC فهما الآليتان اللتان تحققانه. يسأل المحاورون عن هذه الآليات ليتأكدوا من فهمك لما يحدث خلف الكواليس عندما تتصادم المعاملات.
هناك استراتيجيتان عامتان:
- التشاؤمية (القفل): حظر الوصول المتعارض حتى تحرير القفل.
- التفاؤلية / MVCC: السماح للجميع بقراءة لقطة متسقة، واكتشاف التعارضات عند التثبيت.
يتناول هذا الدرس الأقفال، وحالات الجمود، وMVCC، إلى جانب المفاضلات بينها.
الأقفال المشتركة مقابل الأقفال الحصرية
يستخدم القفل التقليدي نمطين أساسيين:
- القفل المشترك (S) للقراءة. ويمكن لعدة معاملات امتلاك قفل مشترك على الصف نفسه في الوقت ذاته.
- القفل الحصري (X) للكتابة. ولا يمكن أن تمتلكه سوى معاملة واحدة، كما أنه يمنع جميع الأقفال الأخرى على ذلك الصف.
القاعدة هي: يتوافق S مع S، لكن X لا يتوافق مع أي شيء. ويجب على الكاتب الانتظار حتى ينتهي جميع القراء، كما يجب على القراء الانتظار حتى ينتهي الكاتب.
القفل الصريح باستخدام SELECT FOR UPDATE
يمكنك طلب قفل كتابة للصفوف التي تقرؤها فقط، لمنع الآخرين من تغييرها قبل أن تتصرف بناءً عليها. وهذه هي الطريقة القياسية لتجنب التحديثات المفقودة في دورة القراءة ثم التعديل ثم الكتابة.
يطبّق SELECT ... FOR UPDATE أقفالًا حصرية على الصفوف، وتظل الصفوف مقفلة حتى تنفذ COMMIT أو ROLLBACK.
BEGIN;
-- lock the row so no one else can modify it concurrently
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT; -- lock released hereما حالة الجمود؟
تحدث حالة الجمود عندما تمتلك معاملتان أو أكثر كل منهما قفلًا تحتاج إليه الأخرى، فتتكون حلقة لا يمكن لأي منها الخروج منها.
الحالة المعروفة هي: تقفل T1 الصف A ثم تريد الصف B، بينما تقفل T2 الصف B ثم تريد الصف A. وتنتظر كل منهما الأخرى إلى ما لا نهاية.
تكتشف قواعد البيانات ذلك باستخدام رسم بياني للانتظار. وعند اكتشاف حلقة، يختار المحرك معاملة ضحية ويلغيها، ثم يعيد خطأ حالة جمود كي تتمكن المعاملات الأخرى من المتابعة.
مخطط زمني لحالة الجمود
راقب تقاطع ترتيب الأقفال. تقفل T1 الصف 1 ثم تطلب الصف 2، بينما تقفل T2 الصف 2 ثم تطلب الصف 1. ولا تحرر أي منهما قفلها، لذلك يلغي المحرك إحدى المعاملتين.
ترى المعاملة الملغاة خطأً مثل deadlock detected ويجب عليها إعادة المحاولة. أما المعاملة الناجية فتثبت بشكل طبيعي.
-- T1 | -- T2
BEGIN; | BEGIN;
UPDATE accounts SET balance=balance-10 | UPDATE accounts SET balance=balance-10
WHERE id=1; -- locks row 1 | WHERE id=2; -- locks row 2
UPDATE accounts SET balance=balance+10 | UPDATE accounts SET balance=balance+10
WHERE id=2; -- waits for T2 | WHERE id=1; -- waits for T1 -> CYCLE
-- one transaction is chosen as victim and rolled backمنع حالات الجمود
لا يمكنك التخلص من حالات الجمود تمامًا، لكن يمكنك جعلها نادرة. وتشمل الإجابات القياسية في المقابلات:
- ترتيب ثابت للأقفال: احصل دائمًا على أقفال الصفوف بالترتيب نفسه (مثلًا حسب المعرّف تصاعديًا). فهذا يكسر الحلقة.
- إبقاء المعاملات قصيرة: احتفظ بالأقفال لأقصر وقت ممكن.
- خفض مستوى العزل عند أمان ذلك: أقفال أقل وتعارضات أقل.
- إضافة منطق لإعادة المحاولة: ينبغي أن تعيد المعاملات الضحية لحالة الجمود المحاولة تلقائيًا.
يُعد الترتيب الثابت للأقفال الحل الأكثر فاعلية، وهو أول ما يريد المحاورون سماعه.
دقة الأقفال
يمكن تطبيق الأقفال على نطاقات مختلفة، في مفاضلة بين التزامن والتكلفة التشغيلية:
- تتيح أقفال مستوى الصف تزامنًا عاليًا، لكنها تتطلب تكلفة أكبر لإدارتها.
- تكون أقفال الصفحة أو الجدول أقل تكلفة في التتبع، لكنها تحظر عددًا أكبر من المعاملات.
تصعّد بعض المحركات الأقفال من مستوى الصف إلى مستوى الجدول عندما تلمس المعاملة عددًا كبيرًا جدًا من الصفوف (تصعيد الأقفال). ويساعدك فهم ذلك على تفسير سبب تسبب عملية UPDATE جماعية كبيرة في حظر الجميع فجأة.
MVCC: نهج اللقطات
إن MVCC (التحكم بالتزامن متعدد الإصدارات) هو الأسلوب الذي تستخدمه Postgres وOracle وInnoDB لتجنب معظم أقفال القراءة. فبدلًا من القفل، تحتفظ قاعدة البيانات بإصدارات متعددة من كل صف.
الفائدة الأساسية، وهي عبارة محببة في المقابلات: القراء لا يمنعون الكُتّاب، والكُتّاب لا يمنعون القراء.
ترى كل معاملة لقطة متسقة تعكس حالة البيانات في نقطة زمنية معينة، بينما تنشئ عمليات الكتابة إصدارات جديدة من الصفوف بدلًا من الكتابة فوقها في مكانها.
كيف يعمل MVCC من الداخل
عند تحديث صف، يكتب MVCC إصدارًا جديدًا ويحتفظ بالإصدار القديم. ويحمل كل إصدار بيانات وصفية لمعرّف المعاملة (في Postgres، xmin وxmax) تحدد وقت ظهوره ووقت استبداله.
تحدد لقطة المعاملة الإصدار الذي تراه. وتصبح الإصدارات القديمة التي لم تعد أي معاملة قادرة على رؤيتها صفوفًا ميتة، ويُتخلص منها لاحقًا عبر عملية تنظيف. وفي Postgres، تُنفذ هذه العملية بواسطة VACUUM؛ ويؤدي عدم تشغيلها إلى تضخم الجدول، وهو سؤال متابعة شائع.
المفاضلة بين القفل وMVCC
لخّص المقارنة بوضوح:
- القفل الخالص: صحة بسيطة، لكن القراء والكتّاب يحظر كل منهم الآخر، مما يضر بالتزامن.
- MVCC: تزامن ممتاز للقراءة من دون أقفال قراءة، لكنه يدفع ثمن ذلك بتخزين الإصدارات وتنظيفها (VACUUM والتضخم)، ولا يزال يحتاج إلى أقفال لحل تعارضات الكتابة مع الكتابة.
حتى محركات MVCC تستخدم الأقفال عند الكتابة: يجب ترتيب معاملتين تحدّثان الصف نفسه. ويزيل MVCC التنافس بين القارئ والكاتب، لا التنافس بين كاتبين.
القفل التفاؤلي وأعمدة الإصدارات
إلى جانب MVCC على مستوى المحرك، تضيف التطبيقات غالبًا القفل التفاؤلي لعمليات القراءة ثم التعديل ثم الكتابة التي تمتد خلال جلسات مستخدم طويلة. إذ تضيف عمود version، وتقرأه، ثم تشترط عند التحديث أن يطابق الإصدار الحالي، مع زيادته.
إذا حدّثت معاملة أخرى الصف أولًا، فلن يتطابق الإصداران، ولن يتأثر أي صف، ويدرك برنامجك أنه يجب إعادة التحميل وإعادة المحاولة. ولا تُحتجز أي أقفال أثناء تفكير المستخدم، لذلك يظل التزامن مرتفعًا. ويحب المحاورون هذا الأسلوب عند طرح سؤال «كيف تتعامل مع تعديل مستخدمين للسجل نفسه؟».
-- read: SELECT id, data, version FROM items WHERE id = 1; -- version = 7
UPDATE items
SET data = 'new value', version = version + 1
WHERE id = 1 AND version = 7;
-- if rows affected = 0, someone else changed it: reload and retryتحقق سريع
اختبر العبارة الأساسية عن MVCC.
مراجعة: الأقفال وحالات الجمود وMVCC
يمكنك الآن شرح الآليات الكامنة وراء العزل:
- الأقفال المشتركة والحصرية تنسق الوصول؛ ويطبّق
SELECT FOR UPDATEأقفال كتابة صريحة. - حالات الجمود هي حلقات من الأقفال؛ يلغي المحرك معاملة ضحية، ويمنع الترتيب الثابت للأقفال معظم هذه الحالات.
- MVCC يحتفظ بإصدارات الصفوف كي لا يحظر القراء والكتّاب بعضهم بعضًا، مقابل تكلفة التنظيف (VACUUM والتضخم).
اربط هذه الآليات بمستويات العزل وحالات الشذوذ من الدروس السابقة، وستتمكن من تغطية موضوع التزامن كاملًا في مقابلات العمل، من البداية إلى النهاية.
الأسئلة الشائعة
هل درس «حالات التعارض والأقفال وMVCC» مجاني؟
نعم — نص درس «حالات التعارض والأقفال وMVCC» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة SQL Interview Prep، انتقل إلى CoddyKit PRO. تتضمن دورة SQL Interview Prep 4 دروس في المجموع.
ماذا ستتعلم في «حالات التعارض والأقفال وMVCC»؟
كيفية تجنّب قواعد البيانات للتعارضات ومفاضلات الأقفال مقابل اللقطات تتمرن على SQL Interview Prep مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ SQL Interview Prep؟
لا تُشترط خبرة سابقة. SQL Interview Prep على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.
كم من الوقت يستغرق درس «حالات التعارض والأقفال وMVCC»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس SQL Interview Prep هذا؟
نعم. كل درس في SQL Interview Prep يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- شرح خصائص ACID
- مستويات العزل الأربعة
- القراءات المتسخة وغير القابلة للتكرار والوهمية
- حالات التعارض والأقفال وMVCC