දශකයකට වැඩි කාලයක් තිස්සේ සංවර්ධනය වෙමින් පවතින නිෂ්පාදනයක් වෙත පැමිණීම, එහි යල් පැන ගිය තාක්ෂණයන් සොයා ගැනීම පුදුමයක් නොවේ. නමුත් මාස හයකින් ඔබට බර 10 ගුණයකින් වැඩි කළ යුතු අතර, වැටීමේ පිරිවැය සිය ගුණයකින් වැඩි වුවහොත් කුමක් කළ යුතුද? මෙම අවස්ථාවේදී, ඔබට සිසිල් Highload Engineer අවශ්ය වේ. නමුත් සේවිකාවක් නැති නිසා ප්‍රශ්නය විසඳීමට ඔවුන් මට භාර දුන්නා. ලිපියේ පළමු කොටසේදී අපි Redis සිට Redis-cluster වෙත ගිය ආකාරය මම ඔබට කියමි, දෙවන කොටසේදී මම පොකුර භාවිතා කිරීම ආරම්භ කරන්නේ කෙසේද සහ එය භාවිතා කිරීමේදී අවධානය යොමු කළ යුතු දේ පිළිබඳව උපදෙස් දෙන්නෙමි.

තාක්ෂණය තෝරා ගැනීම

එය එතරම් නරකද? වෙනම Redis (standalone redis) ස්වාමියා සහ N වහලුන් 1 දෙනෙකුගේ වින්‍යාසයකද? මම එය යල්පැන ගිය තාක්ෂණය ලෙස හඳුන්වන්නේ ඇයි?

නෑ රෙඩිස් එහෙම නරක නෑ... කොහොම උනත් නොසලකා හරින්න බැරි අඩුපාඩු ටිකක් තියෙනවා.

• පළමුව, රෙඩිස් ප්‍රධාන අසාර්ථක වීමෙන් පසු ආපදා ප්‍රතිසාධන යාන්ත්‍රණයට සහාය නොදක්වයි. මෙම ගැටළුව විසඳීම සඳහා, අපි නව ස්වාමියෙකුට VIP ස්වයංක්‍රීයව මාරු කිරීම සමඟ වින්‍යාසයක් භාවිතා කළෙමු, එක් වහලෙකුගේ භූමිකාව වෙනස් කර ඉතිරිය මාරු කළෙමු. මෙම යාන්ත්රණය ක්රියාත්මක වූ නමුත් එය විශ්වසනීය විසඳුමක් ලෙස හැඳින්විය නොහැකිය. පළමුව, ව්‍යාජ අනතුරු ඇඟවීම් සිදු වූ අතර, දෙවනුව, එය ඉවත දැමිය හැකි වූ අතර, මෙහෙයුමෙන් පසු වසන්තය ආරෝපණය කිරීම සඳහා අතින් ක්‍රියා කිරීම අවශ්‍ය විය.

• දෙවනුව, එක් ස්වාමියෙකු පමණක් සිටීම කැඩී යාමේ ගැටලුවට හේතු විය. අපට “1 ස්වාමියා සහ N වහලුන්” ස්වාධීන පොකුරු කිහිපයක් නිර්මාණය කිරීමට සිදු විය, ඉන්පසු මෙම යන්ත්‍ර අතර දත්ත සමුදායන් අතින් බෙදා හරින අතර හෙට එක් දත්ත සමුදායක් එතරම් ඉදිමෙන්නේ නැති අතර එය වෙනම අවස්ථාවකට ගෙන යා යුතුය.

විකල්ප මොනවාද?

• වඩාත්ම මිල අධික හා පොහොසත්ම විසඳුම Redis-Enterprise වේ. මෙය සම්පූර්ණ තාක්ෂණික සහාය ඇතිව පෙට්ටි විසඳුමකි. තාක්ෂණික දෘෂ්ටි කෝණයකින් එය පරමාදර්ශී ලෙස පෙනුනද, දෘෂ්ටිවාදාත්මක හේතූන් මත එය අපට නොගැලපේ.
• රෙඩිස්-පොකුරු. කොටුවෙන් පිටත මාස්ටර් ෆේල්වර් සහ ෂර්ඩිං සඳහා ආධාරකයක් ඇත. අතුරු මුහුණත සාමාන්‍ය අනුවාදයට වඩා වෙනස් නොවේ. එය බලාපොරොත්තු සහගත බව පෙනේ, අපි පසුව අන්තරායන් ගැන කතා කරමු.
• Tarantool, Memcache, Aerospike සහ වෙනත් අය. මෙම සියලු මෙවලම් බොහෝ දුරට එකම දේ කරයි. නමුත් සෑම කෙනෙකුටම තමන්ගේම අඩුපාඩු තිබේ. අපි අපේ බිත්තර සියල්ලම එක කූඩයකට නොදැමීමට තීරණය කළෙමු. අපි වෙනත් කාර්යයන් සඳහා Memcache සහ Tarantool භාවිතා කරන අතර, ඉදිරිය දෙස බලන විට, අපගේ භාවිතයේදී ඔවුන් සමඟ තවත් ගැටළු ඇති බව මම කියමි.

භාවිතයේ විශේෂතා

අපි රෙඩිස් සමඟ ඓතිහාසිකව විසඳා ඇති ගැටළු මොනවාද සහ අප භාවිතා කළ ක්‍රියාකාරීත්වය දෙස බලමු:

• 2GIS වැනි දුරස්ථ සේවා සඳහා ඉල්ලීම් වලට පෙර හැඹිලිය | ගොලං
  

  සකසන්න MGET MSET "DB තෝරන්න"

• MYSQL ට පෙර හැඹිලිය | PHP
  

  සකසන්න MGET MSET ස්කෑන් "යතුරෙන් යතුර" "තෝරන්න DB"

• සැසි සහ රියදුරු ඛණ්ඩාංක සමඟ වැඩ කිරීමේ සේවාව සඳහා ප්රධාන ගබඩාව | ගොලං
  

  සකසන්න MGET MSET "DB තෝරන්න" "භූගෝලීය යතුර එක් කරන්න" "භූමිය යතුර ලබා ගන්න" ස්කෑන් කරන්න

ඔබට පෙනෙන පරිදි, උසස් ගණිතය නැත. එතකොට මොකක්ද තියෙන අමාරුව? එක් එක් ක්‍රමය වෙන වෙනම බලමු.

ක්රමය
විස්තර
Redis-cluster හි විශේෂාංග
තීරණය

SET ලබා ගන්න
ලියන්න/කියවන්න යතුර

MGET MSET
බහු යතුරු ලියන්න/කියවන්න
යතුරු විවිධ නෝඩ් මත පවතිනු ඇත. සූදානම් කළ පුස්තකාලවලට බහු මෙහෙයුම් සිදු කළ හැක්කේ එක් නෝඩයක් තුළ පමණි
N GET මෙහෙයුම් නල මාර්ගයක් සමඟ MGET ප්‍රතිස්ථාපනය කරන්න

DB තෝරන්න
අපි වැඩ කරන පදනම තෝරන්න
බහු දත්ත සමුදායන් සඳහා සහය නොදක්වයි
සෑම දෙයක්ම එකම දත්ත ගබඩාවකට දමන්න. යතුරු වලට උපසර්ග එක් කරන්න

ස්කෑන්
දත්ත සමුදායේ ඇති සියලුම යතුරු හරහා යන්න
අපට එක් දත්ත ගබඩාවක් ඇති බැවින්, පොකුරේ ඇති සියලුම යතුරු හරහා යාම මිල අධිකය
එක් යතුරක් තුළ වෙනස් නොවන එකක් පවත්වා ගෙන මෙම යතුර මත HSCAN කරන්න. නැතහොත් සම්පූර්ණයෙන්ම ප්රතික්ෂේප කරන්න

ජීඑඕඕ
භූගෝලයක් සමඟ මෙහෙයුම්
භූගෝලය කැඩී නැත

රටාව අනුව යතුර
රටාව අනුව යතුරක් සොයමින්
අපට එක් දත්ත සමුදායක් ඇති බැවින්, අපි පොකුරේ ඇති සියලුම යතුරු හරහා සොයන්නෙමු. මිල අධික
SCAN වලදී මෙන් නොවෙනස්ව ප්‍රතික්ෂේප කිරීම හෝ නඩත්තු කිරීම

Redis vs Redis-cluster

පොකුරකට මාරුවීමේදී අපට අහිමි වන්නේ කුමක්ද සහ අපට ලැබෙන්නේ කුමක්ද?

• අවාසි: දත්ත සමුදා කිහිපයක ක්‍රියාකාරීත්වය අපට අහිමි වේ.
  • අපට තාර්කිකව සම්බන්ධ නොවන දත්ත එක් පොකුරක් තුළ ගබඩා කිරීමට අවශ්‍ය නම්, අපට උපසර්ග ආකාරයෙන් අත්වාරු සෑදිය යුතුය.
  • SCAN, DBSIZE, CLEAR DB යනාදී සියලුම "පදනම" මෙහෙයුම් අපට අහිමි වේ.
  • නෝඩ් කිහිපයකට ප්‍රවේශය අවශ්‍ය විය හැකි බැවින් බහු-මෙහෙයුම් ක්‍රියාත්මක කිරීම වඩාත් අපහසු වී ඇත.
• නඩු:
  • මාස්ටර් ෆේල්වර් ස්වරූපයෙන් වැරදි ඉවසීම.
  • රෙඩිස් පැත්තේ ෂර්ඩින්.
  • නෝඩ් අතර දත්ත පරමාණුකව සහ අක්‍රිය කාලයකින් තොරව මාරු කරන්න.
  • අක්‍රිය කාලයකින් තොරව ධාරිතාව සහ බර එකතු කිරීම සහ නැවත බෙදා හැරීම.

ඔබට ඉහළ මට්ටමේ වැරදි ඉවසීමක් ලබා දීමට අවශ්‍ය නැතිනම්, පොකුරකට යාම එය වටින්නේ නැති බව මම නිගමනය කරමි, මන්ද එය සුළු නොවන කාර්යයක් විය හැකි බැවිනි. නමුත් ඔබ මුලින් වෙනම අනුවාදයක් සහ පොකුරු අනුවාදයක් තෝරා ගන්නේ නම්, ඔබ පොකුරක් තෝරා ගත යුතුය, මන්ද එය වඩාත් නරක නොවන අතර ඊට අමතරව, ඔබට සමහර හිසරදයෙන් මිදෙනු ඇත.

චලනය කිරීමට සූදානම් වීම

චලනය සඳහා අවශ්‍යතා සමඟ ආරම්භ කරමු:

• එය බාධාවකින් තොරව විය යුතුය. මිනිත්තු 5 ක සේවාව සම්පූර්ණයෙන් නතර කිරීම අපට නොගැලපේ.
• එය හැකි තරම් ආරක්ෂිත සහ ක්රමයෙන් විය යුතුය. මට තත්වය පාලනය කිරීමට අවශ්‍යයි. අපට එකවර සියල්ල ඉවත දමා ආපසු හැරීමේ බොත්තම මත යාච්ඤා කිරීමට අවශ්‍ය නැත.
• චලනය වන විට අවම දත්ත අහිමි වීම. පරමාණුකව චලනය කිරීම ඉතා අපහසු වනු ඇති බව අපි තේරුම් ගනිමු, එබැවින් අපි සාමාන්‍ය සහ පොකුරු Redis හි දත්ත අතර යම් සමමුහුර්තකරණයකට ඉඩ දෙමු.

පොකුරු නඩත්තුව

චලනය වීමට පෙර, අපට පොකුරට සහාය දිය හැකිද යන්න ගැන සිතා බැලිය යුතුය:

• ප්‍රස්ථාර. CPU භාරය, මතක භාවිතය, සේවාලාභීන් සංඛ්‍යාව, GET, SET, AUTH මෙහෙයුම් ආදිය ප්‍රස්ථාර කිරීමට අපි Prometheus සහ Grafana භාවිතා කරමු.
• විශේෂඥතාව. හෙට ඔබේ වගකීම යටතේ ඔබට විශාල පොකුරක් ලැබෙනු ඇතැයි සිතන්න. එය කැඩී ගියහොත් ඔබට හැර වෙන කිසිවෙකුට එය නිවැරදි කළ නොහැක. ඔහු වේගය අඩු කිරීමට පටන් ගන්නේ නම්, සෑම කෙනෙකුම ඔබ දෙසට දුවනු ඇත. ඔබට සම්පත් එකතු කිරීමට හෝ භාරය නැවත බෙදා හැරීමට අවශ්‍ය නම්, ඔබ වෙත ආපසු එන්න. 25 දී අළු පැහැයක් නොගැනීම සඳහා, මෙම අවස්ථා සඳහා සැපයීම සහ යම් යම් ක්රියාවන් යටතේ තාක්ෂණය හැසිරෙන්නේ කෙසේදැයි කල්තියා පරීක්ෂා කිරීම යෝග්ය වේ. අපි මේ ගැන වඩාත් විස්තරාත්මකව "විශේෂඥ" කොටසේ කතා කරමු.
• නිරීක්ෂණ සහ අනතුරු ඇඟවීම්. පොකුරක් කැඩී ගිය විට, ඔබ ඒ ගැන මුලින්ම දැන ගැනීමට අවශ්යයි. මෙහිදී අපි සියලු නෝඩ් පොකුරු තත්ත්වය පිළිබඳ එකම තොරතුරු ලබා දෙන බවට දැනුම් දීමකට සීමා විය (ඔව්, එය වෙනස් ආකාරයකින් සිදු වේ). රෙඩිස් සේවාදායක සේවාවන්ගෙන් ලැබෙන ඇඟවීම් මගින් අනෙකුත් ගැටළු ඉක්මනින් දැකගත හැක.

චලනය

අපි ගමන් කරන්නේ කෙසේද:

• පළමුවෙන්ම, ඔබ පොකුර සමඟ වැඩ කිරීමට පුස්තකාලයක් සකස් කළ යුතුය. අපි Go අනුවාදය සඳහා go-redis පදනම ලෙස ගෙන එය අපට ගැලපෙන පරිදි ටිකක් වෙනස් කළෙමු. අපි නල මාර්ග හරහා බහු ක්‍රම ක්‍රියාත්මක කළ අතර, නැවත නැවත ඉල්ලීම් සඳහා නීති රීති තරමක් නිවැරදි කළෙමු. PHP අනුවාදයේ වැඩි ගැටළු ඇති නමුත් අවසානයේ අපි php-redis මත පදිංචි විය. ඔවුන් මෑතකදී පොකුරු සහාය හඳුන්වා දුන් අතර එය අපගේ මතය අනුව හොඳ පෙනුමක් ඇත.
• ඊළඟට ඔබ පොකුරේම යෙදවිය යුතුය. මෙය වින්‍යාස ගොනුව මත පදනම් වූ විධාන දෙකකින් වචනාර්ථයෙන් සිදු කෙරේ. අපි පහත සැකසුම වඩාත් විස්තරාත්මකව සාකච්ඡා කරමු.
• ක්රමානුකූල චලනය සඳහා අපි වියළි මාදිලිය භාවිතා කරමු. අප සතුව එකම අතුරු මුහුණතක් සහිත පුස්තකාලයේ අනුවාද දෙකක් ඇති බැවින් (එකක් සාමාන්‍ය අනුවාදය සඳහා, අනෙක පොකුරු සඳහා), වෙනම අනුවාදයක් සමඟ ක්‍රියා කරන සහ සමාන්තරව සියලුම ඉල්ලීම් පොකුරට අනුපිටපත් කරන දවටනයක් නිර්මාණය කිරීමට කිසිවක් වැය නොවේ. ප්‍රතිචාර සංසන්දනය කර ලඝු සටහනේ විෂමතා ලියන්න (අපගේ නඩුවේ NewRelic). මේ අනුව, පොකුරු අනුවාදය පෙරළීමේදී කැඩී ගියද, අපගේ නිෂ්පාදනයට බලපෑමක් ඇති නොවේ.
• වියළි ආකාරයෙන් පොකුර පෙරළීමෙන් පසු, අපට ප්‍රතිචාර විෂමතා පිළිබඳ ප්‍රස්ථාරය සන්සුන්ව බැලිය හැකිය. දෝෂ අනුපාතය සෙමින් නමුත් නිසැකවම යම් කුඩා නියතයක් කරා ගමන් කරයි නම්, සියල්ල හොඳින් වේ. තවමත් නොගැලපීම් පවතින්නේ ඇයි? වෙනම අනුවාදයක පටිගත කිරීම පොකුරට වඩා මඳක් කලින් සිදුවන නිසා සහ මයික්‍රොලැග් නිසා දත්ත අපසරනය විය හැකිය. ඉතිරිව ඇත්තේ විෂමතා ලඝු-සටහන් දෙස බැලීම පමණක් වන අතර, ඒවා සියල්ලම වාර්තාවේ පරමාණුක නොවන බව මගින් පැහැදිලි කළහොත්, අපට ඉදිරියට යා හැකිය.
• දැන් ඔබට වියළි මාදිලිය ප්රතිවිරුද්ධ දිශාවට මාරු කළ හැකිය. අපි පොකුරෙන් ලියා කියවන්නෙමු, එය වෙනම අනුවාදයකට අනුපිටපත් කරන්නෙමු. කුමක් සඳහා ද? ඉදිරි සතිය තුළ මම පොකුරේ වැඩ නිරීක්ෂණය කිරීමට කැමැත්තෙමි. උච්ච බර පැටවීමේ ගැටළු ඇති බව හදිසියේම පෙනී ගියහොත් හෝ අපි යමක් සැලකිල්ලට නොගත්තේ නම්, අපට සෑම විටම පැරණි කේතයට හදිසි ආපසු හැරීමක් සහ වියළි මාදිලියට ස්තූතිවන්ත වන වත්මන් දත්ත තිබේ.
• ඉතිරිව ඇත්තේ වියළි මාදිලිය අක්රිය කිරීම සහ වෙනම අනුවාදය විසුරුවා හැරීමයි.

ප්‍රවීණයන්

පළමුව, පොකුරු නිර්මාණය ගැන කෙටියෙන්.

පළමුවෙන්ම, Redis යනු ප්රධාන වටිනාකම් ගබඩාවකි. අත්තනෝමතික නූල් යතුරු ලෙස භාවිතා කරයි. ඉලක්කම්, නූල් සහ සම්පූර්ණ ව්‍යුහයන් අගයන් ලෙස භාවිතා කළ හැක. පසුකාලීන බොහෝ දේ ඇත, නමුත් සාමාන්ය ව්යුහය අවබෝධ කර ගැනීම සඳහා මෙය අපට වැදගත් නොවේ.
යතුරු වලට පසු වියුක්ත කිරීමේ මීළඟ මට්ටම වන්නේ slots (SLOTS) වේ. සෑම යතුරක්ම තව් 16 න් එකකට අයත් වේ. එක් එක් ස්ලොට් එක තුළ ඕනෑම යතුරු ගණනක් තිබිය හැක. මේ අනුව, සියලුම යතුරු විසංයෝජන කට්ටල 383 කට බෙදා ඇත.

ඊළඟට, පොකුරේ N master nodes තිබිය යුතුය. සෑම නෝඩයක්ම පොකුර තුළ ඇති අනෙකුත් නෝඩ් ගැන සියල්ල දන්නා වෙනම Redis අවස්ථාවක් ලෙස සැලකිය හැකිය. සෑම ප්‍රධාන නෝඩයකම තව් ගණනාවක් අඩංගු වේ. සෑම ස්ලොට් එකක්ම අයිති වන්නේ එක් ප්‍රධාන නෝඩයකට පමණි. සියලුම තව් නෝඩ් අතර බෙදා හැරිය යුතුය. සමහර තව් වෙන් කර නොමැති නම්, ඒවායේ ගබඩා කර ඇති යතුරු ප්‍රවේශ විය නොහැක. එක් එක් ප්රධාන නෝඩය වෙනම තාර්කික හෝ භෞතික යන්ත්රයක් මත ධාවනය කිරීම අර්ථවත් කරයි. සෑම නෝඩයක්ම ක්‍රියාත්මක වන්නේ එක් හරයක් මත පමණක් බව මතක තබා ගැනීම වටී, ඔබට එකම තාර්කික යන්ත්‍රයක බහු රෙඩිස් අවස්ථා ධාවනය කිරීමට අවශ්‍ය නම්, ඒවා විවිධ මධ්‍යයන් මත ධාවනය වන බවට වග බලා ගන්න (අපි මෙය උත්සාහ කර නැත, නමුත් න්‍යායාත්මකව එය ක්‍රියාත්මක විය යුතුය) . අත්‍යවශ්‍යයෙන්ම, ප්‍රධාන නෝඩ් නිතිපතා බෙදා හැරීම සපයන අතර, තවත් ප්‍රධාන නෝඩ් ඉල්ලීම් පරිමාණයට ලිවීමට සහ කියවීමට ඉඩ දෙයි.

සියලුම යතුරු තව් අතර බෙදා හැර, ප්‍රධාන නෝඩ් අතර තව් විසිරී ගිය පසු, එක් එක් ප්‍රධාන නෝඩයට අත්තනෝමතික වහල් නෝඩ් සංඛ්‍යාවක් එක් කළ හැකිය. එවැනි එක් එක් ස්වාමි වහල් සබැඳිය තුළ, සාමාන්‍ය අනුකරණය ක්‍රියා කරයි. කියවීමේ ඉල්ලීම් පරිමාණය කිරීමට සහ ස්වාමියා අසමත් වූ විට අසමත් වීම සඳහා වහලුන් අවශ්‍ය වේ.

දැන් අපි කතා කරමු එය කළ හැකි නම් වඩා හොඳ මෙහෙයුම් ගැන.

අපි Redis-CLI හරහා පද්ධතියට පිවිසෙන්නෙමු. Redis හට තනි පිවිසුම් ලක්ෂයක් නොමැති බැවින්, ඔබට ඕනෑම නෝඩ් එකක පහත මෙහෙයුම් සිදු කළ හැක. සෑම අවස්ථාවකදීම, බර යටතේ මෙහෙයුම සිදු කිරීමේ හැකියාව පිළිබඳව මම වෙන වෙනම අවධානය යොමු කරමි.

• අපට අවශ්‍ය පළමු හා වැදගත්ම දෙය වන්නේ පොකුරු නෝඩ් ක්‍රියාකාරිත්වයයි. එය පොකුරේ තත්වය ආපසු ලබා දෙයි, නෝඩ් ලැයිස්තුවක්, ඒවායේ භූමිකාවන්, තව් බෙදා හැරීම යනාදිය පෙන්වයි. පොකුරු තොරතුරු සහ පොකුරු තව් භාවිතයෙන් වැඩි විස්තර ලබා ගත හැක.
• නෝඩ් එකතු කිරීමට සහ ඉවත් කිරීමට හැකි නම් හොඳයි. මේ සඳහා පොකුරු හමුවීම සහ පොකුරු අමතක කිරීමේ මෙහෙයුම් ඇත. පොකුරු අමතක සෑම නෝඩයකටම, ප්‍රධාන සහ අනුරූ යන දෙකටම යෙදිය යුතු බව කරුණාවෙන් සලකන්න. තවද පොකුරු හමුවීම එක් නෝඩයකට පමණක් ඇමතීමට අවශ්‍ය වේ. මෙම වෙනස නොසන්සුන් විය හැක, එබැවින් ඔබ ඔබේ පොකුර සමඟ සජීවී වීමට පෙර ඒ ගැන ඉගෙන ගැනීම වඩාත් සුදුසුය. නෝඩයක් එකතු කිරීම සටනේදී ආරක්ෂිතව සිදු කරනු ලබන අතර, පොකුරේ ක්රියාකාරිත්වයට කිසිදු ආකාරයකින් බලපාන්නේ නැත (එය තාර්කික වේ). ඔබ පොකුරෙන් නෝඩයක් ඉවත් කිරීමට යන්නේ නම්, එහි තව් කිසිවක් ඉතිරි නොවන බවට ඔබ සහතික විය යුතුය (එසේ නොමැති නම් ඔබට මෙම නෝඩයේ ඇති සියලුම යතුරු වෙත ප්‍රවේශය අහිමි වීමේ අවදානමක් ඇත). එසේම, වහලුන් සිටින ස්වාමියා මකා දමන්න එපා, එසේ නොමැතිනම් නව ස්වාමියා සඳහා අනවශ්ය ඡන්දයක් සිදු කරනු ඇත. නෝඩ් වල තව් නොමැති නම්, මෙය කුඩා ගැටළුවකි, නමුත් අපට පළමුව වහලුන් මකා දැමිය හැකි නම් අපට අමතර තේරීම් අවශ්‍ය වන්නේ ඇයි?
• ඔබට මාස්ටර් සහ වහල් තනතුරු බලහත්කාරයෙන් මාරු කිරීමට අවශ්‍ය නම්, පොකුරු අසාර්ථක විධානය සිදු කරනු ඇත. එය සටනේදී ඇමතීමේදී, මෙහෙයුම අතරතුර ස්වාමියා නොමැති බව ඔබ තේරුම් ගත යුතුය. සාමාන්‍යයෙන් ස්විචය තත්පරයකට වඩා අඩු කාලයකදී සිදු වේ, නමුත් පරමාණුක නොවේ. මෙම කාලය තුළ මාස්ටර් වෙත සමහර ඉල්ලීම් අසාර්ථක වනු ඇතැයි ඔබට අපේක්ෂා කළ හැකිය.
• පොකුරෙන් නෝඩයක් ඉවත් කිරීමට පෙර, එය මත තව් නොතිබිය යුතුය. Cluster reshard විධානය භාවිතයෙන් ඒවා නැවත බෙදා හැරීම වඩා හොඳය. ස්ලොට් එක් ප්‍රධානියෙකුගෙන් තවත් ප්‍රධානයෙකුට මාරු කරනු ලැබේ. සම්පූර්ණ මෙහෙයුම මිනිත්තු කිහිපයක් ගතවනු ඇත, එය මාරු කරන දත්ත පරිමාව මත රඳා පවතී, නමුත් හුවමාරු ක්රියාවලිය ආරක්ෂිත වන අතර පොකුරේ ක්රියාකාරිත්වයට කිසිදු ආකාරයකින් බලපාන්නේ නැත. මේ අනුව, සියලුම දත්ත එක් නෝඩයකින් තවත් නෝඩයකට සෘජුවම පැටවීම යටතේ මාරු කළ හැකි අතර එහි ඇති බව ගැන කරදර නොවී. කෙසේ වෙතත්, සියුම්කම් ද ඇත. පළමුව, දත්ත හුවමාරුව ලබන්නාගේ සහ යවන්නාගේ නෝඩ් වල යම් බරක් සමඟ සම්බන්ධ වේ. ලබන්නාගේ නෝඩය දැනටමත් ප්‍රොසෙසරය මත දැඩි ලෙස පටවා තිබේ නම්, ඔබ එය නව දත්ත ලැබීමෙන් පූරණය නොකළ යුතුය. දෙවනුව, යවන ස්වාමියා මත එක තව් එකක්වත් ඉතිරි නොවූ විගසම, එහි සියලුම වහලුන් වහාම මෙම කට්ට මාරු කළ ස්වාමියා වෙත යයි. තවද ගැටළුව වන්නේ මෙම සියලු වහලුන්ට එකවර දත්ත සමමුහුර්ත කිරීමට අවශ්‍ය වීමයි. එය සම්පූර්ණ සමමුහුර්තකරණයට වඩා අර්ධ වශයෙන් නම් ඔබ වාසනාවන්ත වනු ඇත. මෙය සැලකිල්ලට ගෙන තව් මාරු කිරීමේ සහ වහලුන් අක්‍රීය කිරීමේ/මාරු කිරීමේ මෙහෙයුම් ඒකාබද්ධ කරන්න. නැතහොත් ඔබට ප්‍රමාණවත් ආරක්ෂාවක් ඇතැයි බලාපොරොත්තු වන්න.
• ස්ථාන මාරුව අතරතුර, ඔබට කොතැනක හෝ ස්ථාන අහිමි වී ඇති බව ඔබට පෙනී ගියහොත් ඔබ කළ යුත්තේ කුමක්ද? මෙම ගැටළුව ඔබට බලපාන්නේ නැතැයි මම බලාපොරොත්තු වෙමි, නමුත් එය එසේ නම්, පොකුරු සවි කිරීමේ මෙහෙයුමක් ඇත. අවම වශයෙන්, ඇය අහඹු අනුපිළිවෙලකට නෝඩ් හරහා තව් විසුරුවා හරිනු ඇත. පොකුරෙන් බෙදා හරින ලද තව් සහිත නෝඩය පළමුව ඉවත් කිරීමෙන් එහි ක්‍රියාකාරිත්වය පරීක්ෂා කිරීමට මම නිර්දේශ කරමි. වෙන් නොකළ තව් වල දත්ත දැනටමත් නොමැති බැවින්, මෙම තව් ලබා ගැනීමේ ගැටළු ගැන කරදර වීමට ප්‍රමාද වැඩිය. අනෙක් අතට, මෙහෙයුම බෙදා හරින ලද තව් වලට බලපාන්නේ නැත.
• තවත් ප්රයෝජනවත් මෙහෙයුමක් වන්නේ මොනිටරයයි. නෝඩ් වෙත යන සම්පූර්ණ ඉල්ලීම් ලැයිස්තුව තත්‍ය කාලීනව බැලීමට එය ඔබට ඉඩ සලසයි. එපමණක් නොව, ඔබට එය ග්‍රැප් කර අවශ්‍ය ගමනාගමනය තිබේදැයි සොයා බැලිය හැකිය.

ප්රධාන අසාර්ථක ක්රියා පටිපාටිය ද සඳහන් කිරීම වටී. කෙටියෙන් කිවහොත්, එය පවතින අතර, මගේ මතය අනුව, එය විශිෂ්ට ලෙස ක්රියා කරයි. කෙසේ වෙතත්, ඔබ ප්‍රධාන නෝඩයක් සහිත යන්ත්‍රයක් මත විදුලි රැහැන විසන්ධි කළහොත්, රෙඩිස් වහාම මාරු වන අතර ගනුදෙනුකරුවන්ට පාඩුව නොපෙනේ. මගේ ප්රායෝගිකව, මාරුවීම තත්පර කිහිපයකින් සිදු වේ. මෙම කාලය තුළ, සමහර දත්ත ලබා ගත නොහැකි වනු ඇත: ස්වාමියාගේ නොලැබීම අනාවරණය වේ, නෝඩ් නව එකක් සඳහා ඡන්දය දෙයි, වහලුන් මාරු කරනු ලැබේ, දත්ත සමමුහුර්ත කර ඇත. යෝජනා ක්රමය ක්රියාත්මක වන බව ඔබම තහවුරු කර ගැනීමට හොඳම ක්රමය වන්නේ දේශීය අභ්යාස පැවැත්වීමයි. ඔබගේ ලැප්ටොප් පරිගණකයේ පොකුර ඔසවන්න, අවම බරක් ලබා දෙන්න, බිඳ වැටීමක් අනුකරණය කරන්න (උදාහරණයක් ලෙස, වරාය අවහිර කිරීමෙන්) සහ මාරු වීමේ වේගය තක්සේරු කරන්න. මගේ මතය අනුව, ඔබට තාක්‍ෂණයේ ක්‍රියාකාරිත්වය පිළිබඳ විශ්වාසය තැබිය හැක්කේ දිනක් හෝ දෙකක් මේ ආකාරයෙන් ක්‍රීඩා කිරීමෙන් පසුව පමණි. හොඳයි, නැතහොත් අන්තර්ජාලයෙන් අඩක් භාවිතා කරන මෘදුකාංගය ක්‍රියාත්මක වේ යැයි බලාපොරොත්තු වන්න.

වින්‍යාසය

බොහෝ විට, ඔබට මෙවලම සමඟ වැඩ කිරීම ආරම්භ කිරීමට අවශ්‍ය පළමු දෙය වින්‍යාසයයි. තවද සෑම දෙයක්ම ක්‍රියාත්මක වන විට, ඔබට වින්‍යාසය ස්පර්ශ කිරීමට පවා අවශ්‍ය නැත. සැකසීම් වෙත ආපසු යාමට සහ ඒවා පරිස්සමෙන් යන්නට ඔබට බල කිරීමට යම් උත්සාහයක් අවශ්‍ය වේ. මගේ මතකයේ හැටියට, වින්‍යාසය කෙරෙහි අවධානය යොමු නොකිරීම නිසා අපට අවම වශයෙන් බරපතල අසාර්ථකවීම් දෙකක්වත් තිබුණි. පහත සඳහන් කරුණු කෙරෙහි විශේෂ අවධානය යොමු කරන්න:

• කල් ඉකුත් වීම 0
  අක්‍රිය සම්බන්ධතා වසා දැමූ කාලය (තත්පර වලින්). 0 - වසා නොගන්න
  අපගේ සෑම පුස්තකාලයකටම සම්බන්ධතා නිවැරදිව වසා දැමීමට නොහැකි විය. මෙම සැකසීම අක්‍රිය කිරීමෙන්, අපි සේවාලාභීන් සංඛ්‍යාවේ සීමාවට පැමිණීමේ අවදානමක් ඇත. අනෙක් අතට, එවැනි ගැටළුවක් තිබේ නම්, නැතිවූ සම්බන්ධතා ස්වයංක්‍රීයව අවසන් කිරීම එය වසං කරනු ඇති අතර, අපට එය නොපෙනේ. ඊට අමතරව, අඛණ්ඩ සම්බන්ධතා භාවිතා කරන විට ඔබ මෙම සැකසුම සක්‍රීය නොකළ යුතුය.
• xy සුරකින්න සහ ඔව් පමණක් එකතු කරන්න
  RDB ස්නැප්ෂොට් එකක් සුරකිමින්.
  අපි RDB/AOF ගැටළු පහත විස්තරාත්මකව සාකච්ඡා කරමු.
• bgsave-error no & slave-serve-stale-data ඔව්
  සබල කර ඇත්නම්, RDB ස්නැප්ෂොට් කැඩී ගියහොත්, ස්වාමියා වෙනස් කිරීමේ ඉල්ලීම් පිළිගැනීම නවත්වනු ඇත. ස්වාමියා සමඟ ඇති සම්බන්ධය නැති වුවහොත්, දාසයාට ඉල්ලීම් වලට ප්‍රතිචාර දැක්වීමට (ඔව්). නැතහොත් ප්‍රතිචාර දැක්වීම නවත්වනු ඇත (නැත)
  රෙඩිස් වට්ටක්කා ගෙඩියක් බවට පත්වන තත්ත්වය ගැන අපි සතුටු නොවෙමු.
• repl-ping-slave-period 5
  මෙම කාල පරිච්ඡේදයෙන් පසු, ස්වාමියා බිඳී ගොස් ඇති බවත්, අසාර්ථක ක්රියා පටිපාටිය ක්රියාත්මක කිරීමට කාලය පැමිණ ඇති බවත් අපි කරදර වීමට පටන් ගනිමු.
  ව්‍යාජ ධනාත්මක සහ අසාර්ථකත්වය අවුලුවාලීම අතර සමතුලිතතාවයක් ඔබට අතින් සොයා ගැනීමට සිදුවනු ඇත. අපගේ ප්රායෝගිකව මෙය තත්පර 5 කි.
• repl-backlog-size 1024mb සහ epl-backlog-ttl 0
  අසාර්ථක වූ අනුරුවක් සඳහා අපට බෆරයක හරියටම මෙපමණ දත්ත ගබඩා කළ හැක. බෆරය අවසන් වුවහොත්, ඔබට සම්පූර්ණයෙන්ම සමමුහුර්ත කිරීමට සිදුවනු ඇත.
  ප්රායෝගිකව යෝජනා කරන්නේ ඉහළ අගයක් සැකසීම වඩා හොඳ බවයි. අනුරුවක් ප්‍රමාද වීමට පටන් ගැනීමට බොහෝ හේතු තිබේ. එය ප්‍රමාද වන්නේ නම්, බොහෝ විට ඔබේ ස්වාමියා දැනටමත් මුහුණ දීමට අරගල කරමින් සිටින අතර සම්පූර්ණ සමමුහුර්තකරණය අවසාන පිදුරු වනු ඇත.
• maxclients 10000
  එක් වරක් සේවාලාභීන්ගේ උපරිම සංඛ්‍යාව.
  අපගේ අත්දැකීම් අනුව, ඉහළ අගයක් තැබීම වඩා හොඳය. Redis 10k සම්බන්ධතා හොඳින් හසුරුවයි. පද්ධතියේ ප්‍රමාණවත් සොකට් ඇති බවට වග බලා ගන්න.
• maxmemory-policy volatile-ttl
  පවතින මතක සීමාවට ළඟා වූ විට යතුරු මකා දමන රීතිය.
  මෙහිදී වැදගත් වන්නේ රීතියම නොව, මෙය සිදුවන්නේ කෙසේද යන්න පිළිබඳ අවබෝධයයි. මතක සීමාවට ළඟා වූ විට සාමාන්යයෙන් වැඩ කිරීමට ඇති හැකියාව සඳහා Redis හට ප්රශංසා කළ හැකිය.

RDB සහ AOF ගැටළු

Redis විසින්ම RAM හි සියලු තොරතුරු ගබඩා කර ඇතත්, තැටියට දත්ත සුරැකීමේ යාන්ත්රණයක් ද ඇත. වඩාත් නිවැරදිව, යාන්ත්රණ තුනක්:

• RDB-snapshot - සියලුම දත්තවල සම්පූර්ණ ඡායාරූපයකි. SAVE XY වින්‍යාසය භාවිතයෙන් සකසන්න සහ "අවම වශයෙන් Y යතුරු වෙනස් වී ඇත්නම් සෑම X තත්පරයකම සියලුම දත්තවල සම්පූර්ණ ඡායාරූපයක් සුරකින්න" කියවන්න.
• ඇමිණුම්-පමණි ගොනුව - ඒවා සිදු කරන අනුපිළිවෙලෙහි මෙහෙයුම් ලැයිස්තුවකි. සෑම X තත්පරයකටම හෝ සෑම Y මෙහෙයුමකදීම ගොනුවට නව එන මෙහෙයුම් එකතු කරයි.
• RDB සහ AOF යනු පෙර දෙකේ එකතුවකි.

සියලුම ක්‍රමවලට ඒවායේ වාසි සහ අවාසි ඇත, මම ඒවා සියල්ලම ලැයිස්තුගත නොකරමි, මගේ මතය අනුව පැහැදිලි නොවන කරුණු කෙරෙහි අවධානය යොමු කරමි.

පළමුව, RDB ස්නැප්ෂොට් එකක් සුරැකීමට FORK ඇමතීම අවශ්‍ය වේ. දත්ත විශාල ප්‍රමාණයක් තිබේ නම්, මෙය මිලි තත්පර කිහිපයක සිට තත්පරයක කාලයක් සඳහා සියලුම Redis එල්ලා තැබිය හැක. මීට අමතරව, පද්ධතියට එවැනි ස්නැප්ෂොට් එකක් සඳහා මතකය වෙන් කිරීමට අවශ්‍ය වන අතර එමඟින් තාර්කික යන්ත්‍රයේ ද්විත්ව RAM සැපයුමක් තබා ගැනීමේ අවශ්‍යතාවයට හේතු වේ: රෙඩිස් සඳහා 8 GB වෙන් කර ඇත්නම්, අථත්‍ය යන්ත්‍රයේ 16 GB ලබා ගත යුතුය. එය.

දෙවනුව, අර්ධ සමමුහුර්තකරණයේ ගැටළු තිබේ. AOF මාදිලියේදී, වහල් නැවත සම්බන්ධ වූ විට, අර්ධ සමමුහුර්තකරණය වෙනුවට, සම්පූර්ණ සමමුහුර්තකරණය සිදු කළ හැක. මෙය සිදුවන්නේ ඇයි, මට තේරුම් ගත නොහැකි විය. නමුත් මෙය මතක තබා ගැනීම වටී.

සෑම දෙයක්ම දැනටමත් වහලුන් විසින් අනුපිටපත් කර ඇත්නම් තැටියේ මෙම දත්ත අපට සැබවින්ම අවශ්‍ය දැයි මෙම කරුණු දෙක දැනටමත් අපව සිතීමට සලස්වයි. දත්ත අහිමි විය හැක්කේ සියලුම වහලුන් අසමත් වුවහොත් පමණක් වන අතර මෙය "DC හි ගින්න" මට්ටමේ ගැටලුවකි. සම්මුතියක් ලෙස, ඔබට වහලුන් මත පමණක් දත්ත සුරැකීමට යෝජනා කළ හැකිය, නමුත් මෙම අවස්ථාවේ දී මෙම වහලුන් ආපදා ප්‍රතිසාධනයේදී කිසි විටෙකත් ස්වාමියා බවට පත් නොවන බවට ඔබ සහතික විය යුතුය (මේ සඳහා ඔවුන්ගේ වින්‍යාසය තුළ වහල් ප්‍රමුඛතා සැකසුම ඇත). අප සඳහාම, එක් එක් විශේෂිත අවස්ථාවන්හිදී අපි තැටියට දත්ත සුරැකීමට අවශ්යදැයි සිතන්නෙමු, බොහෝ විට පිළිතුර "නැත" වේ.

නිගමනය

අවසාන වශයෙන්, Redis-cluster ගැන අසා නැති අය සඳහා එය ක්‍රියා කරන ආකාරය පිළිබඳ සාමාන්‍ය අදහසක් ලබා දීමට මට හැකි වූ බව මම බලාපොරොත්තු වෙමි, එසේම එය භාවිතා කරන අයට නොපැහැදිලි කරුණු කිහිපයක් කෙරෙහි අවධානය යොමු කළෙමි. දිගු කාලයකට.
ඔබගේ කාලය සඳහා ස්තූතියි, සෑම විටම මෙන්, මාතෘකාව පිළිබඳ අදහස් සාදරයෙන් පිළිගනිමු.

මූලාශ්රය: www.habr.com