داسې محصول ته راتلل چې له یوې لسیزې څخه ډیر وخت لپاره وده کوي ، دا د حیرانتیا خبره نده چې پدې کې زاړه ټیکنالوژي ومومئ. مګر که څه هم په شپږو میاشتو کې تاسو باید بار 10 ځله لوړ وساتئ، او د راټیټ لګښت به سل ځله لوړ شي؟ په دې حالت کې، تاسو د لوړ لوړ پوړ انجنیر ته اړتیا لرئ. خو د نوکرۍ په نشتوالي کې يې ماته د ستونزې د حل دنده وسپارله. د مقالې په لومړۍ برخه کې زه به تاسو ته ووایم چې څنګه موږ له ریډیس څخه ریډیس کلستر ته لاړو، او په دویمه برخه کې به زه مشوره درکړم چې څنګه د کلستر کارول پیل کړئ او د کارولو په وخت کې څه پاملرنه وکړئ.

د ټکنالوژۍ انتخاب

ایا دا بد دی؟ جلا جلا د 1 ماسټر او N غلامانو په ترتیب کې (Standalone redis)؟ ولې زه دې ته متروکه ټیکنالوژي وایم؟

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

• لومړی، ریډیس د ماسټر ناکامۍ وروسته د ناورین د بیا رغونې میکانیزم ملاتړ نه کوي. د دې ستونزې د حل لپاره، موږ نوي ماسټر ته د VIPs اتوماتیک لیږد سره یو ترتیب کارولی، د یو غلام رول بدلول او پاتې نور بدلول. دې میکانیزم کار وکړ، مګر دا د باور وړ حل نه بلل کیدی شي. لومړی، غلط الارمونه رامینځته شوي، او دویم، دا د ضایع کیدو وړ و، او د عملیاتو وروسته د پسرلي چارج کولو لپاره لارښود عملونو ته اړتیا وه.

• دوهم، یوازې یو ماسټر درلودل د شارډینګ ستونزه رامینځته کوي. موږ باید څو خپلواک کلسترونه "1 ماسټر او N غلامان" جوړ کړو، بیا په لاسي ډول د دې ماشینونو ترمنځ ډیټابیسونه وویشو او هیله مند یو چې سبا به یو ډیټابیس دومره وده ونه کړي چې دا به یو جلا مثال ته لیږدول شي.

اختیارونه څه دي؟

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

د استعمال مشخصات

راځئ چې وګورو چې کومې ستونزې مو په تاریخي ډول د ریډیس سره حل کړې او کوم فعالیت مو کارولی دی:

• د 2GIS په څیر لیرې خدماتو ته د غوښتنې دمخه کیش | ګولنګ
  

  ترلاسه کړئ MGET MSET "DB غوره کړئ"

• د MYSQL مخکې زیرمه | پی ایچ پی
  

  ترلاسه کړئ د MGET MSET سکین "کیلي د پیټرن لخوا" "DB غوره کړئ"

• د غونډو او ډرایور همغږي سره د کار کولو خدمت لپاره اصلي ذخیره | ګولنګ
  

  ترلاسه کړئ MGET MSET "DB غوره کړئ" "جیو کیلي اضافه کړئ" "جیو کیلي ترلاسه کړئ" سکین

لکه څنګه چې تاسو لیدلی شئ، هیڅ لوړ ریاضی نشته. نو بیا مشکل څه دی؟ راځئ چې هر میتود په جلا توګه وګورو.

میتود
شرح
د ریډیس کلستر ځانګړتیاوې
پریکړه

ترلاسه کړئ
کیلي ولیکئ / لوستل

MGET MSET
ډیری کلیدونه ولیکئ / ولولئ
کیلي به په مختلفو نوډونو کې وي. چمتو شوي کتابتونونه کولی شي څو عملیات یوازې په یو نوډ کې ترسره کړي
MGET د N GET عملیاتو پایپ لاین سره بدل کړئ

DB وټاکئ
هغه اساس غوره کړئ چې موږ به ورسره کار وکړو
د ډیری ډیټابیسونو ملاتړ نه کوي
هرڅه په یوه ډیټابیس کې وساتئ. کیلي ته مختګونه اضافه کړئ

SCAN
په ډیټابیس کې د ټولو کلیدونو له لارې لاړ شئ
څرنګه چې موږ یو ډیټابیس لرو، په کلستر کې د ټولو کلیدونو څخه تیریدل خورا ګران دي
په یوه کیلي کې متغیر وساتئ او په دې کیلي کې HSCAN وکړئ. یا په بشپړه توګه رد کړئ

GEO
د جیوکی سره عملیات
جیوکی ټوټه نه ده

د بڼې په واسطه کیلي
د نمونې په واسطه د کیلي لټون کول
څرنګه چې موږ یو ډیټابیس لرو، موږ به په کلستر کې د ټولو کلیدونو لټون وکړو. ډیر ګران
د SCAN په قضیه کې د انویرینټ رد کول یا ساتل

Redis vs Redis-cluster

موږ څه له لاسه ورکوو او څه ترلاسه کوو کله چې کلستر ته لاړ شو؟

• زیانونه: موږ د ډیری ډیټابیس فعالیت له لاسه ورکوو.
  • که موږ غواړو په یوه کلستر کې د منطقي پلوه غیر اړونده ډاټا ذخیره کړو، نو موږ باید د مخکینیو په بڼه کرچونه جوړ کړو.
  • موږ ټول "بیس" عملیات له لاسه ورکوو، لکه سکین، DBSIZE، CLEAR DB، او داسې نور.
  • څو عملیاتونه پلي کول خورا ستونزمن شوي ځکه چې دا ممکن څو نوډونو ته لاسرسی ته اړتیا ولري.
• Pluses:
  • د ماسټر ناکامۍ په بڼه د غلطی زغم.
  • په ریډیس اړخ کې شارډینګ.
  • د نوډونو ترمینځ ډیټا په اټومي ډول او پرته له وخت څخه لیږدوي.
  • پرته له ځنډیدو پرته ظرفیت او بار اضافه او بیا توزیع کړئ.

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

د حرکت لپاره چمتووالی

راځئ چې د حرکت کولو اړتیاو سره پیل وکړو:

• دا باید بې ثباته وي. د 5 دقیقو لپاره د خدماتو بشپړ بندول زموږ سره مناسب ندي.
• دا باید د امکان تر حده خوندي او تدریجي وي. زه غواړم په وضعیت باندې یو څه کنټرول ولرم. موږ نه غواړو هر څه په یوځل ډوب کړو او د رول بیک تڼۍ باندې دعا وکړو.
• د حرکت په وخت کې د معلوماتو لږترلږه ضایع. موږ پوهیږو چې په اټومي ډول حرکت کول به خورا ستونزمن وي، نو موږ په منظم او کلستر شوي ریډیس کې د معلوماتو تر مینځ یو څه غیر همغږي کولو ته اجازه ورکوو.

د کلستر ساتنه

د حرکت څخه دمخه، موږ باید فکر وکړو چې آیا موږ کولی شو د کلستر ملاتړ وکړو:

• چارټونه. موږ Prometheus او Grafana د CPU بار، د حافظې کارول، د پیرودونکو شمیر، د GET شمیره، SET، AUTH عملیاتونو او نور ګراف کولو لپاره کاروو.
• تخصص. تصور وکړئ چې سبا به تاسو د خپل مسؤلیت لاندې یو لوی کلستر ولرئ. که دا مات شي، هیڅوک نشي کولی مګر تاسو یې حل کولی شئ. که هغه سست پیل کړي، هرڅوک به ستاسو په لور وګرځي. که تاسو اړتیا لرئ سرچینې اضافه کړئ یا بار بیا توزیع کړئ ، بیرته تاسو ته راشئ. د دې لپاره چې په 25 کې خړ نه شي، دا مشوره ورکول کیږي چې د دې قضیو لپاره چمتو کړئ او مخکې له مخکې وګورئ چې ټیکنالوژي به د ځینو کړنو لاندې څنګه چلند وکړي. راځئ چې په دې اړه د "تخصص" برخه کې په تفصیل سره خبرې وکړو.
• څارنه او خبرتیاوې. کله چې یو کلستر مات شي، تاسو غواړئ لومړی د هغې په اړه پوه شئ. دلته موږ خپل ځان په یو خبرتیا پورې محدود کړ چې ټول نوډونه د کلستر حالت په اړه ورته معلومات بیرته راولي (هو، دا په بل ډول پیښیږي). او نورې ستونزې د Redis مراجعینو خدماتو څخه خبرتیاو سره ډیر ژر لیدل کیدی شي.

ځای په ځای کول

موږ به څنګه حرکت وکړو:

• لومړی، تاسو اړتیا لرئ چې د کلستر سره کار کولو لپاره کتابتون چمتو کړئ. موږ Go-redis د Go نسخه د اساس په توګه واخیست او د ځان لپاره یې یو څه بدل کړل. موږ د پایپ لاینونو له لارې څو میتودونه پلي کړل، او د غوښتنو د تکرار لپاره مو اصول هم لږ څه سم کړل. د PHP نسخه ډیرې ستونزې درلودې، مګر موږ په پای کې په php-redis کې میشت شو. دوی پدې وروستیو کې د کلستر ملاتړ معرفي کړ او دا زموږ په نظر ښه ښکاري.
• بیا تاسو اړتیا لرئ پخپله کلستر ځای په ځای کړئ. دا په لفظي ډول د ترتیب فایل پراساس په دوه حکمونو کې ترسره کیږي. موږ به لاندې په ډیر تفصیل سره د ترتیب په اړه بحث وکړو.
• د تدریجي حرکت لپاره موږ د وچ حالت څخه کار اخلو. څرنګه چې موږ د ورته انٹرفیس سره د کتابتون دوه نسخې لرو (یو د منظم نسخې لپاره، بل د کلستر لپاره)، دا د ریپر جوړولو لپاره هیڅ لګښت نلري چې د جلا نسخې سره کار وکړي او په موازي ډول د کلستر ټولې غوښتنې نقل کړي، ځوابونه پرتله کړئ او په لاګونو کې توپیرونه ولیکئ (زموږ په قضیه کې په نیو ریلیک کې). په دې توګه، حتی که د کلستر نسخه د رول آوټ په وخت کې مات شي، زموږ تولید به اغیزمن نشي.
• په وچ حالت کې د کلستر له مینځه وړلو سره، موږ کولی شو په آرامۍ سره د غبرګون توپیرونو ګراف ته وګورو. که چیرې د خطا کچه ورو ورو مګر یقینا یو څه کوچني ثابت ته حرکت وکړي ، نو هرڅه سم دي. ولې اوس هم توپیرونه شتون لري؟ ځکه چې په جلا نسخه کې ثبت کول د کلستر په پرتله یو څه دمخه پیښیږي ، او د مایکرولاګ له امله ، ډاټا ممکن توپیر ولري. ټول هغه څه چې پاتې دي د توپیر لاګونو ته د کتلو لپاره دي، او که دا ټول د ریکارډ غیر اټوميیت لخوا تشریح شي، نو موږ کولی شو پرمخ لاړ شو.
• اوس تاسو کولی شئ د وچ حالت په مخالف لوري بدل کړئ. موږ به د کلستر څخه لیکو او لوستلو، او په جلا نسخه کې به یې نقل کړو. د څه لپاره؟ په راتلونکې اونۍ کې زه غواړم د کلستر کار وڅیړم. که دا ناڅاپه معلومه شي چې په لوړ بار کې ستونزې شتون لري، یا موږ یو څه په پام کې نه نیولي، موږ تل د وچ حالت څخه مننه زاړه کوډ او اوسني ډیټا ته بیړني رول بیک لرو.
• ټول هغه څه چې پاتې دي د وچ حالت غیر فعال کول او جلا نسخه له مینځه وړل دي.

تخصص

لومړی، په لنډه توګه د کلستر ډیزاین په اړه.

له هرڅه دمخه ، ریډیس د کلیدي ارزښت پلورنځی دی. خپلمنځي تارونه د کیلي په توګه کارول کیږي. شمیرې، تارونه، او ټول جوړښتونه د ارزښتونو په توګه کارول کیدی شي. وروستي ډیری شتون لري، مګر د عمومي جوړښت د پوهیدو لپاره دا زموږ لپاره مهم ندي.
د کیلي څخه وروسته د خلاصون بله کچه سلاټ (SLOTS) ده. هر کلی د 16 سلاټونو څخه یوه پورې اړه لري. په هر سلاټ کې هر ډول کیلي شتون لري. په دې توګه، ټولې کیلي په 383 بې ځایه سیټونو ویشل شوي.

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

وروسته له دې چې ټولې کیلي د سلاټونو ترمنځ ویشل شوي، او سلاټونه د ماسټر نوډونو په مینځ کې ویشل شوي، هر ماسټر نوډ ته د غلام نوډونو خپل سري شمیر اضافه کیدی شي. د هر داسې ماسټر غلام لینک دننه، نورمال نقل به کار وکړي. د لوستلو غوښتنو اندازه کولو او د ماسټر ناکامۍ په صورت کې د ناکامۍ لپاره غلامانو ته اړتیا ده.

اوس راځئ چې د عملیاتو په اړه خبرې وکړو چې دا به غوره وي چې ترسره شي.

موږ به سیسټم ته د Redis-CLI له لارې لاسرسی ولرو. څرنګه چې ریډیس د ننوتلو یو واحد نقطه نلري، تاسو کولی شئ په هر نوډونو کې لاندې عملیات ترسره کړئ. په هر ځای کې زه په جلا توګه د بار لاندې د عملیاتو ترسره کولو احتمال ته پاملرنه کوم.

• لومړی او خورا مهم شی چې موږ ورته اړتیا لرو د کلستر نوډ عملیات دي. دا د کلستر حالت بیرته راګرځوي، د نوډونو لیست، د دوی رول، د سلاټ ویش، او نور ښیي. نور معلومات د کلستر معلوماتو او کلستر سلاټونو په کارولو سره ترلاسه کیدی شي.
• دا به ښه وي چې د نوډونو اضافه کولو او لرې کولو وړتیا ولرئ. د دې هدف لپاره د کلستر ملاقات او کلستر هیر عملیات شتون لري. مهرباني وکړئ په یاد ولرئ چې کلستر هیر باید په هر نوډ کې پلي شي، دواړه ماسټران او نقلونه. او کلستر ملاقات یوازې په یوه نوډ کې ویل کیږي. دا توپیر کیدای شي د اندیښنې وړ وي، نو دا غوره ده چې مخکې له دې چې تاسو د خپل کلستر سره ژوند وکړئ د دې په اړه زده کړه وکړئ. د نوډ اضافه کول په خوندي ډول په جګړه کې ترسره کیږي او په هیڅ ډول د کلستر عملیات اغیزه نه کوي (کوم چې منطقي وي). که تاسو د کلستر څخه نوډ لرې کوئ، نو تاسو باید ډاډ ترلاسه کړئ چې په دې کې هیڅ سلاټ نه پاتې کیږي (که نه نو تاسو په دې نوډ کې ټولو کیلي ته د لاسرسي له لاسه ورکولو خطر لرئ). همدارنګه، هغه بادار مه حذف کړئ چې غلامان لري، که نه نو د نوي بادار لپاره غیر ضروري رایه به ترسره شي. که نوډونه نور سلاټونه ونلري، نو دا یوه کوچنۍ ستونزه ده، مګر ولې موږ اضافي انتخابونو ته اړتیا لرو که چیرې موږ لومړی غلامان حذف کړو.
• که تاسو په زور سره د ماسټر او غلام پوستونو بدلولو ته اړتیا لرئ، نو د کلستر ناکامي کمانډ به ترسره کړي. کله چې دا په جګړه کې غږ کړئ، تاسو باید پوه شئ چې ماسټر به د عملیاتو په جریان کې شتون ونلري. معمولا سویچ د یوې ثانیې څخه لږ وخت کې واقع کیږي، مګر اټومي نه دی. تاسو تمه کولی شئ چې ماسټر ته ځینې غوښتنې به پدې وخت کې ناکام شي.
• د کلستر څخه د نوډ لرې کولو دمخه، باید په هغې کې هیڅ سلاټ پاتې نشي. دا غوره ده چې د کلستر ریشارډ کمانډ په کارولو سره یې بیا توزیع کړئ. سلاټونه به له یو ماسټر څخه بل ته لیږدول کیږي. ټول عملیات ممکن څو دقیقې وخت ونیسي، دا د لیږد شوي معلوماتو حجم پورې اړه لري، مګر د لیږد بهیر خوندي دی او په هیڅ ډول د کلستر عملیات اغیزه نه کوي. پدې توګه ، ټول معلومات له یو نوډ څخه بل ته مستقیم د بار لاندې لیږدول کیدی شي ، او پرته د دې شتون په اړه اندیښنه. په هرصورت، دلته فرعي ټکي هم شتون لري. لومړی، د معلوماتو لیږد په ترلاسه کونکي او لیږونکي نوډونو کې د یو مشخص بار سره تړاو لري. که د ترلاسه کونکي نوډ دمخه په پروسیسر کې خورا ډیر بار شوی وي ، نو تاسو باید د نوي ډیټا ترلاسه کولو سره دا نه لوډ کړئ. دوهم، هرڅومره ژر چې د رالېږونکي مالک کې یو ځای پاتې نه وي، ټول غلامان به سمدستي هغه مالک ته ځي چې دا سلاټونه لیږدول شوي. او ستونزه دا ده چې دا ټول غلامان غواړي په یوځل کې ډاټا همغږي کړي. او تاسو به خوشحاله یئ که دا د بشپړ ترکیب پرځای جزوي وي. دا په پام کې ونیسئ او د سلاټونو لیږد او د غلامانو غیر فعال کولو/لیږدولو عملیات سره یوځای کړئ. یا امید لرئ چې تاسو د خوندیتوب کافي حاشیه لرئ.
• تاسو باید څه وکړئ که چیرې، د لیږد پر مهال، تاسو ومومئ چې تاسو خپل سلاټونه چیرته له لاسه ورکړي؟ زه امید لرم چې دا ستونزه تاسو اغیزه ونکړي، مګر که دا وي، د کلستر فکس عملیات شتون لري. لږترلږه، هغه به په تصادفي ترتیب کې د نوډونو په اوږدو کې سلاټونه وویشي. زه وړاندیز کوم چې لومړی د کلستر څخه د توزیع شوي سلاټونو سره نوډ لرې کولو سره د دې عملیات چیک کړئ. څرنګه چې په غیر تخصیص شوي سلاټونو کې ډاټا لا دمخه شتون نلري، نو دا ډیر ناوخته دی چې د دې سلاټونو شتون سره د ستونزو په اړه اندیښنه وکړئ. په بدل کې، عملیات به په ویشل شوي سلاټونو اغیزه ونکړي.
• بل ګټور عملیات څارنه ده. دا تاسو ته اجازه درکوي په ریښتیني وخت کې د غوښتنو ټول لیست وګورئ چې نوډ ته ځي. سربیره پردې ، تاسو کولی شئ دا وخورئ او ومومئ چې ایا اړین ترافیک شتون لري.

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

شکل بندي

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

• وخت وتل 0
  هغه وخت چې وروسته غیر فعال اړیکې تړل کیږي (په ثانیو کې). ۰ – مه تړل
  زموږ هر کتابتون د دې توان نه درلود چې اړیکې په سمه توګه وتړي. د دې ترتیب په غیر فعالولو سره، موږ د پیرودونکو په شمیر کې حد ته د رسیدو خطر لرو. له بلې خوا ، که چیرې داسې ستونزه شتون ولري ، نو د ورک شوي اتصالاتو اتوماتیک بندول به دا ماسک کړي ، او موږ ممکن پام ونه کړو. برسېره پردې، تاسو باید دا ترتیب فعال نه کړئ کله چې د دوامداره اړیکو کارولو په وخت کې.
• xy خوندي کړئ او یوازې هو ضمیمه کړئ
  د RDB سنیپ شاټ خوندي کول.
  موږ به لاندې په تفصیل سره د RDB/AOF مسلو په اړه بحث وکړو.
• stop-writes-on-bgsave-error no & slave-serve-stale-data هو
  که فعال شي، که د RDB سنیپ شاټ مات شي، ماسټر به د بدلون غوښتنې منلو مخه ونیسي. که چیرې د مالک سره اړیکه له لاسه ورکړي، نو غلام کولی شي غوښتنو ته ځواب ووايي (هو). یا به د ځواب ویلو مخه ونیسي (نه)
  موږ له هغه وضعیت څخه خوښ نه یو چې ریډیس په کدو بدلیږي.
• repl-ping-slave-period 5
  د دې مودې وروسته ، موږ به اندیښنه پیل کړو چې ماسټر مات شوی او دا د ناکامۍ پروسې ترسره کولو وخت دی.
  تاسو باید په لاسي ډول د غلط مثبتو او د ناکامۍ رامینځته کولو ترمینځ توازن ومومئ. زموږ په تمرین کې دا 5 ثانیې دی.
• repl-backlog-size 1024mb او epl-backlog-ttl 0
  موږ کولی شو د ناکام نقل لپاره دقیقا دومره ډیر معلومات په بفر کې ذخیره کړو. که چیرې بفر پای ته ورسیږي، نو تاسو باید په بشپړه توګه همغږي کړئ.
  تمرین وړاندیز کوي چې دا غوره ده چې لوړ ارزښت وټاکئ. ډیری دلیلونه شتون لري چې ولې یو نقل ممکن ځنډ پیل کړي. که دا وروسته پاتې شي، نو ډیری احتمال چې ستاسو ماسټر لا دمخه د مقابلې لپاره مبارزه کوي، او بشپړ همغږي به وروستی ډډ وي.
• maxclients 10000
  د یو وخت پیرودونکو اعظمي شمیر.
  زموږ په تجربه کې، دا غوره ده چې لوړ ارزښت وټاکئ. ریډیس 10k اتصالونه ښه سمبالوي. بس ډاډ ترلاسه کړئ چې په سیسټم کې کافي ساکټونه شتون لري.
• maxmemory-policy volatile-ttl
  هغه قاعده چې له مخې یې کیلي حذف کیږي کله چې د حافظې موجود حد ته ورسیږي.
  هغه څه چې دلته مهم دي پخپله قاعده نه ده ، مګر پدې پوهیدل چې دا به څنګه پیښ شي. ریډیس د دې وړتیا لپاره ستاینه کیدی شي چې په نورمال ډول کار وکړي کله چې د حافظې حد ته ورسیږي.

RDB او AOF ستونزې

که څه هم ریډیس پخپله ټول معلومات په RAM کې ذخیره کوي ، ډیسک ته د معلوماتو خوندي کولو میکانیزم هم شتون لري. په دقیق ډول، درې میکانیزمونه:

• RDB-snapshot - د ټولو معلوماتو بشپړ سنیپ شاټ. د SAVE XY تشکیلاتو په کارولو سره تنظیم کړئ او "په هر X ثانیه کې د ټولو ډیټا بشپړ سنیپ شاټ خوندي کړئ که لږترلږه Y کیلي بدل شوي وي."
• یوازې د ضمیمه کولو فایل - د عملیاتو لیست په ترتیب سره چې دوی ترسره کیږي. په هر X ثانیه یا هر Y عملیاتو کې فایل ته نوي راتلونکي عملیات اضافه کوي.
• RDB او AOF د پخوانیو دوو ترکیبونو ترکیب دی.

ټول میتودونه خپلې ګټې او زیانونه لري، زه به دوی ټول لیست نه کړم، زه به یوازې هغه ټکو ته پام وکړم چې زما په نظر څرګند ندي.

لومړی، د RDB سنیپ شاټ خوندي کول د FORK زنګ وهلو ته اړتیا لري. که چیرې ډیری ډیټا شتون ولري ، نو دا کولی شي ټول ریډیس د څو ملی ثانیو څخه تر یوې ثانیې پورې ځړ کړي. سربیره پردې ، سیسټم اړتیا لري د داسې سنیپ شاټ لپاره حافظه تخصیص کړي ، کوم چې په منطقي ماشین کې د RAM دوه چنده اکمالاتو ساتلو ته اړتیا رامینځته کوي: که چیرې 8 GB د Redis لپاره تخصیص شوي وي ، نو 16 GB باید په مجازی ماشین کې شتون ولري. دا

دوهم، د جزوی ترکیب سره ستونزې شتون لري. په AOF حالت کې، کله چې غلام بیا وصل شي، د جزوی ترکیب پرځای، بشپړ همغږي ترسره کیدی شي. ولې دا پیښیږي، زه نه پوهیږم. مګر دا د یادولو وړ ده.

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

پایلې

په پایله کې، زه امید لرم چې زه وکولی شوم یو عمومي نظر وړاندې کړم چې څنګه د ریډیس کلستر د هغو کسانو لپاره کار کوي چې دا یې په اړه ندي اوریدلي، او د هغو کسانو لپاره چې دا یې کاروي ځینې غیر ښکاره ټکو ته یې هم پاملرنه کړې. د اوږد مهال لپاره.
ستاسو د وخت لپاره مننه او د تل په څیر، د موضوع په اړه نظرونو ته ښه راغلاست.

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