How Shopify Mitigates Deadlocks in High Concurrency Environments

عشان نضمن الـ Data Integrity فالـ MySQL بيحتاج يعمل Lock على البيانات قبل ما يعمل Update على أي Record موجود ، لو فيه عمليات متعددة (Multiple Processes) بتحاول تعمل Update للبيانات في نفس الجدول في نفس الوقت، فممكن يحصل "deadlock"
How Shopify Mitigates Deadlocks in High Concurrency Environments
How Shopify Mitigates Deadlocks in High Concurrency Environments

في هذه الصفحة

المقدمة

عشان نضمن الـ Data Integrity فالـ MySQL بيحتاج يعمل Lock على البيانات قبل ما يعمل Update على أي Record موجود ، لو فيه عمليات متعددة (Multiple Processes) بتحاول تعمل Update للبيانات في نفس الجدول في نفس الوقت، فممكن يحصل "deadlock" حسب طريقة تخزين البيانات على الـ Disk وحسب إدارة MySQL ليها.

ده ممكن يحصل حتى لو العمليات المختلفة دي بتتعامل مع Records مختلفة. فتعالوا نشوف في المقال ده ازاي Shopify بتشرح مشكلة الـ "deadlocks" في MySQL أثناء عمليات الـ Updates للبيانات، ونشوف إزاي الـ "composite primary keys" ممكن يكون حل للمشكلة دي بشكل فعال.

Deadlock Problem

لما MySQL بيعمل Update/Insert اللي هي (up-sert) لمجموعة من الـ Records اللي فيها بيانات جديدة وموجودة، بيحاول يضيف كل الـ Records ويعملهم Insert. فبالنسبة للسجلات اللي موجودة بالفعل، لو حصل "collision" على الـ "unique constraint" ده بيبقى معناه إن التحديث مطلوب بدل الإضافة. وعشان MySQL يقدر انه يعمل Update للسجلات دي بأمان، بيحتاج يعمل "gap lock".

لما العملية دي بتتكرر بشكل متزامن عن طريق أكتر من Process بتحاول تعمل نفس الكلام، الكلام ده بيبقى عرضة لحدوث "deadlocks".

وده طبعًا بيحصل لأن الـ "gap lock" بيستهدف الـ Record اللي بيتحدث فعليًا والـ Record اللي قبله على طول في الـ Index ، فـ MySQL بيعمل كده عشان يقدر يحدث الـ Index كمان.

لو الـ pkid بطبيعته Sequential ، فده معناه إن البيانات هتتخزن بنفس ترتيب الـ Sequence ده. فلما يجي MySQL يحتاج يعمل "gap locks" عشان يدير العمليات المتعددة اللي بتحدث البيانات، ممكن وقتها يحصل تداخل في الـ "gap locks" اللي محتاجها العمليات المختلفة.

وعلى حسب عدد العمليات اللي شغالة في نفس الوقت وعدد الـ "unique constraint collisions" اللي بتحصل، ممكن ده طبعًا يؤدي لحدوث "deadlocks". وبناءً على تكرار الـ "deadlocks" دي، ممكن تأثر بشكل كبير على أداء التطبيق ككل.

والـ "deadlocks" ممكن تحصل حتى لو العمليات شغالة على دفعات مختلفة (Multiple Batches) من السجلات.


ETL Jobs on Transactions Table

الصورة دي بتوضح جدول اسمه transactions. الجدول ده بيتم تحديثه بشكل متزامن عن طريق عمليات ETL بتشتغل على كل account بشكل مستقل. ورغم إن كل عملية بتستهدف مجموعة مختلفة من الـ Records في الجدول transaction، إلا إن متطلبات الـ Locks بينهم ممكن تتداخل وتسبب "deadlocks".


تقدروا دلوقتي تشتركوا في النشرة الأسبوعية لاقرأ-تِك بشكل مجاني تمامًا عشان يجيلكوا كل جديد بشكل أسبوعي فيما يخص مواضيع متنوعة وبشروحات بسيطة وسهلة وبجودة عالية 🚀

النشرة هيكون ليها شكل جديد ومختلف عن شكلها القديم وهنحاول انها تكون مميزة ومختلفة وخليط بين المحتوى الأساسي اللي بينزل ومفاجآت تانية كتير 🎉

Eqraatech Newsletter | Eqraatech - اقرأ-تِك | Substack
محتوى تقني متميز في مختلف مجالات هندسة البرمجيات باللغة العربية عن طريق تبسيط المفاهيم البرمجية المعقدة بشكل سلس وباستخدام صور توضيحية مذهلة. Click to read Eqraatech Newsletter, a Substack publication with hundreds of subscribers.

بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀

آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة

مستنينكوا تنورونا , وده رابط القناة 👇

https://t.me/eqraatechcom


Mitigating Deadlocks Solution

هذا المقال مخصص للأعضاء المنتسبين لخطط الاشتراك المدفوعة فقط

اشترك الآن بنشرة اقرأ-تِك الأسبوعية

لا تدع أي شيء يفوتك. واحصل على أحدث المقالات المميزة مباشرة إلى بريدك الإلكتروني وبشكل مجاني!