Redis استعمال ڪندي ورهايل تالا

اي حبر!

اڄ اسان توهان جي ڌيان ۾ آڻيون ٿا هڪ پيچيده مضمون جو ترجمو ريڊس استعمال ڪندي ورهايل لاڪنگ جي عمل جي باري ۾ ۽ توهان کي دعوت ڏيون ٿا ريڊس جي امڪانن بابت هڪ موضوع جي طور تي. مارٽن ڪلپمن کان سوال ۾ ريڊ لاک الگورٿم جو تجزيو، ڪتاب جو ليکڪ "هاء لوڊ ايپليڪيشنون"، ڏنو هتي.

ورهايل لاڪنگ هڪ تمام مفيد پرائمري آهي جيڪو ڪيترن ئي ماحولن ۾ استعمال ٿيندو آهي جتي مختلف عملن کي گڏيل وسيلن تي گڏيل طور تي خاص طريقي سان ڪم ڪرڻ گهرجي.

اتي ڪيتريون ئي لائبريريون ۽ پوسٽون موجود آهن جيڪي بيان ڪن ٿيون ته ڪيئن لاڳو ڪجي DLM (ڊسٽريبيوٽڊ لاڪ مئنيجر) Redis استعمال ڪندي، پر هر لائبريري هڪ مختلف طريقو اختيار ڪري ٿي ۽ انهن جي مهيا ڪيل ضمانتون ڪافي ڪمزور آهن ان جي مقابلي ۾ جيڪي حاصل ڪري سگهجن ٿا ان جي مقابلي ۾ ٿورڙي وڌيڪ نفيس ڊيزائن سان.

هن آرٽيڪل ۾ اسان هڪ مشروط ڪيننيڪل الگورٿم بيان ڪرڻ جي ڪوشش ڪنداسين جيڪو ڏيکاري ٿو ته ڪيئن ورهايل لاڪنگ کي لاڳو ڪرڻ Redis استعمال ڪندي. اسان هڪ الگورتھم جي باري ۾ ڳالهائينداسين ريڊ لاڪ، اهو هڪ ورهايل تالا مئنيجر کي لاڳو ڪري ٿو ۽، اسان جي راء ۾، هي الگورتھم عام واحد-مثال جي طريقي کان وڌيڪ محفوظ آهي. اسان کي اميد آهي ته ڪميونٽي ان جو تجزيو ڪندي، موٽ فراهم ڪندي، ۽ ان کي وڌيڪ پيچيده يا متبادل منصوبن لاءِ شروعاتي نقطي طور استعمال ڪندي.

عمل درآمد

الورورٿم جي وضاحت تي اڳتي وڌڻ کان اڳ، اسان تيار ڪيل عملن لاءِ ڪيترائي لنڪ مهيا ڪريون ٿا. اهي حوالي لاء استعمال ڪري سگهجي ٿو.

• ريڊ لاک- آر بي (روبي لاء لاڳو). پڻ آهي ڪانٽو Redlock-rb، جيڪو ورهائڻ جي آسانيءَ لاءِ هڪ پيڪيج (جيم) شامل ڪري ٿو، ۽ نه رڳو ان لاءِ.
• ريڊ لاک-پي (Python عمل درآمد).
• ايئرڊ لاک (Asyncio Python لاءِ عمل درآمد).
• Redlock-php (PHP لاءِ عمل درآمد).
• PHPRedisMutex (PHP لاءِ ٻيو عمل)
• cheprasov/php-redis-lock (PHP لائبريري تالو لاءِ)
• ريڊ سنڪ (جي لاءِ عمل درآمد).
• ريڊيسن (جاوا لاءِ عملدرآمد).
• ريڊيس::ڊسٽ لاڪ (Perl لاء لاڳو).
• ريڊ لاک-سي پي پي (سي ++ لاءِ عمل درآمد).
• Redlock-cs (C#/.NET لاءِ عمل درآمد).
• RedLock.net (C#/.NET لاءِ عمل درآمد). async ۽ تالا لڳائڻ جي حمايت سان.
• اسڪارٽ لاڪ (C# .NET لاءِ ترتيب ڏيڻ واري ڊيٽا اسٽور سان لاڳو)
• Redlock4Net (C# .NET لاءِ عمل درآمد)
• node-redlock (NodeJS لاءِ عمل درآمد). لاڪ وڌائڻ لاءِ سپورٽ شامل آھي.

سيڪيورٽي ۽ دستيابي جي ضمانتون

اسان پنهنجي ڊيزائن کي صرف ٽن خاصيتن سان ماڊل ڪرڻ وارا آهيون جيڪي اسان سمجهون ٿا ته گهٽ ۾ گهٽ گارنٽي فراهم ڪريون جيڪي موثر طريقي سان ورهايل لاڪنگ کي استعمال ڪرڻ لاءِ گهربل هجن.

1. سيڪيورٽي ملڪيت: باهمي خارج ڪرڻ. ڪنهن به وقت، صرف هڪ گراهڪ تالا رکي سگهي ٿو.
2. دستيابي ملڪيت A: ڪابه رڪاوٽ نه آهي. اهو هميشه ممڪن آهي ته آخرڪار هڪ تالا حاصل ڪرڻ، جيتوڻيڪ ڪلائنٽ جيڪو وسيلن کي بند ڪري ٿو ناڪام ٿئي ٿو يا مختلف ڊسڪ جي حصي تي لينڊ.
3. دستيابي ملڪيت B: غلطي رواداري. جيستائين ريڊس نوڊس جي اڪثريت هلائي رهيا آهن، گراهڪ حاصل ڪرڻ ۽ لاڪ ڇڏڻ جي قابل آهن.

ڇو ته ناڪامي جي بحالي جي بنياد تي عملدرآمد هن صورت ۾ ڪافي ناهي
سمجھڻ لاءِ ته اسان ڇا سڌارڻ وارا آھيون، اچو ته تجزيو ڪريون موجوده صورتحال جي اڪثريتي ورهايل لاڪنگ لائبريرين سان جيڪي ريڊس جي بنياد تي.

ريڊيس استعمال ڪندي وسيلن کي بند ڪرڻ جو آسان طريقو مثال ۾ هڪ ڪيچ ٺاهڻ آهي. عام طور تي، هڪ ڪيچي هڪ محدود حياتيءَ سان ٺاهي ويندي آهي، اهو حاصل ڪيو ويندو آهي ختم ٿيڻ واري خاصيت استعمال ڪندي ريڊس ۾ مهيا ڪيل، پوءِ جلد يا بعد ۾ هي ڪيئي جاري ڪئي ويندي آهي (اسان جي لسٽ ۾ ملڪيت 2). جڏهن ڪلائنٽ کي وسيلن کي ڇڏڻ جي ضرورت آهي، اهو کلي کي ختم ڪري ٿو.

پهرين نظر ۾، هي حل تمام سٺو ڪم ڪري ٿو، پر اتي هڪ مسئلو آهي: اسان جو فن تعمير ناڪامي جو هڪ واحد نقطو پيدا ڪري ٿو. ڇا ٿيندو جيڪڏهن ميزبان Redis مثال ناڪام ٿئي؟ اچو ته هڪ غلام کي شامل ڪريو! ۽ اسان ان کي استعمال ڪنداسين جيڪڏهن پيش ڪندڙ دستياب ناهي. بدقسمتي سان، هي اختيار قابل عمل ناهي. ائين ڪرڻ سان، اسان باہمي خارج ڪرڻ واري ملڪيت کي صحيح طريقي سان لاڳو ڪرڻ جي قابل نه ٿي سگهنداسين جيڪا اسان کي حفاظت کي يقيني بڻائڻ جي ضرورت آهي، ڇاڪاڻ ته ريڊس ۾ نقل غير مطابقت رکندڙ آهي.

ظاهر آهي، اهڙي نموني ۾ هڪ نسل جي حالت ٿيندي آهي:

1. ڪلائنٽ A ماسٽر تي هڪ تالا حاصل ڪري ٿو.
2. مکيه داخلا غلام ڏانهن منتقل ٿيڻ کان اڳ ماسٽر ناڪام ٿئي ٿو.
3. پيروڪار کي اڳواڻ ڏانهن وڌايو ويندو آهي.
4. ڪلائنٽ B ساڳئي وسيلن تي هڪ تالا حاصل ڪري ٿو جيڪو A اڳ ۾ ئي بند ڪيو آهي. سيڪيورٽي جي ڀڃڪڙي!

ڪڏهن ڪڏهن اهو مڪمل طور تي عام آهي ته خاص حالتن ۾، جهڙوڪ ناڪامي، ڪيترائي گراهڪ هڪ ئي وقت بند ڪري سگهن ٿا. اهڙين حالتن ۾، هڪ نقل تي ٻڌل حل لاڳو ڪري سگهجي ٿو. ٻي صورت ۾، اسان هن مضمون ۾ بيان ڪيل حل جي صلاح ڏين ٿا.

ھڪڙي مثال سان صحيح عمل درآمد

مٿي بيان ڪيل سنگل مثال جي جوڙجڪ جي خامين کي دور ڪرڻ جي ڪوشش ڪرڻ کان اڳ، اچو ته سمجھون ته هن سادي ڪيس کي ڪيئن صحيح طريقي سان سنڀالجي، ڇو ته اهو حل اصل ۾ انهن ايپليڪيشنن ۾ صحيح آهي جتي نسل جي حالت وقت بوقت قابل قبول هوندي آهي، ۽ اهو پڻ ڇاڪاڻ ته بلاڪنگ اڪيلو مثال طور ڪم ڪري ٿو بنياد جيڪو هتي بيان ڪيل ورهايل الگورتھم ۾ استعمال ٿئي ٿو.

تالا حاصل ڪرڻ لاء، هي ڪريو:

SET resource_name my_random_value NX PX 30000

هي حڪم صرف ان صورت ۾ هڪ ڪني کي انسٽال ڪري ٿو جڏهن اهو اڳ ۾ ئي موجود ناهي (NX آپشن)، 30000 مليسيڪنڊ (PX آپشن) جي صحيح مدت سان. چاٻي مقرر ڪئي وئي آهي "myrandomvalue" هي قدر سڀني گراهڪن ۽ سڀني تالا جي درخواستن ۾ منفرد هجڻ گهرجي.
بنيادي طور تي، هڪ بي ترتيب قدر استعمال ڪيو ويندو آهي محفوظ طور تي تالا ڇڏڻ لاء، هڪ اسڪرپٽ ٻڌائيندي Redis سان: صرف ان کي هٽائي ڇڏيو جيڪڏهن اهو موجود آهي ۽ ان ۾ محفوظ ڪيل قيمت بلڪل آهي جيڪا توقع ڪئي وئي هئي. اهو هيٺ ڏنل لوا اسڪرپٽ استعمال ڪندي حاصل ڪيو ويو آهي:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

اهو ضروري آهي ته ڪنهن ٻئي ڪلائنٽ طرفان بند ٿيل تالا کي هٽائڻ کان روڪيو وڃي. مثال طور، هڪ ڪلائنٽ هڪ تالا حاصل ڪري سگهي ٿو، پوء ڪجهه آپريشن ۾ بند ٿي وڃي ٿو جيڪو پهرين تالا کان وڌيڪ ڊگهو آهي (انهي ڪري ته چاٻي کي ختم ٿيڻ جو وقت آهي)، ۽ بعد ۾ اهو تالا هٽائي ڇڏيو جيڪو ڪنهن ٻئي ڪلائنٽ رکيو هو.
هڪ سادي DEL استعمال ڪرڻ غير محفوظ آهي ڇاڪاڻ ته هڪ ڪلائنٽ هڪ ٻئي ڪلائنٽ طرفان رکيل تالا کي ختم ڪري سگهي ٿو. ان جي ابتڙ، جڏهن مٿي ڏنل اسڪرپٽ استعمال ڪندي، هر تالا بي ترتيب واري تار سان "سائن ٿيل" هوندو آهي، تنهنڪري صرف ڪلائنٽ جيڪو اڳ ۾ رکيل هو ان کي ختم ڪري سگهي ٿو.

هي بي ترتيب تار ڇا هجڻ گهرجي؟ مان اندازو ڪري رهيو آهيان ته اهو /dev/urandom کان 20 بائيٽ هجڻ گهرجي، پر توهان گهٽ قيمتي طريقا ڳولي سگهو ٿا تار کي پنهنجي مقصدن لاءِ ڪافي منفرد بڻائڻ لاءِ. مثال طور، RC4 کي /dev/urandom سان ٻج ڪرڻ ۽ پوءِ ان مان هڪ pseudo-random وهڪرو پيدا ڪرڻ ٺيڪ هوندو. ھڪڙو آسان حل شامل آھي يونڪس وقت جو ميلاپ مائڪرو سيڪنڊ ريزوليوشن ۽ ڪلائنٽ ID ۾؛ اهو محفوظ نه آهي، پر اهو شايد گهڻو ڪري ڪم تي منحصر آهي.

جيڪو وقت اسان استعمال ڪريون ٿا چاٻي جي حياتيءَ جي ماپ لاءِ ان کي ”لاف لائف ٽائيم“ چئجي ٿو. اها قيمت ٻئي وقت جي رقم آهي ان کان اڳ جو لاڪ خود بخود جاري ٿي وڃي ۽ وقت جي مقدار جو هڪ ڪلائنٽ هڪ آپريشن مڪمل ڪرڻ کان پهريان ٻيو ڪلائنٽ ان وسيلن کي بند ڪري سگهي ٿو، اصل ۾ باهمي خارج ڪرڻ جي ضمانت جي ڀڃڪڙي ڪرڻ کان سواءِ. اها گارنٽي صرف وقت جي هڪ مخصوص ونڊو تائين محدود آهي، جيڪا ان وقت کان شروع ٿئي ٿي جڏهن تالا خريد ڪيو ويندو آهي.

تنهنڪري اسان هڪ تالا حاصل ڪرڻ ۽ ڇڏڻ لاء هڪ سٺو طريقو بحث ڪيو آهي. سسٽم (جيڪڏهن اسان هڪ غير ورهايل سسٽم بابت ڳالهائي رهيا آهيون جنهن ۾ هڪ واحد ۽ هميشه موجود مثال شامل آهي) محفوظ آهي. اچو ته هن تصور کي ورهايل نظام ڏانهن وڌايون، جتي اسان وٽ ڪا به ضمانت نه آهي.

Redlock الگورتھم

الگورٿم جو ورهايل ورزن فرض ڪري ٿو ته اسان وٽ N Redis ماسٽرز آهن. اهي نوڊس هڪ ٻئي کان مڪمل طور تي آزاد آهن، تنهنڪري اسان نقل يا ڪنهن ٻئي ضمني ڪوآرڊينيشن سسٽم استعمال نٿا ڪريون. اسان اڳ ۾ ئي ڍڪي ڇڏيو آهي ته ڪيئن محفوظ طور تي حاصل ڪرڻ ۽ هڪ واحد مثال تي تالا ڇڏڻ. اسان ان کي تسليم ڪريون ٿا ته الورورٿم، جڏهن هڪ واحد مثال سان ڪم ڪندي، اهو ئي طريقو استعمال ڪندو. اسان جي مثالن ۾ اسان مقرر ڪيو N کان 5، جيڪو هڪ مناسب قدر آهي. اهڙيء طرح، اسان کي استعمال ڪرڻ جي ضرورت پوندي 5 ريڊس ماسٽر مختلف ڪمپيوٽرن يا ورچوئل مشينن تي يقيني بڻائڻ لاءِ ته اهي هڪ ٻئي کان وڏي حد تائين آزاديءَ سان ڪم ڪن.

تالا حاصل ڪرڻ لاء، ڪلائنٽ هيٺين عملن کي انجام ڏئي ٿو:

1. مليس سيڪنڊن ۾ موجوده وقت حاصل ڪري ٿو.
2. ترتيب سان سڀني N مثالن تي تالا حاصل ڪرڻ جي ڪوشش ڪري ٿو، سڀني صورتن ۾ ساڳيو اهم نالو ۽ بي ترتيب قدر استعمال ڪندي. اسٽيج 2 ۾، جڏهن ڪلائنٽ في مثال جي بنياد تي هڪ لاڪ سيٽ ڪري ٿو، ڪلائنٽ ان کي حاصل ڪرڻ لاءِ دير استعمال ڪري ٿو جيڪو ان وقت جي مقابلي ۾ ڪافي ننڍو آهي جنهن کان پوءِ تالا پاڻمرادو آزاد ٿي ويندو آهي. مثال طور، جيڪڏهن بلاڪ ڪرڻ جو عرصو 10 سيڪنڊ آهي، ته پوءِ دير ٿي سگهي ٿي ~ 5-50 ملي سيڪنڊن جي حد ۾. هي ان صورتحال کي ختم ڪري ٿو جنهن ۾ ڪلائنٽ هڪ ڊگهي وقت تائين بلاڪ رهي سگهي ٿي ناڪام ريڊس نوڊ تائين پهچڻ جي ڪوشش ڪندي: جيڪڏهن مثال دستياب ناهي، ته پوءِ اسان ڪوشش ڪريون ٿا ته جلد کان جلد ڪنهن ٻئي مثال سان ڳنڍڻ جي.
3. تالا ڪڍڻ لاءِ، ڪلائنٽ حساب ڪري ٿو ته ڪيترو وقت گذري چڪو آهي؛ هن کي ڪرڻ لاءِ، اهو اصل وقت جي قيمت مان گھٽائي ٿو ٽائم اسٽيمپ جيڪا حاصل ڪئي وئي هئي قدم 1 ۾. جيڪڏهن ۽ صرف ان صورت ۾ جڏهن ڪلائنٽ اڪثريت (گهٽ ۾ گهٽ 3) تي تالا حاصل ڪرڻ جي قابل هو، ۽ ان ۾ لڳل ڪل وقت تالا حاصل ڪريو، تالا جي مدت کان گهٽ، تالا حاصل ڪيو ويو سمجهيو ويندو آهي.
4. جيڪڏهن هڪ تالا حاصل ڪيو ويو آهي، تالا جي مدت کي اصل تالا جي مدي ۾ ورتو وڃي ٿو مائنس جيڪو گذري ويو وقت 3 ۾ حساب ڪيو ويو آهي.
5. جيڪڏهن ڪلائنٽ ڪنهن سبب جي ڪري تالا حاصل ڪرڻ ۾ ناڪام ٿئي ٿو (يا ته اهو N/2+1 مثالن کي لاڪ ڪرڻ جي قابل نه هو، يا لاڪ جو مدو منفي هو)، پوءِ اهو ڪوشش ڪندو ته سڀني مثالن کي ان لاڪ ڪرڻ جي ڪوشش ڪندو (جيتوڻيڪ اهو سوچيو ته اهو بلاڪ نٿو ڪري سگهي. ).

ڇا الورورٿم هم وقت ساز آهي؟

هي الگورٿم ان مفروضي تي مبني آهي ته، جيتوڻيڪ اتي ڪا هم وقت ساز ڪلاڪ نه آهي جنهن تي سڀئي عمل ڪم ڪن، هر عمل ۾ مقامي وقت اڃا به لڳ ڀڳ ساڳئي رفتار سان وهندو آهي، ۽ غلطي ان مجموعي وقت جي مقابلي ۾ ننڍي آهي جنهن کان پوءِ تالا لڳل آهي. خودڪار طور تي آزاد. اهو مفروضو عام ڪمپيوٽرن لاءِ عام صورتحال سان تمام گهڻو ملندڙ جلندڙ آهي: هر ڪمپيوٽر ۾ هڪ مقامي ڪلاڪ آهي، ۽ اسان عام طور تي ان حقيقت تي شمار ڪري سگهون ٿا ته مختلف ڪمپيوٽرن جي وچ ۾ وقت جو فرق ننڍڙو آهي.

هن نقطي تي، اسان کي وڌيڪ احتياط سان اسان جي باهمي خارج ڪرڻ واري قاعدي کي ترتيب ڏيڻ گهرجي: باهمي خارج ٿيڻ جي ضمانت صرف ان صورت ۾ ڏني وئي آهي جڏهن ڪلائنٽ لاڪ جي صحيح هجڻ جي وقت کان ٻاهر نڪرندو آهي (هي قيمت قدم 3 ۾ حاصل ڪئي وئي آهي)، گهٽ ۾ گهٽ ڪجهه وڌيڪ وقت (ڪل ڪجهه عملن جي وچ ۾ وقت جي فرق جي تلافي ڪرڻ لاءِ مليسيڪنڊ).

هيٺ ڏنل دلچسپ مضمون اهڙن نظامن جي باري ۾ وڌيڪ ٻڌائي ٿو جيڪي وقت جي وقفن جي همراهن جي ضرورت آهي: ليز: ورهايل فائل ڪيش جي مستقل مزاجي لاءِ هڪ موثر غلطي برداشت ڪرڻ وارو ميڪانيزم.

ناڪامي تي ٻيهر ڪوشش ڪريو

جڏهن هڪ گراهڪ تالا حاصل ڪرڻ ۾ ناڪام ٿئي ٿو، ان کي بي ترتيب دير کان پوء ٻيهر ڪوشش ڪرڻ گهرجي؛ اهو هڪ ئي وقت هڪ ئي وسيلن تي تالا حاصل ڪرڻ جي ڪوشش ڪندڙ ڪيترن ئي ڪلائنٽ کي ختم ڪرڻ لاءِ ڪيو ويو آهي (جيڪو "اسپلٽ-برين" واري صورتحال کي جنم ڏئي سگهي ٿو جنهن ۾ ڪو به فاتح ناهي). اضافي طور تي، تيزيءَ سان هڪ ڪلائنٽ اڪثريتي ريڊيس مثالن تي تالا حاصل ڪرڻ جي ڪوشش ڪندو آهي، اوتري ئي ونڊو تنگ ٿيندي جنهن ۾ ورهايل دماغي صورتحال ٿي سگهي ٿي (۽ ٻيهر ڪوششن جي ضرورت گهٽ هوندي). تنهن ڪري، مثالي طور تي، ڪلائنٽ کي ڪوشش ڪرڻ گهرجي SET حڪمن کي N مثالن تي هڪ ئي وقت ملٽي پلڪسنگ استعمال ڪندي.

هتي اهو زور ڏيڻ جي قابل آهي ته اهو ڪلائنٽ لاءِ ڪيترو اهم آهي جيڪي اڪثريتي لاڪ حاصل ڪرڻ ۾ ناڪام ٿين ٿا (جزوي طور تي) حاصل ڪيل تالن کي ڇڏڻ لاءِ، انهي ڪري انهن کي ٻيهر حاصل ڪرڻ کان پهريان چاٻي جي ختم ٿيڻ جو انتظار نه ڪرڻو پوي. (جيتوڻيڪ جيڪڏهن نيٽ ورڪ جو ٽڪراءُ ٿئي ٿو، ۽ گراهڪ Redis مثالن سان رابطو وڃائي ٿو، ته پوءِ توهان کي دستيابي ڏنڊ ادا ڪرڻو پوندو جڏهن ته چاٻي ختم ٿيڻ جي انتظار ۾).

تالا ڇڏايو

لاڪ جاري ڪرڻ هڪ سادي آپريشن آهي جنهن لاءِ صرف سڀني مثالن کي ان لاڪ ڪرڻ جي ضرورت آهي، قطع نظر ته ڪلائنٽ ڪنهن خاص مثال کي ڪاميابيءَ سان بند ڪري ڇڏيو آهي.

سيڪيورٽي خيالات

ڇا الورورٿم محفوظ آهي؟ اچو ته تصور ڪرڻ جي ڪوشش ڪريون ته مختلف حالتن ۾ ڇا ٿئي.

شروع ڪرڻ سان، اچو ته فرض ڪريون ته ڪلائنٽ اڪثريت جي صورتن تي تالا حاصل ڪرڻ جي قابل ٿي ويو. هر مثال ۾ هڪ اهم شامل هوندو جنهن ۾ سڀني لاءِ ساڳي زندگي هوندي. بهرحال، انهن مان هر هڪ مختلف وقتن تي نصب ڪيو ويو آهي، تنهنڪري اهي مختلف وقتن تي ختم ٿي ويندا. پر، جيڪڏهن پهرين چاٻي ڪنهن وقت تي نصب ڪئي وئي هئي T1 کان وڌيڪ خراب ناهي (جنهن وقت اسان پهرين سرور سان رابطو ڪرڻ کان اڳ چونڊيو ٿا)، ۽ آخري چيڪ نصب ڪيو ويو هو هڪ وقت تي T2 کان وڌيڪ خراب ناهي (جنهن وقت جواب ملي ويو هو. آخري سرور کان)، پوء اسان کي يقين آهي ته سيٽ ۾ پهرين ڪنجي جيڪا ختم ٿي ويندي آهي گهٽ ۾ گهٽ زنده رهندي MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. ٻيون سڀئي چابيون بعد ۾ ختم ٿي وينديون، تنهنڪري اسان پڪ ڪري سگهون ٿا ته سڀئي ڪنجيون هڪ ئي وقت گهٽ ۾ گهٽ هن وقت لاءِ صحيح هونديون.

ان وقت جي دوران جڏهن اڪثر ڪنجيون صحيح رهنديون، ٻيو ڪلائنٽ لاڪ حاصل ڪرڻ جي قابل نه هوندو، ڇاڪاڻ ته N/2+1 SET NX آپريشن ڪامياب نه ٿي سگهندا جيڪڏهن N/2+1 چاٻيون اڳ ۾ ئي موجود آهن. تنهن ڪري، هڪ ڀيرو هڪ تالا حاصل ڪيو ويو آهي، اهو ناممڪن آهي ته ان کي ٻيهر حاصل ڪرڻ ساڳئي وقت (اهو باهمي خارج ڪرڻ واري ملڪيت جي ڀڃڪڙي ڪندو).
تنهن هوندي، اسان اهو پڪ ڪرڻ چاهيون ٿا ته هڪ ئي وقت ۾ هڪ تالا حاصل ڪرڻ جي ڪوشش ڪندڙ ڪيترائي گراهڪ هڪ ئي وقت ۾ ڪامياب نٿا ٿي سگهن.

جيڪڏهن ڪلائنٽ اڪثريتن کي لاڪ ڪيو آهي تقريبن يا ان کان وڌيڪ لاڪ جي مدي تائين، اهو تالا کي غلط سمجھندو ۽ مثالن کي ان لاڪ ڪندو. تنهن ڪري، اسان کي صرف ان صورت ۾ رکڻو پوندو جنهن ۾ ڪلائنٽ کي ختم ٿيڻ جي تاريخ کان گهٽ وقت ۾ اڪثريت جي اڪثريت کي بلاڪ ڪرڻ جو انتظام ڪيو. انهي صورت ۾، مٿين دليل جي حوالي سان، وقت جي دوران MIN_VALIDITY ڪو به گراهڪ تالا ٻيهر حاصل ڪرڻ جي قابل نه هوندو. تنهن ڪري، ڪيترائي گراهڪ N/2+1 مثالن کي هڪ ئي وقت ۾ بند ڪري سگهندا (جيڪو اسٽيج 2 جي آخر ۾ ختم ٿئي ٿو) صرف ان وقت جڏهن اڪثريت کي لاڪ ڪرڻ جو وقت TTL وقت کان وڌيڪ هو، جيڪو تالا کي غلط قرار ڏئي ٿو.

ڇا توهان سيڪيورٽي جو باضابطه ثبوت مهيا ڪري سگهو ٿا، موجوده ساڳئي الگورتھم کي ظاهر ڪري سگهو ٿا، يا مٿين ۾ ڪو بگ ڳولي سگهو ٿا؟

پهچ جا ويچار

سسٽم جي دستيابي ٽن مکيه خاصيتن تي منحصر آهي:

1. پاڻمرادو لاڪ جاري ڪريو (جيئن چاٻيون ختم ٿين ٿيون): چاٻيون آخرڪار دستياب ٿي وينديون تالا لاءِ استعمال ٿيڻ لاءِ.
2. حقيقت اها آهي ته گراهڪ عام طور تي هڪ ٻئي جي مدد ڪندي تالا هٽائڻ سان جڏهن گهربل تالا حاصل نه ڪيو ويو آهي، يا حاصل ڪيو ويو آهي ۽ نوڪري مڪمل ٿي وئي آهي؛ تنهن ڪري اهو ممڪن آهي ته اسان کي تالا ٻيهر حاصل ڪرڻ لاءِ چاٻين جي ختم ٿيڻ جو انتظار نه ڪرڻو پوندو.
3. حقيقت اها آهي ته جڏهن هڪ گراهڪ کي هڪ تالا حاصل ڪرڻ لاء ٻيهر ڪوشش ڪرڻ جي ضرورت آهي، اهو نسبتا گهڻي وقت تائين انتظار ڪري ٿو جيڪو گهڻي عرصي کان وڌيڪ تالا حاصل ڪرڻ جي ضرورت آهي. اهو هڪ تقسيم دماغ جي صورتحال جو امڪان گھٽائي ٿو جڏهن وسيلن جي مقابلي ۾ پيدا ٿئي ٿي.

تنهن هوندي، اتي موجود آهي سزا جي برابر آهي نيٽ ورڪ حصن جي TTL جي برابر، تنهن ڪري جيڪڏهن اتي متضاد حصا آهن، سزا اڻڄاتل ٿي سگهي ٿي. اهو تڏهن ٿئي ٿو جڏهن هڪ ڪلائنٽ هڪ لاڪ حاصل ڪري ٿو ۽ پوءِ ان کي ڇڏڻ کان پهريان ڪنهن ٻئي حصي ڏانهن ڇڪي ٿو.

اصول ۾، لامحدود متضاد نيٽ ورڪ حصن کي ڏنو ويو آهي، هڪ سسٽم لامحدود عرصي تائين دستياب نه رهي سگهي ٿو.

ڪارڪردگي، ناڪامي ۽ fsync

ڪيترائي ماڻهو استعمال ڪندا آهن ريڊس ڇاڪاڻ ته انهن کي لاڪ حاصل ڪرڻ ۽ ڇڏڻ لاءِ گهربل دير جي لحاظ کان اعليٰ تالا سرور جي ڪارڪردگي جي ضرورت آهي، ۽ حاصلات / رليز جو تعداد جيڪو في سيڪنڊ مڪمل ڪري سگهجي ٿو. ھن ضرورت کي پورو ڪرڻ لاءِ، ويڪرائي گھٽائڻ لاءِ N Redis سرورز سان ڳالھ ٻولھ ڪرڻ جي حڪمت عملي آھي. هي هڪ ملٽي پلڪسنگ حڪمت عملي آهي (يا ”غريب ماڻهوءَ جي ملٽي پلڪسنگ“، جتي ساکٽ نان بلاڪنگ موڊ ۾ رکيل آهي، سڀ ڪمانڊ موڪلي ٿو، ۽ حڪمن کي بعد ۾ پڙهي ٿو، فرض ڪري ٿو ته ڪلائنٽ ۽ هر مثال جي وچ ۾ گول-ٽريپ جو وقت ساڳيو آهي) .

تنهن هوندي، اسان کي پڻ خيال رکڻو پوندو ڊگھي مدي واري ڊيٽا اسٽوريج سان لاڳاپيل غور جيڪڏهن اسان ناڪامين کان قابل اعتماد بحالي سان ماڊل ٺاهڻ جي ڪوشش ڪريون.

بنيادي طور تي، مسئلي کي واضع ڪرڻ لاء، اچو ته فرض ڪريون ته اسان ريڊيس کي ترتيب ڏيون ٿا تمام ڊگهي مدت واري ڊيٽا اسٽوريج سان. ڪلائنٽ 3 مان 5 مثالن کي بلاڪ ڪرڻ جو انتظام ڪري ٿو. ھڪڙو مثال جيڪو ڪلائنٽ کي بلاڪ ڪرڻ ۾ منظم ڪيو ويو آھي ٻيهر شروع ڪيو ويو آھي، ۽ ھن وقت ساڳئي وسيلن لاء 3 مثال آھن، جنھن کي اسين بلاڪ ڪري سگھون ٿا، ۽ ٻيو ڪلائنٽ، موڙ ۾، ٻيهر شروع ٿيل مثال کي بلاڪ ڪري سگھي ٿو، سيڪيورٽي ملڪيت جي ڀڃڪڙي ڪندي. تالا جي خاصيت کي فرض ڪري ٿو.

جيڪڏهن توهان ڊيٽا اڳيان (AOF) کي فعال ڪريو ٿا، صورتحال ٿوري بهتر ٿي ويندي. مثال طور، توهان SHUTDOWN حڪم موڪلڻ ۽ ان کي ٻيهر شروع ڪندي سرور کي فروغ ڏئي سگهو ٿا. جيئن ته ريڊس ۾ ختم ٿيڻ واري عملن کي لفظي طور تي لاڳو ڪيو ويو آهي انهي طريقي سان وقت جاري رهي ٿو جڏهن ته سرور بند ڪيو وڃي، اسان جون سڀئي گهرجون ٺيڪ آهن. اهو عام آهي جيستائين عام بند کي يقيني بڻايو وڃي. بجلي بند ٿيڻ جي صورت ۾ ڇا ڪجي؟ جيڪڏهن ريڊس ڊفالٽ طور ترتيب ڏنل آهي، هر سيڪنڊ ڊسڪ تي fsync هم وقت سازي سان، پوء اهو ممڪن آهي ته ٻيهر شروع ڪرڻ کان پوء اسان وٽ اسان جي ڪيچ نه هوندي. نظرياتي طور تي، جيڪڏهن اسان ڪنهن به مثال کي ٻيهر شروع ڪرڻ دوران تالا سيڪيورٽي جي ضمانت ڏيڻ چاهيون ٿا، اسان کي فعال ڪرڻ گهرجي fsync=always ڊگھي مدت جي ڊيٽا اسٽوريج لاء سيٽنگون ۾. اهو مڪمل طور تي ڪارڪردگي کي ختم ڪري ڇڏيندو، سي پي سسٽم جي سطح تائين، جيڪي روايتي طور تي ورهايل تالا کي محفوظ طور تي لاڳو ڪرڻ لاء استعمال ڪيا ويندا آهن.

پر صورتحال بهتر آهي ته اها پهرين نظر ۾ لڳي. اصول ۾، الورورٿم جي حفاظت محفوظ ڪئي وئي آهي ڇاڪاڻ ته جڏهن مثال ناڪام ٿيڻ کان پوء ٻيهر شروع ڪيو ويندو آهي، اهو هاڻي ڪنهن به تالا ۾ حصو نه وٺندو آهي جيڪو هن وقت فعال آهي.

انهي کي يقيني بڻائڻ لاءِ، اسان کي صرف ان ڳالهه کي يقيني بڻائڻ جي ضرورت آهي ته هڪ ناڪامي کان پوءِ مثال موجود نه رهي ٿو وقت جي هڪ عرصي تائين جيڪا اسان استعمال ڪريون ٿا وڌ ۾ وڌ TTL کان ٿورو وڌيڪ. هن طريقي سان اسان انتظار ڪنداسين جيستائين ختم ٿيڻ جي تاريخ ۽ خودڪار طور تي جاري ڪيل سڀني چابيون جيڪي ناڪامي جي وقت تي سرگرم هئا.

دير سان ٻيهر شروع ڪرڻ کي استعمال ڪندي، اهو اصولي طور تي ممڪن آهي سيڪيورٽي حاصل ڪرڻ جيتوڻيڪ ريڊس ۾ ڪنهن به ڊگهي مدت جي تسلسل جي غير موجودگي ۾. نوٽ، بهرحال، اهو نتيجو ٿي سگهي ٿو رسائي جي ڀڃڪڙي لاء جرمانه. مثال طور، جيڪڏهن اڪثريت ناڪام ٿي وڃي ٿي، سسٽم عالمي سطح تي TTL لاءِ دستياب نه ٿي ويندو (۽ هن وقت تائين ڪو به وسيلو بند نه ٿي ڪري سگهجي).

اسان الورورٿم جي دستيابي کي وڌايو: اسان بلاڪنگ کي وڌايو

جيڪڏهن ڪلائنٽ پاران ڪيل ڪم ننڍن قدمن تي مشتمل آهي، اهو ممڪن آهي ته ڊفالٽ تالا جي مدت کي گهٽائڻ ۽ تالا وڌائڻ لاء هڪ ميڪانيزم لاڳو ڪرڻ. اصولي طور تي، جيڪڏهن ڪلائنٽ ڪمپيوٽنگ ۾ مصروف آهي ۽ لاڪ ختم ٿيڻ جي قيمت خطرناڪ حد تائين گهٽ آهي، ته توهان انهن سڀني مثالن لاءِ Lua اسڪرپٽ موڪلي سگهو ٿا جيڪي ڪي جي TTL کي وڌائين ٿا جيڪڏهن ڪيڏي اڃا موجود آهي ۽ ان جي قيمت اڃا تائين هڪ بي ترتيبي قيمت آهي جڏهن تالا حاصل ڪيو ويو.

هڪ ڪلائنٽ کي صرف هڪ تالا کي ٻيهر حاصل ڪرڻ تي غور ڪرڻ گهرجي جيڪڏهن اهو صحيح مدت جي اندر اڪثريت جي مثالن کي بند ڪرڻ ۾ ڪامياب ٿي ويو آهي.

سچ، ٽيڪنيڪل طور تي الگورتھم تبديل نٿو ٿئي، تنهنڪري لاڪ حاصل ڪرڻ لاء بار بار ڪوششن جو وڌ ۾ وڌ تعداد محدود هجڻ گهرجي، ٻي صورت ۾ رسائي جي ملڪيت جي ڀڃڪڙي ڪئي ويندي.

جو ذريعو: www.habr.com