نسخ حديث بروس مومجيان لعام 2020 بعنوان "فتح مدير قفل Postgres".
(ملاحظة: يمكنك الحصول على جميع استعلامات SQL من الشرائح الموجودة على هذا الرابط: )
مرحبًا! إنه لأمر رائع أن أكون هنا في روسيا مرة أخرى. أنا آسف لأنني لم أتمكن من الحضور العام الماضي ، لكن إيفان ولدي هذا العام خطط كبيرة. أتمنى أن أكون هنا في كثير من الأحيان. أحب القدوم إلى روسيا. سوف أزور تيومين ، تفير. أنا سعيد جدًا لأنني سأتمكن من زيارة هذه المدن.
اسمي بروس مومجيان. أعمل في EnterpriseDB وأعمل مع Postgres منذ أكثر من 23 عامًا. أعيش في فيلادلفيا بالولايات المتحدة الأمريكية. أسافر حوالي 90 يومًا في السنة. وأنا أحضر حوالي 40 مؤتمرًا. لي الذي يحتوي على الشرائح التي سأعرضها لك الآن. لذلك ، بعد المؤتمر يمكنك تنزيلها من موقعي الشخصي. يحتوي أيضًا على حوالي 30 عرضًا تقديميًا. وهناك أيضًا مقاطع فيديو وعدد كبير من إدخالات المدونة ، أكثر من 500. هذا مصدر إعلامي إلى حد ما. وإذا كنت مهتمًا بهذه المادة ، فأنا أدعوك لاستخدامها.
اعتدت أن أكون مدرسًا وأستاذًا قبل أن أبدأ العمل مع Postgres. وأنا سعيد جدًا لأنني أستطيع الآن أن أخبرك بما سأخبرك به. هذا واحد من أكثر عروضي إثارة للاهتمام. ويحتوي هذا العرض التقديمي على 110 شريحة. سنبدأ الحديث بأشياء بسيطة ، وبحلول نهاية التقرير سيصبح الأمر أكثر تعقيدًا ، وسيصبح معقدًا للغاية.
هذه محادثة غير سارة إلى حد ما. الحظر ليس الموضوع الأكثر شيوعًا. نريده أن يختفي في مكان ما. إنه مثل الذهاب إلى طبيب الأسنان.
- يمثل القفل مشكلة لكثير من الأشخاص الذين يعملون في قواعد البيانات ولديهم عمليات متعددة تعمل في نفس الوقت. إنهم بحاجة إلى الحجب. أي ، سأعطيك اليوم المعرفة الأساسية بالحظر.
- معرّفات المعاملات. هذا جزء ممل من العرض التقديمي ، لكن يجب فهمه.
- بعد ذلك ، سنتحدث عن أنواع الحجب. إنه جزء ميكانيكي تمامًا.
- وبعد ذلك سنقدم بعض الأمثلة على الحجب. وسيكون من الصعب فهمه.
دعنا نتحدث عن الحجب.
مصطلحاتنا معقدة للغاية. كم منكم يعرف من أين يأتي هذا المقطع؟ شخصان. إنها من لعبة تسمى Colossal Cave Adventure. لقد كانت لعبة كمبيوتر نصية في الثمانينيات ، على ما أعتقد. هناك كان لا بد من الذهاب إلى الكهف ، إلى المتاهة وتغير النص ، لكن المحتوى كان متماثلًا تقريبًا في كل مرة. هكذا أتذكر هذه اللعبة.
وهنا نرى اسم الأقفال التي أتت إلينا من Oracle. نحن نستخدمهم.
هنا نرى المصطلحات التي تحيرني. على سبيل المثال ، SHARE UPDATE ECXLUSIVE. التالي SHARE RAW ECXLUSIVE. بصراحة هذه الأسماء ليست واضحة جدا. سنحاول النظر فيها بمزيد من التفصيل. يحتوي بعضها على كلمة "مشاركة" ، والتي تعني الفصل. يحتوي بعضها على كلمة "حصري" - حصري. بعضها يحتوي على هاتين الكلمتين. أود أن أبدأ بكيفية عمل هذه الأقفال.
وكلمة "الوصول" مهمة جدًا أيضًا. وكلمات "صف" - سطر. أي ، توزيع الوصول ، توزيع الصفوف.
هناك مشكلة أخرى يجب فهمها في Postgres ، والتي للأسف لن أتمكن من تغطيتها في حديثي ، وهي MVCC. لدي عرض تقديمي منفصل حول هذا الموضوع على موقع الويب الخاص بي. وإذا كنت تعتقد أن هذا العرض التقديمي صعب ، فمن المحتمل أن يكون MVCC هو الأصعب بالنسبة لي. وإذا كنت مهتمًا ، فيمكنك رؤيتها على الموقع. يمكنك مشاهدة الفيديو.
شيء آخر نحتاج إلى فهمه هو معرفات المعاملات. لا يمكن أن تعمل العديد من المعاملات بدون معرفات فريدة. وهنا لدينا شرح لماهية الصفقة. يحتوي Postgres على نظامين لترقيم المعاملات. أعلم أنه ليس حلاً جميلًا جدًا.
ضع في اعتبارك أيضًا أن الشرائح ستكون صعبة جدًا في القراءة ، لذا فإن ما تم تمييزه باللون الأحمر هو ما تحتاج إلى الانتباه إليه.
نحن ننظر. رقم المعاملة مظلل باللون الأحمر. تظهر هنا وظيفة SELECT pg_back. تقوم بإرجاع معاملتي ومعرف تلك المعاملة.
شيء آخر ، إذا كنت تحب هذا العرض التقديمي وترغب في تشغيله في قاعدة البيانات الخاصة بك ، فيمكنك اتباع هذا الرابط المميز باللون الوردي وتنزيل SQL لهذا العرض التقديمي. ويمكنك فقط تشغيله في PSQL الخاص بك وسيكون العرض التقديمي بأكمله على شاشتك في أي وقت من الأوقات. لن تحتوي على أزهار ، لكن على الأقل يمكننا رؤيتها.
في هذه الحالة ، نرى معرّف المعاملة. هذا هو الرقم الذي خصصناه لها. وهناك نوع آخر من معرف المعاملة في Postgres يسمى معرف المعاملة الظاهري
ويجب أن نفهم هذا. هذا مهم جدًا ، وإلا فلن نتمكن من فهم الإغلاق في Postgres.
معرف المعاملة الظاهري هو معرف المعاملة الذي لا يحتوي على قيم ثابتة. على سبيل المثال ، إذا قمت بتشغيل أمر SELECT ، فأنا على الأرجح لن أغير قاعدة البيانات ، ولن أقفل أي شيء. لذلك عندما نقوم بتشغيل SELECT بسيط ، فإننا لا نعطي هذه المعاملة معرفًا دائمًا. نعطيها فقط هوية افتراضية هناك.
وهذا يحسن أداء Postgres ، ويحسن القدرة على التنظيف ، وبالتالي فإن معرف المعاملة الافتراضي يتكون من رقمين. الرقم الأول قبل الشرطة المائلة هو معرف الواجهة الخلفية. وعلى اليمين نرى مجرد عداد.
لذلك ، إذا قمت بتشغيل طلب ، فإنه يقول أن معرف الواجهة الخلفية هو 2.
وإذا قمت بتشغيل سلسلة من هذه المعاملات ، فسنرى أن العداد يتزايد في كل مرة أقوم فيها بتشغيل الاستعلام. على سبيل المثال ، عندما أقوم بتشغيل الاستعلام 2/10 ، 2/11 ، 2/12 ، إلخ.
ضع في اعتبارك أن هناك عمودين هنا. على اليسار ، نرى معرّف المعاملة الافتراضي - 2/12. وعلى اليمين لدينا معرف معاملة دائم. وهذا الحقل فارغ. وهذه المعاملة لا تعدل قاعدة البيانات. لذلك ، لا أقوم بتعيين معرّف معاملة دائم لها.
بمجرد تشغيل أمر التحليل ((ANALYZE)) ، يمنحني الاستعلام نفسه معرّف معاملة دائم. انظر كيف تغيرنا. في السابق ، لم يكن لدي هذا المعرف ، والآن لدي.
إذن هذا طلب آخر ، معاملة أخرى. رقم المعاملة الافتراضي هو 2/13. وإذا طلبت معرف معاملة دائم ، فعند تشغيل الطلب ، سأحصل عليه.
إذن ، مرة أخرى. لدينا معرف معاملة افتراضي ومعرف معاملة دائم. فقط خذ هذه النقطة لفهم سلوك Postgres.
ننتقل إلى القسم الثالث. هنا سنتعرف على أنواع الأقفال المختلفة في Postgres. إنه ليس ممتعًا جدًا. سيكون القسم الأخير أكثر إثارة للاهتمام. لكن علينا أن نفكر في الأشياء الأساسية ، وإلا فإننا لن نفهم ما سيحدث بعد ذلك.
سنتناول هذا القسم ، وسننظر في كل نوع من أنواع الحجب. وسأعرض لك أمثلة حول كيفية تثبيتها ، وكيفية عملها ، وأظهر لك بعض الاستعلامات التي يمكنك استخدامها لمعرفة كيفية عمل الحظر في Postgres.
لإنشاء استعلام ومعرفة ما يحدث في Postgres ، نحتاج إلى إصدار الاستعلام إلى عرض النظام. في هذه الحالة ، يتم تمييز pg_lock باللون الأحمر. pg_lock هو جدول نظام يخبرنا عن الأقفال المستخدمة حاليًا في Postgres.
ومع ذلك ، من الصعب جدًا بالنسبة لي أن أعرض عليك pg_lock بمفردها ، لأنها معقدة للغاية. لذلك قمت بإنشاء عرض يُظهر pg_locks. كما أنه يؤدي بعض الأعمال التي تتيح لي أن أفهم بشكل أفضل. أي أنه يستثني أقفالي وجلستي الخاصة وما إلى ذلك. إنه مجرد معيار SQL ويسمح لك بإظهار ما يحدث بشكل أفضل.
هناك مشكلة أخرى وهي أن هذا العرض واسع جدًا ، لذا يجب أن أقوم بإنشاء عرض آخر - lockview2.
ويظهر لي المزيد من الأعمدة من الجدول. وآخر يظهر لي باقي الأعمدة. هذا معقد للغاية ، لذا حاولت تقديمه ببساطة قدر الإمكان.
لذلك ، قمنا بإنشاء جدول يسمى Lockdemo. وقمنا بإنشاء سطر واحد هناك. هذا هو جدول عينة لدينا. وسننشئ أقسامًا فقط لنعرض لك أمثلة على الحظر.
إذن ، صف واحد ، عمود واحد. النوع الأول من القفل يسمى ACCESS SHARE. هذا هو الحظر الأقل تقييدًا. هذا يعني أنه لا يتعارض عمليًا مع الأقفال الأخرى.
وإذا أردنا تعريف القفل بشكل صريح ، فإننا نقوم بتشغيل الأمر "lock table". وسيتم حظره بشكل صريح ، أي في وضع ACCESS SHARE ، نقوم بتشغيل جدول القفل. وإذا بدأت PSQL في الخلفية ، سأبدأ الجلسة الثانية من جلستي الأولى بهذه الطريقة. أي ماذا سأفعل هنا؟ أذهب إلى جلسة أخرى وأقول لها "أرني عرض القفل لهذا الطلب". وهنا لدي AccessShareLock على هذه الطاولة. هذا فقط ما طلبته. ويقول إنه تم تخصيص القفل. بسيط جدا.
علاوة على ذلك ، إذا نظرنا إلى العمود الثاني ، فلا يوجد شيء هناك. هم فارغون.
وإذا قمت بتشغيل الأمر "SELECT" ، فهذه هي الطريقة الضمنية (الصريحة) لطلب AccessShareLock. لذلك قمت بتحرير الجدول الخاص بي وتشغيل استعلام وسيقوم الاستعلام بإرجاع صفوف متعددة. وفي أحد السطور نرى AccessShareLock. لذا يستدعي SELECT AccessShareLock على الطاولة. ولا يتعارض مع أي شيء تقريبًا ، لأنه قفل منخفض المستوى.
ماذا لو قمت بتشغيل SELECT ولدي ثلاثة جداول مختلفة؟ في السابق كنت أدير جدولًا واحدًا فقط ، أما الآن فأنا أقوم بتشغيل ثلاثة: pg_class و pg_namespace و pg_attribute.
والآن عندما ألقي نظرة على الاستعلام أرى 9 AccessShareLocks في XNUMX جداول. لماذا؟ تم تمييز ثلاثة جداول باللون الأزرق: pg_attribute ، و pg_class ، و pg_namespace. ولكن يمكنك أيضًا رؤية أن جميع الفهارس التي تم تحديدها من خلال هذه الجداول لها أيضًا AccessShareLock.
وهذا حظر لا يتعارض عمليًا مع الآخرين. وكل ما يفعله هو منعنا من إسقاط الطاولة أثناء اختيارنا لها. يبدو الأمر معقولا. أي ، إذا حددنا جدولاً ، فإنه يختفي في تلك اللحظة ، وبالتالي فهذا خطأ AccessShare هو قفل ذو مستوى منخفض يخبرنا "لا تحذف هذا الجدول أثناء عملي". هذا كل ما تفعله في الأساس.
مشاركة الصف - يختلف هذا القفل قليلاً.
لنأخذ مثالا. حدد طريقة مشاركة الصف لقفل كل صف على حدة. بهذه الطريقة لا يمكن لأي شخص حذفها أو تغييرها أثناء مشاهدتها.
إذن ، ماذا يفعل SHARE LOCK؟ نرى أن معرف المعاملة هو 681 لـ SELECT. وهذا مثير للاهتمام. ماذا حدث هنا؟ لأول مرة نرى الرقم في حقل "القفل". نأخذ معرّف المعاملة ، ويقول إنه يحظرها في الوضع الحصري. كل ما يفعله هو أن لدي صفًا مغلقًا تقنيًا في مكان ما على الطاولة. لكنه لا يقول أين بالضبط. سننظر في هذا بمزيد من التفصيل لاحقًا.
هنا نقول أن القفل مستخدم من قبلنا.
لذلك ، يقول القفل الحصري صراحة (صراحة) أنه حصري. وأيضًا إذا حذفت صفًا في هذا الجدول ، فهذا ما يحدث ، كما ترى.
SHARE EXCLUSIVE هو قفل أطول.
هذا هو (ANALYZE) أمر المحلل الذي سيتم استخدامه.
SHARE LOCK - يمكنك قفل وضع المشاركة بشكل صريح.
يمكنك أيضًا إنشاء فهرس فريد. وهناك يمكنك رؤية SHARE LOCK ، وهو جزء منها. ويقفل الطاولة ويضع قفل SHARE LOCK عليها.
تعني ميزة SHARE LOCK الافتراضية في الجدول أنه يمكن للآخرين قراءة الجدول ، ولكن لا يمكن لأحد تعديله. وهذا بالضبط ما يحدث عند إنشاء فهرس فريد.
إذا قمت بإنشاء فهرس فريد بشكل متزامن ، فسيكون لدي نوع مختلف من القفل ، لأن ، تذكر ، استخدام الفهارس المتزامنة يقلل من متطلبات القفل. وإذا استخدمت قفلًا عاديًا ، فهرسًا عاديًا ، فأنا بذلك أمنع الكتابة في فهرس الجدول أثناء إنشائه. إذا كنت أستخدم فهرسًا بشكل متزامن ، فأنا بحاجة إلى استخدام نوع مختلف من القفل.
SHARE ROW حصري - مرة أخرى ، يمكن تعيينه بشكل صريح (صريح).
أو يمكننا إنشاء قاعدة ، أي نأخذ بعض الحالات المحددة التي سيتم استخدامها فيها.
يعني القفل الحصري أنه لا يمكن لأي شخص آخر تغيير الجدول.
هنا نرى أنواع مختلفة من الأقفال.
ACCESS EXCLUSIVE ، على سبيل المثال ، هو أمر قفل. على سبيل المثال ، إذا قمت بذلك CLUSTER table، فسيعني ذلك أنه لن يتمكن أحد من الكتابة هناك. وهو لا يقفل الجدول نفسه فحسب ، بل يقفل الفهارس أيضًا.
هذه هي الصفحة الثانية من قفل ACCESS EXCLUSIVE حيث نرى على وجه التحديد ما يتم قفله في الجدول. يقوم بإغلاق صفوف الجدول الفردية ، وهو أمر مثير للاهتمام بدرجة كافية.
هذه هي كل المعلومات الأساسية التي أردت أن أقدمها. تحدثنا عن الأقفال ، ومعرفات المعاملات ، وتحدثنا عن معرفات المعاملات الافتراضية ، ومعرفات المعاملات الدائمة.
والآن سنتناول أمثلة الحظر. هذا هو الجزء الأكثر إثارة للاهتمام. سنرى حالات مثيرة جدا للاهتمام. وهدفي في هذا العرض هو أن أعطيك فكرة أفضل عما تفعله Postgres بالفعل عندما تحاول منع الأشياء. يبدو لي أنه جيد جدًا في منع الأجزاء الفردية.
لنلقِ نظرة على بعض الأمثلة المحددة.
سنبدأ بالجداول وصف واحد لكل جدول. عندما أقوم بإدخال شيء ما ، أحصل على ExclusiveLock ومعرف المعاملة و ExclusiveLock على الطاولة.
ماذا يحدث إذا أدخلت صفين آخرين؟ والآن يتكون جدولنا من ثلاثة صفوف. وأدرجت صفًا واحدًا وحصلت على هذا كناتج. وإذا أدخلت صفين آخرين ، فما الغريب هنا؟ هناك شذوذ هنا لأنني أضفت ثلاثة صفوف إلى هذا الجدول ، لكن لا يزال لدي صفان في جدول القفل. وهذا ، في الواقع ، هو السلوك الأساسي لبوستجرس.
يعتقد الكثير من الناس أنه إذا قمت بقفل 100 صف في قاعدة البيانات ، فستحتاج إلى إنشاء 100 إدخال قفل. إذا حظرت 1 صف دفعة واحدة ، فسأحتاج إلى 000 طلب من هذا القبيل. وإذا كنت بحاجة إلى مليون أو مليار لأحجبه. لكن إذا فعلنا ذلك ، فلن يعمل بشكل جيد. إذا كنت قد استخدمت نظامًا يقوم بإنشاء إدخالات حظر لكل صف على حدة ، فيمكنك أن ترى أن هذا الأمر معقد. لأنك تحتاج إلى تحديد جدول القفل على الفور ، والذي يمكن أن يتجاوز ، لكن Postgres لا يفعل ذلك.
ومن المهم جدًا في هذه الشريحة أنه يوضح بوضوح أن هناك نظامًا آخر يعمل داخل MVCC يمنع الخطوط الفردية. لذلك عندما تغلق مليارات الصفوف ، لا تنشئ Postgres مليار تعليمات قفل منفصلة. وهذا جيد جدًا للأداء.
ماذا عن التحديث؟ أقوم بتحديث السلسلة الآن ويمكنك أن ترى أنها قامت بعمليتين مختلفتين في وقت واحد. لقد أغلق الجدول في نفس الوقت ، لكنه أغلق أيضًا الفهرس. وقد احتاج إلى قفل الفهرس لأن هناك قيودًا فريدة على ذلك الجدول. ونريد التأكد من عدم تغيير أي شخص ، لذلك نقوم بحظره.
ماذا يحدث إذا أردت تحديث صفين؟ ونرى أنه يتصرف بنفس الطريقة. نقوم بعمل ضعف عدد التحديثات ، ولكن بالضبط نفس عدد خطوط الحظر.
إذا كنت تتساءل عن كيفية قيام Postgres بهذا ، فيجب أن تستمع إلى محادثاتي على MVCC لمعرفة كيف تقوم Postgres بتمييز هذه السطور داخليًا بأنها تتغير. ولدى Postgres طريقة للقيام بذلك ، لكنها لا تفعل ذلك على مستوى قفل الطاولة ، بل تقوم بذلك على مستوى أقل وأكثر كفاءة.
ماذا لو أردت حذف شيء ما؟ إذا قمت بحذف ، على سبيل المثال ، صف واحد وما زلت أمتلك مدخلين في القفل ، وحتى إذا كنت أرغب في حذفهم جميعًا ، فلا يزالون هناك.
وعلى سبيل المثال ، أريد إدخال 1 سطر ، ثم إما حذف أو إضافة 000 سطر ، ثم الأسطر الفردية التي أقوم بإضافتها أو تغييرها ، لم يتم تسجيلها هنا. وهي مكتوبة في مستوى أدنى داخل الصف نفسه. وأثناء حديث MVCC ، تحدثت عنه بالتفصيل. ولكن من المهم جدًا عند تحليل الأقفال أن تتأكد من أن لديك قفلًا على مستوى الجدول وأنك لا تستطيع رؤية كيفية كتابة الصفوف الفردية هنا.
ماذا عن الحجب الصريح؟
إذا قمت بالنقر فوق "تحديث" ، فسيكون لدي صفان مقفولان. وإذا قمت بتحديدها جميعًا وانقر فوق "تحديث في كل مكان" ، فلا يزال لدي سجلي قفل.
لا نقوم بإنشاء إدخالات منفصلة لكل صف على حدة. نظرًا لانخفاض الأداء بعد ذلك ، فقد يكون هناك الكثير منه. وقد نجد أنفسنا في موقف غير سار.
ونفس الشيء ، إذا قمنا بالمشاركة ، فيمكننا فعل كل شيء 30 مرة.
نستعيد طاولتنا ، ونحذف كل شيء ، ثم نضيف صفًا واحدًا مرة أخرى.
هناك نوع آخر من السلوك الذي تراه في Postgres والذي يكون معروفًا جيدًا والسلوك المرغوب فيه ، وهو أنه يمكنك إجراء تحديث أو تحديد. ويمكنك القيام بذلك في نفس الوقت. وحدد لا يمنع التحديث ونفس الشيء في الاتجاه المعاكس. نقول للقارئ ألا يمنع الكاتب ، والكاتب لم يمنع القارئ.
سأريكم مثالا على ذلك. سأقوم بالاختيار الآن. ثم سنفعل INSERT. وبعد ذلك يمكنك أن ترى - 694. يمكنك أن ترى معرّف المعاملة التي أدخلت هذا الإدخال. وهذه هي الطريقة التي يعمل بها.
وإذا نظرت الآن إلى هويتي الخلفية ، فقد أصبحت - 695.
ويمكنني أن أرى أن 695 يظهر في طاولتي.
وإذا قمت بالتحديث هنا بهذا الشكل ، فسأحصل على حالة مختلفة. في هذه الحالة ، يعد 695 قفلًا حصريًا ، والتحديث له نفس السلوك ، ولكن لا يوجد تعارض بينهما ، وهو أمر غير معتاد تمامًا.
ويمكنك ملاحظة أنه في الجزء العلوي يوجد ShareLock وفي الجزء السفلي يوجد ExclusiveLock. ونجحت كلتا العمليتين.
وتحتاج إلى الاستماع إلى حديثي في MVCC لفهم كيفية حدوث ذلك. لكن هذا توضيح لحقيقة أنه يمكنك القيام بذلك في نفس الوقت ، أي قم بالاختيار والتحديث في نفس الوقت.
دعنا نعيد الضبط ونقوم بعملية واحدة مرة أخرى.
إذا حاولت تشغيل تحديثين في نفس الوقت على نفس الصف ، فسيتم حظره. وتذكر ، قلت إن القارئ لا يمنع الكاتب ، بل كاتب القارئ ، لكن كاتب واحد يحجب كاتبًا آخر. وهذا يعني أنه لا يمكن أن يقوم شخصان بتحديث نفس الصف في نفس الوقت. عليك الانتظار حتى ينتهي أحدهم.
ولتوضيح ذلك ، سألقي نظرة على طاولة Lockdemo. وسننظر في صف واحد. للمعاملة 698.
لقد قمنا بترقيته إلى 2. 699 هو التحديث الأول. وكانت ناجحة أو أنها في صفقة معلقة تنتظر منا إلزامها أو إلغائها.
لكن انظر إلى شيء آخر - 2/51 هي معاملتنا الأولى ، جلستنا الأولى. 3/112 هو الطلب الثاني الذي جاء من الأعلى وغيّر هذه القيمة إلى 3. وإذا لاحظت ، فإن الطلب الأعلى قد أغلق نفسه ، وهو 699. لكن 3/112 لم يمنحك قفلًا. يشير عمود Lock_mode إلى أنه ينتظر. إنه يتوقع 699. وإذا نظرت إلى مكان 699 ، فهو أعلى. وماذا فعلت الجلسة الأولى؟ لقد أنشأت قفلًا حصريًا على معرف المعاملة الخاص بها. هذه هي الطريقة التي يقوم بها Postgres. يمنع معرف المعاملة الخاص به. وإذا كنت تريد الانتظار حتى يقوم شخص ما بالالتزام أو الإلغاء ، فعليك الانتظار ريثما تكون هناك معاملة معلقة. وهكذا يمكننا أن نرى خطًا غريبًا.
لننظر مرة أخرى. على اليسار نرى معرف المعالجة الخاص بنا. في العمود الثاني نرى معرف المعاملة الافتراضي الخاص بنا ، وفي العمود الثالث نرى lock_type. ماذا يعني هذا؟ في الواقع ، تقول إنها تمنع معرف المعاملة. لكن لاحظ أنه في جميع الصفوف في الأسفل توجد علاقة مكتوبة. وبالتالي لديك نوعان من الأقفال على الطاولة. هناك قفل علاقة. وأيضًا هناك قفل للمعاملة حيث نقوم بإغلاقه بمفردنا ، وهذا بالضبط ما يحدث في الصف الأول أو في الجزء السفلي حيث نتوقع أن ينتهي 699 من العملية.
أرى ما يحدث هنا. وهنا شيئان يحدثان في نفس الوقت. أنت تنظر إلى قفل معرّف المعاملة في الصف الأول ، والذي يقفل نفسه. وهي تحجب نفسها لتجعل الناس ينتظرون.
إذا نظرت إلى السطر السادس ، فهو نفس الإدخال مثل الأول. وهكذا تم حظر المعاملة 6. 699 هو أيضًا قفل ذاتي. ثم في الصف السفلي سترى أننا ننتظر 700 لإتمام عملها.
وفي lock_type ، tuple ترى الأرقام.
يمكنك أن ترى أنه 0/10. وهذا هو رقم الصفحة ، وأيضًا إزاحة هذا الصف المحدد.
وسترى ما سيصبح 0/11 عندما نقوم بالتحديث.
لكن في الواقع ، إنها 0/10 ، لأن هناك توقعًا لهذه العملية. لدينا الفرصة لنرى أن هذا هو الصف الذي أنتظر تأكيده.
بمجرد تأكيدنا عليه والضغط على الالتزام ، وعندما ينتهي التحديث ، هذا ما نحصل عليه مرة أخرى. الصفقة 700 هي القفل الوحيد ، فهي لا تنتظر أي شخص آخر ، لأنها ارتكبت. إنه ينتظر فقط حتى تكتمل المعاملة. بمجرد انتهاء 699 ، لا ننتظر أي شيء آخر. والآن تقول المعاملة 700 أن كل شيء على ما يرام ، وأنه يحتوي على جميع الأقفال التي يحتاجها في جميع الجداول المسموح بها.
ولزيادة تعقيد الأمر برمته ، فإننا نخلق وجهة نظر أخرى ، والتي ستزودنا هذه المرة بتسلسل هرمي. لا أتوقع منك فهم هذا الطلب. لكنه سيعطينا رؤية أوضح لما يحدث.
هذا عرض تكراري يحتوي أيضًا على قسم آخر. ثم يعيد كل شيء معًا مرة أخرى. دعونا نستخدم هذا.
ماذا لو أجرينا ثلاثة تحديثات متزامنة وقلنا أن الصف الآن ثلاثة. وسنغير 3 إلى 4.
وهنا نرى 4. ومعرف المعاملة 702.
وبعد ذلك سأبادل 4 مقابل 5. و 5 مقابل 6 ، و 6 مقابل 7. وأنا أصطف عددًا من الأشخاص لانتظار اكتمال هذه المعاملة الواحدة.
وكل شيء يصبح واضحا. ما هو الصف الأول؟ هذا هو 702. هذا هو معرف المعاملة الذي حدد هذه القيمة في الأصل. ماذا لدي في العمود الممنوح؟ لدي علامات f. هذه هي تحديثاتي التي لا يمكن الموافقة عليها (5 ، 6 ، 7) لأننا ننتظر انتهاء صلاحية معرف المعاملة 702. هناك لدينا قفل معرف المعاملة. واتضح معرف 5 أقفال المعاملات.
وإذا نظرتم إلى 704 ، في 705 ، فلا شيء مكتوب هناك حتى الآن ، لأنهم لا يعرفون ما الذي يجري بعد. يكتبون فقط أنه ليس لديهم فكرة عما يحدث. وسوف يذهبون للنوم فقط لأنهم ينتظرون انتهاء شخص ما وسوف يتم إيقاظهم عندما يمكنهم تغيير الصفوف.
هذا ما يبدو عليه. من الواضح أنهم جميعًا ينتظرون الصف الثاني عشر.
هذا ما رأيناه هنا. هنا 0/12.
لذلك ، بمجرد الموافقة على المعاملة الأولى ، يمكنك معرفة كيفية عمل التسلسل الهرمي هنا. والآن كل شيء واضح. كلهم يصبحون نظيفين. وهم في الواقع ما زالوا ينتظرون.
إليكم ما يحدث. 702 ملتزم. والآن يحصل 703 على قفل الصف هذا ، ثم يبدأ 704 في انتظار 703 للالتزام. و 705 ينتظر هذا أيضًا. وعندما يكتمل كل هذا ، ينظفون أنفسهم. وأود أن أشير إلى أن الجميع يصطفون. وهو مشابه جدًا لحالة الازدحام المروري حيث ينتظر الجميع السيارة الأولى. توقفت السيارة الأولى واصطف الجميع في طابور طويل. ثم يتحرك ، ثم يمكن للسيارة التالية أن تتقدم وتحصل على كتلة ، وهكذا.
وإذا بدا لك أن الأمر لم يكن صعبًا بما يكفي ، فسنتحدث معك الآن عن المآزق. لا أعرف من منكم اختبرهم. هذه مشكلة شائعة إلى حد ما في أنظمة قواعد البيانات. لكن الجمود هو عندما تنتظر جلسة أخرى جلسة أخرى للقيام بشيء ما. وفي تلك اللحظة تنتظر جلسة أخرى الجلسة الأولى للقيام بشيء ما.
وعلى سبيل المثال ، إذا قال إيفان: "أعطني شيئًا" ، وقلت: "لا ، سأعطيك إياه فقط إذا أعطيتني شيئًا آخر." ويقول: "لا ، لن أعطيها لك إذا لم تعطها لي". وننتهي في موقف مسدود. أنا متأكد من أن إيفان لن يفعل ذلك ، لكنك حصلت على فكرة أن لدينا شخصين يريدان شيئًا وأنهما غير مستعدين للتنازل عنه حتى يمنحهما الشخص الآخر ما يريدانه. ولا يوجد حل.
وفي الواقع ، تحتاج قاعدة البيانات الخاصة بك إلى اكتشاف ذلك. وبعد ذلك تحتاج إلى حذف أو إغلاق إحدى الجلسات ، وإلا فإنها ستبقى هناك إلى الأبد. ونراه في قواعد البيانات ، ونراه في أنظمة التشغيل. وفي كل الأماكن التي لدينا فيها عمليات متوازية ، يمكن أن يحدث هذا.
وسنضع عقدين الآن. سنضع 50 و 80. في الصف الأول ، سأقوم بالتحديث من 50 إلى 50. سأحصل على المعاملة رقم 710.
ثم سأغير 80 إلى 81 ومن 50 إلى 51.
وهذا ما سيبدو عليه. وهكذا فإن 710 لديه قفل صف ، و 711 ينتظر التأكيد. رأينا ذلك عندما قمنا بتحديث. 710 - صاحب سلسلتنا. و 711 ينتظر 710 لإتمام الصفقة.
بل إنه يقول في أي صف لدينا مأزق. وهذا هو المكان الذي يبدأ فيه الأمر في أن يصبح غريبًا.
نقوم الآن بتحديث 80 إلى 80.
وهنا تبدأ المآزق. 710 ينتظر ردًا من 711 ، و 711 ينتظر 710. وهذا لن ينتهي بشكل جيد. ولا يوجد مخرج من هذا. وسيتوقعون ردا من بعضهم البعض.
ويبدأ في تأخير كل شيء. ونحن لا نريد ذلك.
ولدى Postgres طرق لملاحظة حدوث ذلك. وعندما يحدث ذلك ، تحصل على هذا الخطأ. ومن هذا يتضح أن عملية كذا وكذا تنتظر SHARE LOCK من عملية أخرى ، أي التي تم حظرها بواسطة عملية 711. وكانت تلك العملية في انتظار منح SHARE LOCK لمعرف المعاملة كذا وكذا ويتم حظره بواسطة عملية كذا وكذا. لذلك ، هناك حالة من الحجب الميت.
هل هناك طريق مسدود ثلاثي؟ هل هو ممكن؟ نعم.
نقود هذه الأرقام إلى الجدول. نغير 40 إلى 40 ، نصنع قفلًا.
قم بتغيير 60 إلى 61 ، ومن 80 إلى 81.
ثم نقوم بتغيير 80 ثم الازدهار!
و 714 ينتظر الآن 715. 716 ينتظر 715. ولا يوجد شيء يمكن القيام به حيال ذلك.
لم يعد هناك شخصان ، هناك ثلاثة أشخاص بالفعل. أريد منك شيئًا ، هذا الشخص يريد شيئًا من الشخص الثالث ، والشخص الثالث يريد شيئًا مني. وينتهي بنا المطاف في انتظار ثلاثي لأننا جميعًا ننتظر أن يكمل الشخص الآخر ما يتعين عليه القيام به.
ويعرف Postgres أي صف يحدث. وهكذا ستعطيك الرسالة التالية التي توضح أن لديك مشكلة حيث تمنع المدخلات الثلاثة بعضها البعض. ولا توجد قيود. قد يكون هذا هو الحال حيث يحظر 20 إدخالًا بعضها البعض.
العدد التالي قابل للتسلسل.
إذا كان قفل خاص قابل للتسلسل.
ونعود إلى 719. لديه مشكلة طبيعية تمامًا.
ويمكنك الدفع لإجراء معاملة من قابلة للتسلسل.
وأنت تدرك أن لديك الآن نوعًا مختلفًا من حظر SA - وهذا يعني أنه قابل للتسلسل.
ولذا لدينا نوع جديد من القفل يسمى SARieadLock ، وهو قفل تسلسلي ويسمح لك بإدخال الأرقام التسلسلية.
ويمكنك أيضًا إدراج فهارس فريدة.
في هذا الجدول لدينا فهارس فريدة.
إذا وضعت الرقم 2 هنا ، فهذا هو سبب وجود 2. ولكن في الأعلى ، وضعت 2 أخرى. ويمكنك أن ترى أن 721 لديه قفل خاص. لكن الآن 722 ينتظر 721 لإكمال عمليته لأنه لا يمكن إدخال 2 حتى يعرف ما سيحدث لـ 721.
وإذا قمنا بإجراء معاملة فرعية.
لدينا هنا 723.
وإذا حفظنا النقطة ثم قمنا بتحديثها ، فسنحصل على معرف معاملات جديد. هذا سلوك آخر يجب أن تكون على دراية به. إذا أعدنا ذلك ، فسيختفي معرف المعاملة. 724 يغادر. لكن لدينا الآن 725.
وماذا أحاول أن أفعل هنا؟ أحاول أن أعرض لك أمثلة على الأقفال غير العادية التي يمكنك العثور عليها: سواء كانت أقفال قابلة للتسلسل أو أقفال SAVEPOINT ، فهذه أنواع مختلفة من الأقفال التي ستظهر في جدول القفل.
هذا هو إنشاء أقفال صريحة (صريحة) ، والتي تحتوي على pg_advisory_lock.
ويمكنك أن ترى أن نوع القفل مدرج هنا كاستشاري. وهنا تقول كلمة "استشاري" باللون الأحمر. ويمكنك الحظر في وقت واحد باستخدام pg_advisory_unlock.
وفي الختام ، أود أن أريكم شيئًا آخر يذهل العقل. سوف أقوم بإنشاء وجهة نظر أخرى. لكنني سوف أنضم إلى جدول pg_locks مع جدول pg_stat_activity. ولماذا اريد ان افعل هذا؟ لأنه سيسمح لي بالاطلاع على جميع الجلسات الحالية ومشاهدتها ومعرفة نوع الأقفال التي ينتظرونها. وهو أمر مثير للاهتمام بما يكفي عندما نجمع جدولًا مقفلًا وجدول استعلام.
وها نحن ننشئ pg_stat_view.
ونقوم بتحديث الصف بواحد. وهنا نرى 724. ثم نقوم بتحديث الصف إلى ثلاثة. وماذا ترى هنا الآن؟ هذه طلبات ، أي ترى القائمة الكاملة للطلبات المدرجة في العمود الأيمن. ثم على الجانب الأيمن يمكنك رؤية الأقفال وما تصنعه. ويمكن أن يكون مفهوماً أكثر بالنسبة لك بحيث لا تضطر إلى العودة إلى كل جلسة في كل مرة ومعرفة ما إذا كنت بحاجة إلى الانضمام إليها أم لا. يفعلون ذلك من أجلنا.
ميزة أخرى مفيدة للغاية هي pg_blocking_pids. ربما لم تسمع بها من قبل ماذا تفعل هي؟ يسمح لنا بإخبار هذه الجلسة 11740 ما هي معرفات العملية التي تنتظرها. ويمكنك أن ترى أن 11740 يتوقع 724. و 724 في القمة. و 11306 هو معرف العملية الخاص بك. بشكل أساسي ، تنتقل هذه الوظيفة إلى طاولة القفل الخاصة بك. وأنا أعلم أن الأمر معقد بعض الشيء ، لكنك فهمت الفكرة. بشكل أساسي ، تمر هذه الوظيفة عبر جدول القفل هذا وتحاول العثور على معرّف العملية هذا ، بالنظر إلى الأقفال التي تنتظرها. ويحاول أيضًا معرفة معرف العملية الذي تنتظره العملية التي تنتظر القفل. حتى تتمكن من تشغيل هذه الوظيفة pg_blocking_pids.
وهذا مفيد جدا. لقد أضفنا هذا فقط منذ الإصدار 9.6 ، لذا فإن هذه الميزة عمرها 5 سنوات فقط ، لكنها مفيدة جدًا جدًا. والشيء نفسه ينطبق على الطلب الثاني. إنه يظهر بالضبط ما نحتاج إلى رؤيته.
هذا ما أردت أن أتحدث إليكم عنه. وكما توقعت ، فقد استنفدنا كل وقتنا لأنه كان هناك الكثير من الشرائح. والشرائح متاحة للتنزيل. أود أن أشكرك على وجودك هنا. أنا متأكد من أنك ستستمتع ببقية المؤتمر ، شكرًا جزيلاً لك!
الأسئلة:
على سبيل المثال ، إذا حاولت تحديث الصفوف ، وحاولت الجلسة الثانية حذف الجدول بأكمله. بقدر ما أفهم ، يجب أن يكون هناك شيء مثل قفل النية. هل يوجد شيء من هذا القبيل في Postgres؟
نعود إلى البداية. قد تتذكر أنه عندما تفعل أي شيء ، مثل عندما تفعل SELECT ، فإننا نصدر AccessShareLock. ويمنع سقوط الطاولة. لذلك ، إذا كنت تريد ، على سبيل المثال ، تحديث صف في جدول أو حذف صف ، فلن يتمكن شخص ما من حذف الجدول بأكمله في نفس الوقت ، لأنك تحتفظ بـ AccessShareLock هذا فوق الجدول بأكمله وفوق الصف. وبمجرد الانتهاء ، يمكنهم إزالته. ولكن طالما قمت بتغيير شيء ما هناك بشكل مباشر ، فلن يتمكنوا من القيام بذلك.
دعونا نفعل ذلك مرة أخرى. دعنا ننتقل إلى مثال الحذف. وترى كيف أن الصف له قفل خاص على الطاولة بأكملها.
سيبدو مثل قفل حصري ، أليس كذلك؟
نعم ، يبدو الأمر كذلك. أنا أفهم ما تتحدث عنه. هل تقول أنه إذا قمت بإجراء SELECT ، فسيكون لدي ShareExclusive ثم أضعه في حالة "صف حصري" ، فهل يصبح ذلك مشكلة؟ لكن من المستغرب أن هذا لا يمثل مشكلة. إنه يشبه زيادة درجة القفل ، لكن لدي بشكل أساسي قفل يمنع حذفه. والآن ، عندما أجعل هذا القفل أكثر قوة ، فإنه لا يزال يمنع الحذف. لذلك ليس الأمر كما لو أنني صعد. أي أنه منعه عندما كان في مستوى أدنى أيضًا ، لذلك عندما أرفعه ، فإنه لا يزال يمنع الطاولة من السقوط.
أنا أفهم ما تتحدث عنه. لا توجد حالة لزيادة درجة الحجب ، حيث تحاول التخلي عن كتلة واحدة من أجل تقديم كتلة أكثر قوة. هنا يزيد فقط من هذا التجنب في كل مكان ، لذلك لا يسبب أي تعارض. لكنه سؤال جيد. شكرا جزيلا لسؤالك!
ما الذي يتعين علينا القيام به لتجنب حالة الجمود عندما يكون لدينا العديد من الجلسات ، وعدد كبير من المستخدمين؟
يلاحظ Postgres تلقائيًا حالات الجمود. وسيقوم تلقائيًا بحذف إحدى الجلسات. الطريقة الوحيدة لتجنب حالة الجمود هي حظر الأشخاص بنفس الترتيب. لذلك عندما تنظر إلى التطبيق الخاص بك ، غالبًا ما يكون هذا هو سبب الجمود ... لنفترض أنني أريد حظر شيئين مختلفين. يقوم أحد التطبيقات بإقفال الجدول 1 وتطبيق آخر يقوم بإقفال الجدول 2 ثم الجدول 1. وأسهل طريقة لتجنب حالات الجمود هي إلقاء نظرة على تطبيقك ومحاولة التأكد من حدوث القفل بنفس الترتيب في جميع التطبيقات. وهذا عادة ما يزيل 80٪ من المشاكل ، لأن جميع أنواع الناس يكتبون هذه التطبيقات. وإذا قمت بحظرهم بنفس الترتيب ، فلن تواجه موقفًا مسدودًا.
شكرا جزيلا على أدائك! لقد تحدثت عن فراغ ممتلئ ، وإذا فهمت بشكل صحيح ، فإن الفراغ الكامل يفسد ترتيب السجلات في متجر منفصل ، لذلك يحافظ على السجلات الحالية دون تغيير. لماذا يأخذ الفراغ الكامل وصول قفل حصري ولماذا يتعارض مع عمليات الكتابة؟
هذا سؤال جيد. والسبب هو أن الفراغ الممتلئ يأخذ طاولة. ونقوم بشكل أساسي بإنشاء نسخة جديدة من الجدول. وستكون الطاولة جديدة. اتضح أنه سيكون نسخة جديدة تمامًا من الجدول. والمشكلة هي أنه عندما نفعل ذلك ، لا نريد أن يقرأه الناس لأننا نريدهم أن يروا الجدول الجديد. وهذا يرتبط بالسؤال السابق. إذا تمكنا من القراءة في نفس الوقت ، فلن نتمكن من نقله وتوجيه الأشخاص إلى طاولة جديدة. يجب أن ننتظر حتى ينتهي الجميع من قراءة هذا الجدول ، وبالتالي ، في الأساس ، هذا هو الوضع الحصري للقفل.
نحن نقول فقط إننا مقفل منذ البداية لأننا نعلم أننا سنحتاج إلى قفل خاص في النهاية لنقل الجميع إلى النسخة الجديدة. لذلك من المحتمل أن نتمكن من حلها. وهذه هي الطريقة التي نقوم بها بالفهرسة الآنية. لكن هذا أصعب بكثير. وهذا ينطبق بشدة على سؤالك السابق حول القفل الحصري.
هل من الممكن إضافة مهلة القفل في Postgres؟ في Oracle ، يمكنني ، على سبيل المثال ، كتابة "تحديد للتحديث" والانتظار لمدة 50 ثانية قبل التحديث. كانت جيدة للتطبيق. لكن في Postgres ، إما أن أحتاج إلى القيام بذلك على الفور وعدم الانتظار على الإطلاق ، أو الانتظار حتى بعض الوقت.
نعم ، يمكنك اختيار مهلة أقفالك ، أقفالك. يمكنك أيضًا إصدار الأمر no way ، والذي سيكون ... إذا لم تتمكن من الحصول على القفل على الفور. لذلك ، إما قفل المهلة ، أو أي شيء آخر يسمح لك بالقيام بذلك. لا يتم ذلك على المستوى النحوي. يتم ذلك كمتغير على الخادم. في بعض الأحيان لا يمكن استخدامه.
هل يمكنك فتح الشريحة 75؟
نعم.
وسؤالي هو التالي. لماذا تنتظر عمليتا التحديث 703؟
وهذا سؤال رائع. بالمناسبة ، لا أفهم سبب قيام Postgres بهذا. ولكن عندما تم إنشاء 703 ، كانت تنتظر 702. وعندما تظهر 704 و 705 ، لا يبدو أنهم يعرفون ما الذي ينتظرونه ، لأنه لا يوجد شيء هناك حتى الآن. ويقوم Postgres بذلك على النحو التالي: عندما لا يمكنك الحصول على قفل ، فإنه يقول "ما الهدف من معالجتك؟" ، لأنك تنتظر بالفعل شخصًا ما. لذلك فقط اتركها معلقة في الهواء ، فلن تقوم بتحديثها على الإطلاق. لكن ماذا حدث هنا؟ حالما أكمل 702 العملية واستلم 703 قفله ، عاد النظام مرة أخرى. وقالت إن لدينا الآن شخصان ينتظران. ثم دعونا نقوم بتحديثها معًا. وتشير إلى أن كلاهما متوقع.
لا أعرف لماذا يقوم Postgres بهذا. لكن هناك مشكلة تسمى f…. يبدو لي أن هذا ليس مصطلحًا باللغة الروسية. هذا عندما ينتظر الجميع قلعة واحدة ، حتى لو كان هناك 20 حالة تنتظر القلعة. وفجأة يستيقظون جميعًا في نفس الوقت. ويبدأ الجميع في محاولة الرد. لكن النظام يجعل الجميع ينتظر 703. لأنهم جميعًا ينتظرون ، وسنقوم على الفور بترتيبهم جميعًا. وإذا ظهر أي طلب جديد تم تشكيله بعد ذلك ، على سبيل المثال 707 ، فسيكون هناك فراغ مرة أخرى.
ويبدو لي أن هذا يتم حتى أتمكن من القول إنه في هذه المرحلة 702 ينتظر 703 ، وكل من سيأتي بعد ذلك لن يكون لهم أي دخول في هذا المجال. ولكن بمجرد أن يغادر النادل الأول ، يتلقى كل من كانوا ينتظرون في تلك اللحظة قبل التحديث نفس الرمز المميز. ولذا يبدو لي أن هذا يتم حتى نتمكن من المعالجة بالترتيب ، بحيث يتم ترتيبها بشكل صحيح.
لطالما نظرت إليها على أنها ظاهرة غريبة إلى حد ما. لأنهم هنا ، على سبيل المثال ، غير مدرجين على الإطلاق. ولكن يبدو لي أنه في كل مرة نعطي فيها قفلًا جديدًا ، فإننا ننظر إلى كل أولئك الذين هم في طور الانتظار. ثم نصطفهم جميعًا. وبعد ذلك يتم وضع أي واحد جديد يأتي في قائمة الانتظار فقط عندما ينتهي الشخص التالي من المعالجة. سؤال جيد جدا. شكرا جزيلا على سؤالك!
يبدو لي أكثر منطقية عندما يتوقع 705 704.
لكن المشكلة هنا هي التالية. من الناحية الفنية ، يمكنك أن تستيقظ إما واحدًا أو ذاك. وهكذا نستيقظ واحدًا أو آخر. لكن ماذا يحدث في تشغيل النظام؟ يمكنك أن ترى كيف قام 703 في الجزء العلوي بحظر معرف المعاملة الخاص به. هذه هي الطريقة التي يعمل بها Postgres. وتم حظر 703 بواسطة معرف المعاملة الخاص به ، لذلك إذا أراد شخص ما الانتظار ، فسوف ينتظر 703. وفي الواقع ، اكتمل 703. وفقط بعد اكتمالها ، تستيقظ إحدى العمليات. ولا نعرف أي نوع من العملية ستكون. ثم نقوم بمعالجة كل شيء تدريجيًا. لكن ليس من الواضح أي عملية تستيقظ أولاً ، لأنها يمكن أن تكون أيًا من هذه العمليات. في الأساس ، كان لدينا برنامج جدولة قال إنه يمكننا الآن إيقاظ أي من هذه العمليات. نحن فقط نختار واحدة عشوائيا. لذلك ، يجب ملاحظة كلاهما ، لأنه يمكننا إيقاظ أي منهما.
والمشكلة هي أن لدينا CP- اللانهاية. وبالتالي ، من المحتمل جدًا أن نتمكن من إيقاظ الشخص اللاحق. وإذا استيقظنا لاحقًا ، على سبيل المثال ، فسننتظر الشخص الذي تلقى القفل للتو ، لذلك لا نحدد من الذي سيتم إيقاظه بالضبط أولاً. نحن نخلق مثل هذا الموقف تمامًا ، وسيقوم النظام بإيقاظهم بشكل عشوائي.
هنالك . انظروا ، هم أيضا مثيرون للاهتمام ومفيدون. الموضوع ، بالطبع ، معقد بشكل رهيب. شكرا جزيلا بروس!
المصدر: www.habr.com