د Redis په کارولو سره توزیع شوي تالاشي

اې حبره!

نن ورځ موږ ستاسو پام ته د Redis په کارولو سره د توزیع شوي تالاشۍ پلي کولو په اړه د یوې پیچلې مقالې ژباړه راوړو او تاسو ته بلنه درکوو چې د یوې موضوع په توګه د ریډیس امکاناتو په اړه وغږیږو. د ریډ لاک الګوریتم تحلیل د کتاب لیکوال مارتین کلیپمن څخه په پوښتنه کې "د لوړ بار غوښتنلیکونه"، ورکړل شوی دلته.

توزیع شوي تالاشۍ یو خورا ګټور لومړنی دی چې په ډیری چاپیریالونو کې کارول کیږي چیرې چې بیلابیل پروسې باید په دوه اړخیزه توګه په ګډو سرچینو کار وکړي.

دلته یو شمیر کتابتونونه او پوسټونه شتون لري چې د ریډیس په کارولو سره د DLM (توزیع شوي لاک مدیر) پلي کولو څرنګوالی تشریح کوي ، مګر هر کتابتون مختلف چلند غوره کوي او هغه تضمینونه چې دوی یې چمتو کوي خورا ضعیف دي د هغه څه په پرتله چې د یو څه ډیر پیچلي ډیزاین سره ترلاسه کیږي.

پدې مقاله کې به موږ هڅه وکړو چې د مشروط کانونیکي الګوریتم تشریح کړو چې د ریډیس په کارولو سره د توزیع شوي تالاشۍ پلي کولو څرنګوالی ښیې. موږ به د الګوریتم په اړه وغږیږو ریډ لاک، دا د توزیع شوي تالاش مدیر پلي کوي او زموږ په نظر ، دا الګوریتم د معمول واحد مثال په پرتله خوندي دی. موږ هیله لرو چې ټولنه به یې تحلیل کړي، فیډبیک ورکړي، او د نورو پیچلو یا بدیل پروژو لپاره د پیل ټکي په توګه وکاروي.

تطبیق

مخکې لدې چې د الګوریتم توضیحاتو ته لاړ شو ، موږ د چمتو شوي پلي کولو لپاره څو لینکونه چمتو کوو. دوی د حوالې لپاره کارول کیدی شي.

• Redlock-rb (د روبي لپاره تطبیق). هم شته فورک Redlock-rb، کوم چې د توزیع اسانتیا لپاره یو بسته (جیم) اضافه کوي، او نه یوازې د دې لپاره.
• Redlock-py (Python تطبیق).
• Aioredlock (د Asyncio Python لپاره تطبیق).
• Redlock-php (د PHP لپاره تطبیق).
• PHPRedisMutex (د PHP لپاره بل تطبیق)
• cheprasov/php-redis-lock (د قلفونو لپاره د پی ایچ پی کتابتون)
• ریډ سینک (د تګ لپاره تطبیق).
• ریډیسون (د جاوا لپاره تطبیق).
• Redis::DistLock (د پرل لپاره تطبیق).
• Redlock-cpp (د C++ لپاره تطبیق).
• Redlock-cs (د C#/.NET لپاره تطبیق).
• RedLock.net (د C#/.NET لپاره تطبیق). د async او لاک توسیعونو ملاتړ سره.
• سکارټ لاک (د ترتیب وړ ډیټا ذخیره سره د C# .NET لپاره پلي کول)
• Redlock4Net (د C# .NET لپاره تطبیق)
• نوډ-ریډ لاک (د NodeJS لپاره تطبیق). د تالاشۍ غزولو لپاره ملاتړ شامل دی.

د امنیت او شتون تضمین

موږ به زموږ ډیزاین یوازې د دریو ملکیتونو سره ماډل کړو چې موږ فکر کوو د توزیع شوي تالاشۍ په مؤثره توګه کارولو لپاره لږترلږه تضمین چمتو کوو.

1. امنیتي ملکیت: دوه اړخیزه جالوالی. په هر وخت کې، یوازې یو پیرودونکی کولی شي تالا وساتي.
2. د شتون ملکیت A: هیڅ ځنډ نشته. دا تل ممکنه ده چې بالاخره یو لاک ترلاسه کړئ، حتی که چیرې هغه پیرودونکي چې سرچینې یې بندې کړي ناکام شي یا په مختلف ډیسک برخې کې راشي.
3. د موجودیت ملکیت ب: د غلطۍ زغم. تر هغه چې د ریډیس نوډونو ډیری برخه روانه وي ، پیرودونکي د دې وړتیا لري چې لاکونه ترلاسه او خوشې کړي.

ولې د ناکامۍ بیا رغونه پر بنسټ پلي کول پدې قضیه کې کافي ندي
د پوهیدو لپاره چې موږ څه ته وده ورکوو، راځئ چې د ریډیس پراساس د ډیری توزیع شوي تالاشۍ کتابتونونو سره د چارو اوسنی حالت تحلیل کړو.

د ریډیس په کارولو سره د سرچینې بندولو ترټولو اسانه لار په مثال کې د کیلي رامینځته کول دي. په عموم کې ، کیلي د محدود ژوند سره رامینځته کیږي ، دا په ریډیس کې چمتو شوي د ختمیدو ځانګړتیا په کارولو سره ترلاسه کیږي ، نو ژر یا وروسته دا کیلي خوشې کیږي (زموږ په لیست کې ملکیت 2). کله چې پیرودونکي سرچینې خوشې کولو ته اړتیا لري، دا کیلي ړنګوي.

په لومړي نظر کې، دا حل خورا ښه کار کوي، مګر یوه ستونزه شتون لري: زموږ جوړښت د ناکامۍ یو واحد ټکی رامینځته کوي. څه پیښیږي که چیرې کوربه ریډیس مثال ناکام شي؟ راځه بیا یو غلام اضافه کړو! او موږ به یې وکاروو که چیرې وړاندیز کونکی شتون ونلري. له بده مرغه، دا اختیار د منلو وړ نه دی. د دې کولو په کولو سره، موږ به وکولی شو د دوه اړخیز جلا کولو ملکیت په سمه توګه پلي نه کړو چې موږ ورته اړتیا لرو چې امنیت ډاډمن کړو، ځکه چې په ریډیس کې نقل کول غیر متناسب دی.

په ښکاره ډول، په داسې ماډل کې د نسل حالت واقع کیږي:

1. پیرودونکي A په ماسټر کې لاک ترلاسه کوي.
2. ماسټر ناکام کیږي مخکې لدې چې کلیدي ننوتل غلام ته لیږدول کیږي.
3. پیروونکی مشر ته وده ورکول کیږي.
4. پیرودونکی B په ورته سرچینې کې یو لاک ترلاسه کوي چې A لا دمخه لاک کړی. امنیتي سرغړونې!

ځینې ​​​​وختونه دا په بشپړه توګه عادي خبره ده چې په ځانګړو شرایطو کې، لکه د ناکامۍ په څیر، ډیری پیرودونکي کولی شي په ورته وخت کې تالاشي وساتي. په داسې قضیو کې، د نقل پر بنسټ حل کارول کیدی شي. که نه نو، موږ په دې مقاله کې تشریح شوي حل وړاندیز کوو.

د یو واحد مثال سره سم تطبیق

مخکې لدې چې پورته بیان شوي د واحد مثال ترتیب نیمګړتیاو ته د رسیدو هڅه وکړئ ، راځئ چې پوه شو چې څنګه دا ساده قضیه په سمه توګه اداره کړو ، ځکه چې دا حل واقعیا په غوښتنلیکونو کې د اعتبار وړ دی چیرې چې د ریس حالت وخت په وخت د منلو وړ وي ، او همدارنګه د بلاک کولو له امله. واحد مثال د اساس په توګه کار کوي چې دلته تشریح شوي توزیع شوي الګوریتم کې کارول کیږي.

د تالاشۍ ترلاسه کولو لپاره، دا وکړئ:

SET resource_name my_random_value NX PX 30000

دا کمانډ یوازې هغه کیلي نصبوي که چیرې دا دمخه شتون ونلري (NX اختیار) ، د 30000 ملی ثانیو (PX اختیار) اعتبار موده سره. کلید دې ته ټاکل شوی چې "myrandomvalue" دا ارزښت باید په ټولو مشتریانو او د تالاشۍ ټولو غوښتنو کې ځانګړی وي.
اساسا ، یو تصادفي ارزښت په خوندي ډول د لاک خوشې کولو لپاره کارول کیږي ، د سکریپټ سره چې ریډیس ته وايي: یوازې هغه کیلي لرې کړئ که چیرې شتون ولري او پدې کې زیرمه شوي ارزښت دقیقا هغه څه دي چې تمه کیده. دا د لاندې لوا سکریپټ په کارولو سره ترلاسه کیږي:

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 سره تخم کړئ او بیا له هغې څخه یو تصادفي جریان تولید کړئ. یو ساده حل کې د مایکرو ثانیه ریزولوشن او د پیرودونکي ID کې د یونیکس وخت ترکیب شامل دی؛ دا دومره خوندي نه دی، مګر دا شاید په ډیرو شرایطو کې کار پورې اړه ولري.

هغه وخت چې موږ د کیلي د ژوند موده د اندازې په توګه کاروو د "لاک ژوند موده" بلل کیږي. دا ارزښت دواړه د وخت مقدار دی مخکې لدې چې قفل په اوتومات ډول خلاص شي او د هغه وخت مقدار چې یو پیرودونکی باید عملیات بشپړ کړي مخکې لدې چې بل پیرودونکي وکولی شي دا سرچینه لاک کړي ، پرته لدې چې په حقیقت کې د متقابل خارج تضمین څخه سرغړونه وکړي. دا تضمین یوازې د وخت یوې ټاکلې کړکۍ پورې محدود دی، کوم چې د قلف اخیستلو له شیبې څخه پیل کیږي.

نو موږ د تالاشۍ ترلاسه کولو او خوشې کولو لپاره په یوه ښه لاره بحث کړی دی. سیسټم (که موږ د غیر توزیع شوي سیسټم په اړه وغږیږو چې یو واحد او تل شتون لري) خوندي دی. راځئ چې دا مفهوم یو ویشل شوي سیسټم ته وغزوو، چیرې چې موږ داسې تضمین نه لرو.

ریډ لاک الګوریتم

د الګوریتم ویشل شوی نسخه داسې انګیرل کیږي چې موږ د N Redis ماسټران لرو. دا نوډونه له یو بل څخه په بشپړه توګه خپلواک دي، نو موږ د نقل یا کوم بل ضمني همغږۍ سیسټم نه کاروو. موږ لا دمخه پوښلي چې څنګه په یوه بیلګه کې په خوندي ډول د لاک ترلاسه کولو او خوشې کولو څرنګوالی. موږ دا په پام کې نیسو چې الګوریتم، کله چې د یوې بیلګې سره کار کوي، په سمه توګه دا طریقه کاروي. زموږ په مثالونو کې موږ N ته 5 ټاکلو، کوم چې یو مناسب ارزښت دی. پدې توګه ، موږ به اړتیا ولرو چې په مختلف کمپیوټرونو یا مجازی ماشینونو کې د 5 ریډیس ماسټران وکاروو ترڅو ډاډ ترلاسه کړو چې دوی په پراخه کچه له یو بل څخه خپلواکه عمل کوي.

د تالاشۍ ترلاسه کولو لپاره، پیرودونکي لاندې عملیات ترسره کوي:

1. اوسنی وخت په ملی ثانیو کې ترلاسه کوي.
2. په ترتیب سره هڅه کوي چې په ټولو قضیو کې د ورته کلیدي نوم او تصادفي ارزښتونو په کارولو سره په ټولو N مثالونو کې لاک ترلاسه کړي. په 2 مرحله کې، کله چې پیرودونکی د هر مثال په اساس یو قفل تنظیموي، پیرودونکي د دې ترلاسه کولو لپاره ځنډ کاروي چې د هغه وخت په پرتله خورا لنډ وي چې وروسته یې تالا په اتوماتيک ډول خوشې کیږي. د مثال په توګه، که د بلاک کولو موده 10 ثانیې وي، نو ځنډ ممکن د ~ 5-50 ملی ثانیو په حد کې وي. دا هغه وضعیت له مینځه وړي چیرې چې پیرودونکي د اوږدې مودې لپاره بند پاتې کیدی شي د ناکام ریډیس نوډ ته د رسیدو په هڅه کې: که چیرې مثال شتون ونلري ، نو موږ هڅه کوو ژر تر ژره بل مثال سره وصل کړو.
3. د تالاشۍ اخیستلو لپاره، پیرودونکي محاسبه کوي چې څومره وخت تیر شوی؛ د دې کولو لپاره، دا د حقیقي وخت ارزښت څخه د مهال ویش څخه کموي چې په 1 مرحله کې ترلاسه شوي. که چیرې او یوازې هغه وخت چې پیرودونکي وکولی شي په ډیرو مواردو کې تالاشي ترلاسه کړي (لږترلږه 3)، او ټول وخت یې واخیست. قفل ترلاسه کول، د قفل د مودې څخه کم، قفل ترلاسه شوی ګڼل کیږي.
4. که یو قفل ترلاسه شوی وي، د تالاشۍ موده د اصلي تالاشۍ مودې په توګه اخیستل کیږي چې په 3 ګام کې حساب شوي تیر شوي وخت څخه منفي وي.
5. که چیرې پیرودونکی د کوم دلیل لپاره د تالاشۍ په ترلاسه کولو کې پاتې راشي (یا دا د N/2+1 مثالونو لاک کولو توان نه درلود ، یا د لاک موده منفي وه) ، نو دا به هڅه وکړي چې ټول مثالونه خلاص کړي (حتی هغه چې فکر یې کاوه بلاک نشي کولی. ).

ایا الګوریتم غیر متناسب دی؟

دا الګوریتم د دې انګیرنې پر بنسټ والړ دی چې که څه هم هیڅ همغږي شوي ساعت شتون نلري چې ټولې پروسې به کار وکړي، په هره پروسه کې محلي وخت لاهم په ورته سرعت کې تیریږي، او تېروتنه د هغه ټول وخت په پرتله کوچنۍ ده چې وروسته یې تالاشي کوي. په اتوماتيک ډول خپور شو. دا انګیرنه د عادي کمپیوټرونو لپاره عادي حالت ته ورته ده: هر کمپیوټر یو محلي ساعت لري، او موږ معمولا په دې حقیقت حساب کولی شو چې د مختلف کمپیوټرونو ترمنځ د وخت توپیر کوچنی دی.

پدې مرحله کې، موږ باید په ډیر احتیاط سره خپل د متقابل جالوالی قاعده جوړه کړو: دوه اړخیزه جالوالی یوازې هغه وخت تضمین کیږي چې پیرودونکی د تالاشۍ په وخت کې د قفل د اعتبار په وخت کې وځي (دا ارزښت په 3 مرحله کې ترلاسه شوی)، منفي یو څه نور وخت (ټول یو څو د پروسو ترمنځ د وخت توپیر لپاره د جبران کولو لپاره ملیسیکنډونه).

لاندې په زړه پورې مقاله د داسې سیسټمونو په اړه نور څه وايي چې د وخت وقفې همغږۍ ته اړتیا لري: اجارې: د توزیع شوي فایل کیچ ثبات لپاره د غلطۍ زغمونکی میکانیزم.

د ناکامۍ لپاره بیا هڅه وکړئ

کله چې یو پیرودونکی د تالاشۍ په ترلاسه کولو کې پاتې راشي، دا باید د ناڅاپي ځنډ وروسته بیا هڅه وکړي؛ دا د څو مشتریانو د غیر همغږي کولو لپاره ترسره کیږي چې هڅه کوي په ورته وخت کې په ورته سرچینې کې لاک ترلاسه کړي (کوم چې کولی شي د "سپلایټ دماغ" حالت رامینځته کړي چې پکې هیڅ ګټونکي شتون نلري). برسیره پردې، هرڅومره ګړندی چې یو پیرودونکی هڅه کوي په ډیری ریډیس مثالونو کې تالا ترلاسه کړي ، د کړکۍ تنګیږي چیرې چې د سپیټ دماغ حالت رامینځته کیدی شي (او د بیاکتنې اړتیا لږ وي). له همدې امله ، په مثالي توګه ، پیرودونکي باید هڅه وکړي چې د ملټي پلیکسینګ په کارولو سره N مثالونو ته د SET کمانډونه واستوي.

دلته دا د ټینګار ارزښت لري چې د پیرودونکو لپاره دا څومره مهم دی چې د ډیری قفلونو په ترلاسه کولو کې پاتې راغلي ترڅو د (جزوي) ترلاسه شوي تالاشۍ خوشې کولو کې پاتې راشي ، نو دوی اړتیا نلري چې د کیلي پای ته رسیدو ته انتظار وباسي مخکې لدې چې د سرچینې تالاش بیرته ترلاسه شي. (که څه هم که د شبکې ټوټه ټوټه شي، او پیرودونکي د ریډیس مثالونو سره اړیکه له لاسه ورکړي، نو تاسو باید د شتون جریمه ورکړئ پداسې حال کې چې د کیلي پای ته رسیدو انتظار کوئ).

قلف خلاص کړئ

د لاک خوشې کول یو ساده عمل دی چې په ساده ډول د ټولو مثالونو خلاصولو ته اړتیا لري ، پرته لدې چې پیرودونکي داسې بریښي چې یو ځانګړي مثال په بریالیتوب سره لاک کړی وي.

امنیتي نظرونه

ایا الګوریتم خوندي دی؟ راځئ چې تصور وکړو چې په مختلفو سناریوګانو کې څه پیښیږي.

د پیل کولو لپاره، راځئ چې فرض کړو چې پیرودونکی د دې توان درلود چې په ډیری مواردو کې لاک ترلاسه کړي. هره بیلګه به د ټولو لپاره د ورته ژوند سره کلیدي ولري. په هرصورت، د دې کیلي هر یو په یو بل وخت کې نصب شوي، نو دوی به په مختلفو وختونو کې پای ته ورسیږي. مګر، که لومړی کیلي په داسې وخت کې نصب شوې وي چې د 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 د اوږدې مودې ډیټا ذخیره کولو لپاره تنظیماتو کې. دا به په بشپړه توګه فعالیت وژني، د CP سیسټمونو کچې ته چې په دودیز ډول د توزیع شوي لاکونو پلي کولو لپاره کارول کیږي.

مګر وضعیت تر هغه ښه دی چې په لومړي نظر کې ښکاري. په اصولو کې، د الګوریتم امنیت ساتل کیږي ځکه چې کله چې مثال د ناکامۍ وروسته بیا پیل شي، دا نور په کوم لاک کې برخه نه اخلي چې اوس مهال فعال وي.

د دې ډاډ ترلاسه کولو لپاره، موږ یوازې اړتیا لرو چې ډاډ ترلاسه کړو چې د ناکامۍ وروسته مثال د یوې مودې لپاره شتون نلري چې د اعظمي TTL څخه لږ څه چې موږ یې کاروو. پدې توګه به موږ د پای نیټې پورې انتظار وکړو او د ټولو کلیدونو اتوماتیک خوشې کیدو پورې چې د ناکامۍ په وخت کې فعال وو.

د ځنډول شوي بیا پیل کولو په کارولو سره، دا په اصولو کې ممکنه ده چې امنیت ترلاسه کړئ حتی په ریډیس کې د اوږدې مودې دوام په نشتوالي کې. په هرصورت، یادونه وکړئ چې دا ممکن د لاسرسي څخه سرغړونې لپاره جریمه وي. د مثال په توګه، که چیرې ډیری مثالونه ناکام شي، سیسټم به په نړیواله کچه د TTL لپاره شتون ونلري (او پدې وخت کې هیڅ سرچینه بنده نشي).

موږ د الګوریتم شتون ته وده ورکوو: موږ بلاک کول پراخوو

که چیرې د پیرودونکو لخوا ترسره شوي کار کوچني ګامونه ولري ، نو دا ممکنه ده چې د ډیفالټ تالاشۍ موده کمه کړئ او د تالاشۍ غزولو لپاره میکانیزم پلي کړئ. په اصولو کې، که چیرې پیرودونکی په کمپیوټر کې بوخت وي او د تالاشۍ پای ته رسیدو ارزښت په خطرناک ډول ټیټ وي، تاسو کولی شئ د Lua سکریپټ په ټولو مواردو کې واستوئ چې د کیلي TTL پراخوي که چیرې کیلي لاهم شتون ولري او ارزښت یې لاهم یو تصادفي ارزښت دی کله چې ترلاسه کیږي. تالا ترلاسه شو.

یو پیرودونکی باید یوازې د بیا ترلاسه کولو لپاره یو قفل په پام کې ونیسي که چیرې هغه د اعتبار موده کې د ډیری مثالونو بندولو اداره کړې وي.

ریښتیا، په تخنیکي توګه الګوریتم نه بدلیږي، نو د لاکونو ترلاسه کولو لپاره د تکرار هڅو اعظمي شمیر باید محدود وي، که نه نو د لاسرسي ملکیتونه به سرغړونه وي.

سرچینه: www.habr.com