એક દાયકા કરતાં વધુ સમયથી વિકાસશીલ પ્રોડક્ટ પર આવી રહ્યા છે, તેમાં જૂની ટેક્નોલોજીઓ શોધવી એ જરાય આશ્ચર્યજનક નથી. પરંતુ શું જો છ મહિનામાં તમારે ભાર 10 ગણો વધારે રાખવો પડશે, અને ફોલ્સની કિંમત સેંકડો ગણી વધી જશે? આ કિસ્સામાં, તમારે કૂલ હાઇલોડ એન્જિનિયરની જરૂર છે. પરંતુ નોકરાણીની ગેરહાજરીમાં, તેઓએ મને સમસ્યા હલ કરવાની જવાબદારી સોંપી. લેખના પહેલા ભાગમાં હું તમને કહીશ કે અમે રેડિસથી રેડિસ-ક્લસ્ટરમાં કેવી રીતે ગયા, અને બીજા ભાગમાં હું ક્લસ્ટરનો ઉપયોગ કેવી રીતે શરૂ કરવો અને તેનો ઉપયોગ કરતી વખતે શું ધ્યાન આપવું તે અંગે સલાહ આપીશ.

તકનીકી પસંદગી

શું તે ખરાબ છે? અલગ રેડિસ (સ્ટેન્ડઅલોન રેડિસ) 1 માસ્ટર અને એન સ્લેવના રૂપરેખાંકનમાં? શા માટે હું તેને અપ્રચલિત ટેકનોલોજી કહું?

ના, રેડિસ એટલું ખરાબ નથી... જો કે, કેટલીક ખામીઓ છે જેને અવગણી શકાય નહીં.

• પ્રથમ, મુખ્ય નિષ્ફળતા પછી Redis આપત્તિ પુનઃપ્રાપ્તિ પદ્ધતિને સમર્થન આપતું નથી. આ સમસ્યાને ઉકેલવા માટે, અમે નવા માસ્ટરને વીઆઈપીના સ્વચાલિત સ્થાનાંતરણ સાથેના રૂપરેખાંકનનો ઉપયોગ કર્યો, એક સ્લેવની ભૂમિકા બદલીને અને બાકીનાને સ્વિચ કર્યા. આ મિકેનિઝમ કામ કર્યું, પરંતુ તેને વિશ્વસનીય ઉકેલ કહી શકાય નહીં. પ્રથમ, ખોટા એલાર્મ્સ આવ્યા, અને બીજું, તે નિકાલજોગ હતું, અને ઓપરેશન પછી સ્પ્રિંગ ચાર્જ કરવા માટે મેન્યુઅલ ક્રિયાઓ જરૂરી હતી.

• બીજું, ફક્ત એક જ માસ્ટર હોવાને કારણે શાર્ડિંગની સમસ્યા થઈ. અમારે ઘણા સ્વતંત્ર ક્લસ્ટર્સ “1 માસ્ટર અને એન સ્લેવ્સ” બનાવવાના હતા, પછી આ મશીનો વચ્ચે મેન્યુઅલી ડેટાબેસેસનું વિતરણ કરવું પડ્યું અને આશા રાખીએ કે આવતીકાલે ડેટાબેઝમાંનો એક એટલો ફૂલશે નહીં કે તેને અલગ દાખલામાં ખસેડવો પડશે.

વિકલ્પો શું છે?

• સૌથી મોંઘા અને સૌથી ધનાઢ્ય સોલ્યુશન એ Redis-Enterprise છે. આ સંપૂર્ણ તકનીકી સપોર્ટ સાથે બોક્સવાળી સોલ્યુશન છે. તકનીકી દૃષ્ટિકોણથી તે આદર્શ લાગે છે તે હકીકત હોવા છતાં, તે વૈચારિક કારણોસર અમને અનુકૂળ ન હતું.
• રેડિસ-ક્લસ્ટર. બૉક્સની બહાર માસ્ટર ફેલઓવર અને શાર્ડિંગ માટે સપોર્ટ છે. ઇન્ટરફેસ નિયમિત સંસ્કરણથી લગભગ અલગ નથી. તે આશાસ્પદ લાગે છે, અમે પછીથી મુશ્કેલીઓ વિશે વાત કરીશું.
• ટેરન્ટૂલ, મેમકેચે, એરોસ્પાઇક અને અન્ય. આ બધા સાધનો લગભગ સમાન વસ્તુ કરે છે. પરંતુ દરેકની પોતાની ખામીઓ છે. અમે અમારા બધા ઇંડાને એક ટોપલીમાં ન મૂકવાનું નક્કી કર્યું. અમે અન્ય કાર્યો માટે Memcache અને Tarantool નો ઉપયોગ કરીએ છીએ, અને આગળ જોઈને, હું કહીશ કે અમારી પ્રેક્ટિસમાં તેમની સાથે વધુ સમસ્યાઓ હતી.

ઉપયોગની વિશિષ્ટતાઓ

ચાલો આપણે Redis સાથે ઐતિહાસિક રીતે કઈ સમસ્યાઓ હલ કરી છે અને અમે કઈ કાર્યક્ષમતાનો ઉપયોગ કર્યો છે તેના પર એક નજર કરીએ:

• 2GIS | જેવી દૂરસ્થ સેવાઓની વિનંતીઓ પહેલાં કેશ ગોલાંગ
  

  સેટ મેળવો MGET MSET "સિલેક્ટ ડીબી"

• MYSQL પહેલા કેશ | PHP
  

  સેટ કરો MGET MSET SCAN "કી બાય પેટર્ન" "ડીબી પસંદ કરો"

• સત્રો અને ડ્રાઇવર કોઓર્ડિનેટ્સ સાથે કામ કરવાની સેવા માટેનું મુખ્ય સ્ટોરેજ | ગોલાંગ
  

  GET SET MGET MSET "સિલેક્ટ DB" "જિયો કી ઉમેરો" "જીઓ કી મેળવો" સ્કેન મેળવો

જેમ તમે જોઈ શકો છો, કોઈ ઉચ્ચ ગણિત નથી. તો પછી મુશ્કેલી શું છે? ચાલો દરેક પદ્ધતિને અલગથી જોઈએ.

પદ્ધતિ
વર્ણન
રેડિસ-ક્લસ્ટરની વિશેષતાઓ
નિર્ણય

સેટ કરો
કી લખો/વાંચો

MGET MSET
બહુવિધ કી લખો/વાંચો
કીઓ અલગ-અલગ નોડ્સ પર હશે. તૈયાર પુસ્તકાલયો માત્ર એક નોડની અંદર બહુવિધ કામગીરી કરી શકે છે
MGET ને N GET કામગીરીની પાઇપલાઇન સાથે બદલો

DB પસંદ કરો
અમે જેની સાથે કામ કરીશું તે આધાર પસંદ કરો
બહુવિધ ડેટાબેસેસને સપોર્ટ કરતું નથી
એક ડેટાબેઝમાં બધું મૂકો. કીમાં ઉપસર્ગ ઉમેરો

સ્કેન
ડેટાબેઝમાંની બધી કી મારફતે જાઓ
અમારી પાસે એક ડેટાબેઝ હોવાથી, ક્લસ્ટરની બધી કીમાંથી પસાર થવું ખૂબ ખર્ચાળ છે
એક કીની અંદર ઇન્વેરિઅન્ટ જાળવી રાખો અને આ કી પર HSCAN કરો. અથવા સંપૂર્ણપણે ઇનકાર કરો

જીઇઓ
જીઓકી સાથેની કામગીરી
જીઓકી શાર્ડેડ નથી

પેટર્ન દ્વારા કી
પેટર્ન દ્વારા કી શોધી રહ્યાં છીએ
અમારી પાસે એક ડેટાબેઝ હોવાથી, અમે ક્લસ્ટરની બધી કીમાં શોધીશું. ખૂબ ખર્ચાળ
SCAN ના કેસની જેમ, અપરિવર્તકને નકારો અથવા જાળવી રાખો

રેડિસ વિ રેડિસ-ક્લસ્ટર

ક્લસ્ટર પર સ્વિચ કરતી વખતે આપણે શું ગુમાવીએ છીએ અને શું મેળવીએ છીએ?

• ગેરફાયદા: અમે ઘણા ડેટાબેસેસની કાર્યક્ષમતા ગુમાવીએ છીએ.
  • જો આપણે તાર્કિક રીતે અસંબંધિત ડેટાને એક ક્લસ્ટરમાં સંગ્રહિત કરવા માંગીએ છીએ, તો અમારે ઉપસર્ગના રૂપમાં ક્રેચ બનાવવા પડશે.
  • અમે SCAN, DBSIZE, CLEAR DB વગેરે જેવા તમામ "બેઝ" ઑપરેશન ગુમાવીએ છીએ.
  • મલ્ટી-ઓપરેશન્સ અમલમાં મૂકવું વધુ મુશ્કેલ બની ગયું છે કારણ કે તેને ઘણા નોડ્સની ઍક્સેસની જરૂર પડી શકે છે.
• પ્લુસ:
  • માસ્ટર ફેલઓવરના રૂપમાં ફોલ્ટ સહિષ્ણુતા.
  • Redis બાજુ પર Sharding.
  • નોડ્સ વચ્ચે પરમાણુ અને ડાઉનટાઇમ વિના ડેટા ટ્રાન્સફર કરો.
  • ડાઉનટાઇમ વિના ક્ષમતા અને લોડ ઉમેરો અને પુનઃવિતરિત કરો.

હું નિષ્કર્ષ પર આવીશ કે જો તમારે ઉચ્ચ સ્તરની ખામી સહિષ્ણુતા પ્રદાન કરવાની જરૂર નથી, તો પછી ક્લસ્ટરમાં ખસેડવું તે યોગ્ય નથી, કારણ કે તે બિન-તુચ્છ કાર્ય હોઈ શકે છે. પરંતુ જો તમે શરૂઆતમાં અલગ સંસ્કરણ અને ક્લસ્ટર સંસ્કરણ વચ્ચે પસંદ કરો છો, તો તમારે ક્લસ્ટર પસંદ કરવું જોઈએ, કારણ કે તે વધુ ખરાબ નથી અને તે ઉપરાંત, તમને માથાનો દુખાવોમાંથી રાહત આપશે.

ખસેડવાની તૈયારી કરી રહી છે

ચાલો ખસેડવા માટેની આવશ્યકતાઓથી પ્રારંભ કરીએ:

• તે સીમલેસ હોવું જોઈએ. 5 મિનિટ માટે સેવાનો સંપૂર્ણ સ્ટોપ અમને અનુકૂળ નથી.
• તે શક્ય તેટલું સલામત અને ધીમે ધીમે હોવું જોઈએ. હું પરિસ્થિતિ પર થોડો નિયંત્રણ રાખવા માંગુ છું. અમે એક જ સમયે બધું ડમ્પ કરવા અને રોલબેક બટન પર પ્રાર્થના કરવા માંગતા નથી.
• ખસેડતી વખતે ન્યૂનતમ ડેટા નુકશાન. અમે સમજીએ છીએ કે પરમાણુ રીતે ખસેડવું ખૂબ મુશ્કેલ હશે, તેથી અમે નિયમિત અને ક્લસ્ટર્ડ રેડિસમાં ડેટા વચ્ચે કેટલાક ડિસિંક્રોનાઇઝેશનને મંજૂરી આપીએ છીએ.

ક્લસ્ટર જાળવણી

ચાલ પહેલા, આપણે વિચારવું જોઈએ કે શું આપણે ક્લસ્ટરને સમર્થન આપી શકીએ છીએ:

• ચાર્ટ્સ. અમે CPU લોડ, મેમરી વપરાશ, ક્લાયન્ટની સંખ્યા, GET, SET, AUTH ઑપરેશન્સ વગેરેની સંખ્યાને ગ્રાફ કરવા માટે પ્રોમિથિયસ અને ગ્રાફનાનો ઉપયોગ કરીએ છીએ.
• નિપુણતા. કલ્પના કરો કે આવતીકાલે તમારી જવાબદારી હેઠળ તમારી પાસે એક વિશાળ ક્લસ્ટર હશે. જો તે તૂટી જાય, તો તમે સિવાય કોઈ તેને ઠીક કરી શકશે નહીં. જો તે ધીમું થવાનું શરૂ કરશે, તો દરેક તમારી તરફ દોડશે. જો તમારે સંસાધનો ઉમેરવા અથવા લોડને ફરીથી વિતરિત કરવાની જરૂર હોય, તો તમારી પાસે પાછા આવો. 25 વર્ષની ઉંમરે ગ્રે ન થાય તે માટે, આ કેસો માટે પ્રદાન કરવાની સલાહ આપવામાં આવે છે અને અગાઉથી તપાસો કે ટેક્નોલોજી ચોક્કસ ક્રિયાઓ હેઠળ કેવી રીતે વર્તશે. ચાલો "નિષ્ણાત" વિભાગમાં આ વિશે વધુ વિગતવાર વાત કરીએ.
• મોનીટરીંગ અને ચેતવણીઓ. જ્યારે કોઈ ક્લસ્ટર તૂટી જાય છે, ત્યારે તમે તેના વિશે જાણવા માટે પ્રથમ બનવા માંગો છો. અહીં અમે અમારી જાતને એક સૂચના સુધી મર્યાદિત કરી છે કે તમામ નોડ્સ ક્લસ્ટરની સ્થિતિ વિશે સમાન માહિતી પરત કરે છે (હા, તે અલગ રીતે થાય છે). અને અન્ય સમસ્યાઓ Redis ક્લાયન્ટ સેવાઓ તરફથી ચેતવણીઓ દ્વારા વધુ ઝડપથી નોંધી શકાય છે.

ખસેડવું

અમે કેવી રીતે ખસેડીશું:

• સૌ પ્રથમ, તમારે ક્લસ્ટર સાથે કામ કરવા માટે લાઇબ્રેરી તૈયાર કરવાની જરૂર છે. અમે ગો વર્ઝન માટે ગો-રેડીસને આધાર તરીકે લીધો અને તેને પોતાને અનુકૂળ આવે તે રીતે થોડો બદલ્યો. અમે પાઇપલાઇન્સ દ્વારા મલ્ટિ-મેથોડ્સનો અમલ કર્યો, અને વિનંતીઓનું પુનરાવર્તન કરવા માટેના નિયમોમાં પણ થોડો સુધારો કર્યો. PHP સંસ્કરણમાં વધુ સમસ્યાઓ હતી, પરંતુ અમે આખરે php-redis પર સ્થાયી થયા. તેઓએ તાજેતરમાં ક્લસ્ટર સપોર્ટ રજૂ કર્યો છે અને તે અમારા મતે સારું લાગે છે.
• આગળ તમારે ક્લસ્ટરને જ જમાવવાની જરૂર છે. આ રૂપરેખાંકન ફાઇલ પર આધારિત બે આદેશોમાં શાબ્દિક રીતે કરવામાં આવે છે. અમે નીચે વધુ વિગતવાર સેટિંગની ચર્ચા કરીશું.
• ધીમે ધીમે ખસેડવા માટે અમે ડ્રાય-મોડનો ઉપયોગ કરીએ છીએ. અમારી પાસે સમાન ઇન્ટરફેસ સાથે લાઇબ્રેરીના બે સંસ્કરણો હોવાથી (એક નિયમિત સંસ્કરણ માટે, બીજું ક્લસ્ટર માટે), રેપર બનાવવા માટે કોઈ ખર્ચ નથી જે એક અલગ સંસ્કરણ સાથે કાર્ય કરશે અને ક્લસ્ટરની બધી વિનંતીઓને સમાંતર ડુપ્લિકેટ કરશે, પ્રતિસાદોની તુલના કરો અને લોગમાં વિસંગતતાઓ લખો (અમારા કિસ્સામાં ન્યુરેલિકમાં). આમ, રોલઆઉટ દરમિયાન ક્લસ્ટર વર્ઝન તૂટી જાય તો પણ અમારા ઉત્પાદનને અસર થશે નહીં.
• ક્લસ્ટરને ડ્રાય મોડમાં રોલઆઉટ કર્યા પછી, અમે શાંતિથી પ્રતિભાવ વિસંગતતાઓના ગ્રાફને જોઈ શકીએ છીએ. જો ભૂલ દર ધીમે ધીમે પરંતુ ચોક્કસ કેટલાક નાના સ્થિરાંક તરફ આગળ વધે છે, તો બધું સારું છે. શા માટે હજુ પણ વિસંગતતાઓ છે? કારણ કે અલગ સંસ્કરણમાં રેકોર્ડિંગ ક્લસ્ટર કરતાં થોડું વહેલું થાય છે, અને માઇક્રોલેગને કારણે, ડેટા અલગ થઈ શકે છે. જે બાકી છે તે વિસંગતતા લોગ જોવાનું છે, અને જો તે બધા રેકોર્ડની બિન-પરમાણુતા દ્વારા સમજાવવામાં આવે, તો આપણે આગળ વધી શકીએ છીએ.
• હવે તમે ડ્રાય-મોડને વિરુદ્ધ દિશામાં સ્વિચ કરી શકો છો. અમે ક્લસ્ટરમાંથી લખી અને વાંચીશું, અને તેને અલગ સંસ્કરણમાં ડુપ્લિકેટ કરીશું. શેના માટે? આવતા અઠવાડિયે હું ક્લસ્ટરના કામનું અવલોકન કરવા માંગુ છું. જો તે અચાનક બહાર આવે કે પીક લોડ પર સમસ્યાઓ છે, અથવા અમે કંઈક ધ્યાનમાં લીધું નથી, તો અમારી પાસે હંમેશા જૂના કોડ પર કટોકટી રોલબેક હોય છે અને ડ્રાય-મોડને કારણે વર્તમાન ડેટાનો આભાર.
• જે બાકી છે તે ડ્રાય-મોડને અક્ષમ કરવાનું અને અલગ સંસ્કરણને તોડી પાડવાનું છે.

કુશળતા

પ્રથમ, ક્લસ્ટર ડિઝાઇન વિશે ટૂંકમાં.

સૌ પ્રથમ, રેડિસ એ કી-વેલ્યુ સ્ટોર છે. આર્બિટરી સ્ટ્રિંગ્સનો ઉપયોગ કી તરીકે થાય છે. સંખ્યાઓ, શબ્દમાળાઓ અને સમગ્ર માળખાનો ઉપયોગ મૂલ્યો તરીકે થઈ શકે છે. બાદમાં ઘણા બધા છે, પરંતુ સામાન્ય રચનાને સમજવા માટે આ આપણા માટે મહત્વપૂર્ણ નથી.
કીઓ પછી અમૂર્તતાનું આગલું સ્તર સ્લોટ્સ (SLOTS) છે. દરેક કી 16 સ્લોટમાંથી એકની છે. દરેક સ્લોટની અંદર ગમે તેટલી સંખ્યામાં કી હોઈ શકે છે. આમ, બધી કીને 383 ડિસજોઇન્ટ સેટમાં વહેંચવામાં આવી છે.

આગળ, ક્લસ્ટરમાં N માસ્ટર નોડ્સ હોવા જોઈએ. દરેક નોડને એક અલગ રેડિસ ઉદાહરણ તરીકે વિચારી શકાય છે જે ક્લસ્ટરની અંદરના અન્ય નોડ્સ વિશે બધું જ જાણે છે. દરેક માસ્ટર નોડમાં સંખ્યાબંધ સ્લોટ હોય છે. દરેક સ્લોટ માત્ર એક માસ્ટર નોડનો છે. બધા સ્લોટ્સ નોડ્સ વચ્ચે વિતરિત કરવાની જરૂર છે. જો કેટલાક સ્લોટ ફાળવવામાં આવ્યા નથી, તો તેમાં સંગ્રહિત કીઓ અપ્રાપ્ય હશે. દરેક માસ્ટર નોડને અલગ લોજિકલ અથવા ફિઝિકલ મશીન પર ચલાવવાનો અર્થ છે. તે યાદ રાખવું પણ યોગ્ય છે કે દરેક નોડ ફક્ત એક કોર પર ચાલે છે, અને જો તમે એક જ લોજિકલ મશીન પર બહુવિધ રેડિસ દાખલાઓ ચલાવવા માંગતા હો, તો ખાતરી કરો કે તેઓ વિવિધ કોરો પર ચાલે છે (અમે આનો પ્રયાસ કર્યો નથી, પરંતુ સિદ્ધાંતમાં તે કામ કરવું જોઈએ) . અનિવાર્યપણે, માસ્ટર નોડ્સ નિયમિત શાર્ડિંગ પ્રદાન કરે છે, અને વધુ માસ્ટર નોડ્સ લખવા અને વાંચવાની વિનંતીઓને સ્કેલ કરવાની મંજૂરી આપે છે.

બધી ચાવીઓ સ્લોટ્સ વચ્ચે વિતરિત થયા પછી, અને સ્લોટ્સ માસ્ટર નોડ્સ વચ્ચે વેરવિખેર થઈ ગયા પછી, દરેક માસ્ટર નોડમાં સ્લેવ નોડ્સની મનસ્વી સંખ્યા ઉમેરી શકાય છે. આવી દરેક માસ્ટર-સ્લેવ લિંકની અંદર, સામાન્ય પ્રતિકૃતિ કામ કરશે. વાંચન વિનંતીઓને માપવા માટે અને માસ્ટર નિષ્ફળતાના કિસ્સામાં નિષ્ફળતા માટે સ્લેવ્સની જરૂર છે.

હવે ચાલો એવા ઓપરેશન્સ વિશે વાત કરીએ જે કરવા માટે સક્ષમ થવું વધુ સારું રહેશે.

અમે Redis-CLI મારફતે સિસ્ટમને ઍક્સેસ કરીશું. Redis પાસે એક પણ એન્ટ્રી પોઈન્ટ ન હોવાથી, તમે કોઈપણ નોડ્સ પર નીચેની કામગીરી કરી શકો છો. દરેક બિંદુએ હું અલગથી લોડ હેઠળ ઓપરેશન કરવાની શક્યતા તરફ ધ્યાન દોરું છું.

• પ્રથમ અને સૌથી મહત્વની વસ્તુ જે આપણને જોઈએ છે તે છે ક્લસ્ટર નોડ્સ ઓપરેશન. તે ક્લસ્ટરની સ્થિતિ પરત કરે છે, નોડ્સની સૂચિ, તેમની ભૂમિકાઓ, સ્લોટ વિતરણ વગેરે બતાવે છે. ક્લસ્ટર માહિતી અને ક્લસ્ટર સ્લોટ્સનો ઉપયોગ કરીને વધુ માહિતી મેળવી શકાય છે.
• ગાંઠો ઉમેરવા અને દૂર કરવામાં સક્ષમ થવા માટે તે સરસ રહેશે. આ હેતુ માટે ક્લસ્ટર મીટ અને ક્લસ્ટર ભૂલી કામગીરી છે. મહેરબાની કરીને નોંધ કરો કે ક્લસ્ટર ભૂલી દરેક નોડ પર લાગુ થવું જોઈએ, બંને માસ્ટર્સ અને પ્રતિકૃતિઓ. અને ક્લસ્ટર મીટ માત્ર એક નોડ પર બોલાવવાની જરૂર છે. આ તફાવત ચિંતાજનક હોઈ શકે છે, તેથી તમે તમારા ક્લસ્ટર સાથે લાઇવ જાઓ તે પહેલાં તેના વિશે શીખવું શ્રેષ્ઠ છે. નોડ ઉમેરવાનું યુદ્ધમાં સુરક્ષિત રીતે કરવામાં આવે છે અને ક્લસ્ટરની કામગીરીને કોઈપણ રીતે અસર કરતું નથી (જે તાર્કિક છે). જો તમે ક્લસ્ટરમાંથી નોડ દૂર કરવા જઈ રહ્યા છો, તો તમારે ખાતરી કરવી જોઈએ કે તેના પર કોઈ સ્લોટ બાકી નથી (અન્યથા તમે આ નોડ પરની બધી કીની ઍક્સેસ ગુમાવવાનું જોખમ લેશો). ઉપરાંત, ગુલામો ધરાવતા માસ્ટરને કાઢી નાખશો નહીં, અન્યથા નવા માસ્ટર માટે બિનજરૂરી મત આપવામાં આવશે. જો નોડ્સમાં હવે સ્લોટ્સ નથી, તો આ એક નાની સમસ્યા છે, પરંતુ જો આપણે પહેલા સ્લેવ્સને કાઢી નાખી શકીએ તો શા માટે અમને વધારાની પસંદગીઓની જરૂર છે.
• જો તમારે માસ્ટર અને સ્લેવની સ્થિતિને બળપૂર્વક સ્વેપ કરવાની જરૂર હોય, તો ક્લસ્ટર ફેલઓવર આદેશ કરશે. તેને યુદ્ધમાં બોલાવતી વખતે, તમારે સમજવાની જરૂર છે કે ઓપરેશન દરમિયાન માસ્ટર ઉપલબ્ધ રહેશે નહીં. સામાન્ય રીતે સ્વિચ એક સેકન્ડ કરતાં ઓછા સમયમાં થાય છે, પરંતુ તે અણુ નથી. તમે અપેક્ષા રાખી શકો છો કે આ સમય દરમિયાન માસ્ટરને કેટલીક વિનંતીઓ નિષ્ફળ જશે.
• ક્લસ્ટરમાંથી નોડને દૂર કરતા પહેલા, તેના પર કોઈ સ્લોટ્સ બાકી ન હોવા જોઈએ. ક્લસ્ટર રીશાર્ડ આદેશનો ઉપયોગ કરીને તેમને ફરીથી વિતરણ કરવું વધુ સારું છે. સ્લોટ્સ એક માસ્ટરથી બીજામાં ટ્રાન્સફર કરવામાં આવશે. સમગ્ર કામગીરીમાં ઘણી મિનિટો લાગી શકે છે, તે ટ્રાન્સફર થઈ રહેલા ડેટાના વોલ્યુમ પર આધાર રાખે છે, પરંતુ ટ્રાન્સફર પ્રક્રિયા સુરક્ષિત છે અને ક્લસ્ટરની કામગીરીને કોઈપણ રીતે અસર કરતી નથી. આમ, તમામ ડેટા લોડ હેઠળ અને તેની ઉપલબ્ધતા વિશે ચિંતા કર્યા વિના સીધા જ એક નોડમાંથી બીજામાં ટ્રાન્સફર કરી શકાય છે. જો કે, ત્યાં પણ સૂક્ષ્મતા છે. પ્રથમ, ડેટા ટ્રાન્સફર પ્રાપ્તકર્તા અને પ્રેષક ગાંઠો પર ચોક્કસ ભાર સાથે સંકળાયેલ છે. જો પ્રાપ્તકર્તા નોડ પહેલેથી જ પ્રોસેસર પર ભારે લોડ થયેલ છે, તો તમારે તેને નવો ડેટા પ્રાપ્ત કરવા સાથે લોડ કરવો જોઈએ નહીં. બીજું, જલદી મોકલનાર માસ્ટર પર એક પણ સ્લોટ બાકી નથી, તેના તમામ ગુલામો તરત જ તે માસ્ટર પાસે જશે કે જેને આ સ્લોટ ટ્રાન્સફર કરવામાં આવ્યા હતા. અને સમસ્યા એ છે કે આ બધા ગુલામો એક જ સમયે ડેટાને સિંક્રનાઇઝ કરવા માંગશે. અને જો તે સંપૂર્ણ સિંક્રનાઇઝેશનને બદલે આંશિક હોય તો તમે નસીબદાર હશો. આને ધ્યાનમાં લો અને સ્લોટ્સને સ્થાનાંતરિત કરવા અને ગુલામોને અક્ષમ/ટ્રાન્સફર કરવાની કામગીરીને જોડો. અથવા આશા છે કે તમારી પાસે સલામતીનો પૂરતો માર્જિન છે.
• તમારે શું કરવું જોઈએ જો, ટ્રાન્સફર દરમિયાન, તમને લાગે કે તમે તમારા સ્લોટ ક્યાંક ગુમાવી દીધા છે? હું આશા રાખું છું કે આ સમસ્યા તમને અસર કરશે નહીં, પરંતુ જો તે થાય, તો ક્લસ્ટર ફિક્સ ઑપરેશન છે. ઓછામાં ઓછું, તે રેન્ડમ ક્રમમાં નોડ્સમાં સ્લોટ્સને વેરવિખેર કરશે. હું ક્લસ્ટરમાંથી વિતરિત સ્લોટ્સ સાથે નોડને પહેલા દૂર કરીને તેની કામગીરી તપાસવાની ભલામણ કરું છું. બિન ફાળવેલ સ્લોટમાં ડેટા પહેલેથી જ અનુપલબ્ધ હોવાથી, આ સ્લોટ્સની ઉપલબ્ધતામાં સમસ્યાઓ વિશે ચિંતા કરવામાં મોડું થઈ ગયું છે. બદલામાં, ઓપરેશન વિતરિત સ્લોટ્સને અસર કરશે નહીં.
• અન્ય ઉપયોગી કામગીરી મોનિટર છે. તે તમને નોડ પર જતી વિનંતીઓની સંપૂર્ણ સૂચિ વાસ્તવિક સમયમાં જોવાની મંજૂરી આપે છે. તદુપરાંત, તમે તેને પકડી શકો છો અને શોધી શકો છો કે શું ત્યાં જરૂરી ટ્રાફિક છે.

તે માસ્ટર ફેલઓવર પ્રક્રિયાનો પણ ઉલ્લેખ કરવા યોગ્ય છે. ટૂંકમાં, તે અસ્તિત્વમાં છે, અને, મારા મતે, તે મહાન કાર્ય કરે છે. જો કે, એવું વિચારશો નહીં કે જો તમે માસ્ટર નોડ સાથે મશીન પર પાવર કોર્ડને અનપ્લગ કરો છો, તો રેડિસ તરત જ સ્વિચ થઈ જશે અને ક્લાયન્ટ્સ નુકસાનની નોંધ લેશે નહીં. મારી પ્રેક્ટિસમાં, સ્વિચિંગ થોડી સેકંડમાં થાય છે. આ સમય દરમિયાન, કેટલાક ડેટા અનુપલબ્ધ હશે: માસ્ટરની અનુપલબ્ધતા મળી આવે છે, નોડ્સ નવા માટે મત આપે છે, સ્લેવ્સ સ્વિચ કરવામાં આવે છે, ડેટા સિંક્રનાઇઝ થાય છે. આ યોજના કામ કરી રહી છે તેની ખાતરી કરવાનો શ્રેષ્ઠ માર્ગ એ છે કે સ્થાનિક કસરતો કરવી. તમારા લેપટોપ પર ક્લસ્ટરને વધારો, તેને ન્યૂનતમ લોડ આપો, ક્રેશનું અનુકરણ કરો (ઉદાહરણ તરીકે, પોર્ટ્સને અવરોધિત કરીને), અને સ્વિચિંગ ઝડપનું મૂલ્યાંકન કરો. મારા મતે, એક કે બે દિવસ આ રીતે રમ્યા પછી જ તમે ટેક્નોલોજીના સંચાલનમાં આત્મવિશ્વાસ મેળવી શકો છો. સારું, અથવા આશા છે કે સોફ્ટવેર કે જે ઇન્ટરનેટનો અડધો ઉપયોગ કરે છે તે કદાચ કામ કરે છે.

રૂપરેખાંકન

ઘણીવાર, ટૂલ સાથે કામ કરવાનું શરૂ કરવા માટે તમારે સૌપ્રથમ રૂપરેખાંકન કરવાની જરૂર હોય છે. અને જ્યારે બધું કામ કરે છે, ત્યારે તમે રૂપરેખાને સ્પર્શ કરવા પણ માંગતા નથી. સેટિંગ્સ પર પાછા જવા માટે અને તેમને કાળજીપૂર્વક પસાર કરવા માટે તમારી જાતને દબાણ કરવા માટે થોડો પ્રયાસ લે છે. મારી યાદમાં, રૂપરેખાંકનમાં બેદરકારીને કારણે અમારી પાસે ઓછામાં ઓછી બે ગંભીર નિષ્ફળતાઓ હતી. નીચેના મુદ્દાઓ પર વિશેષ ધ્યાન આપો:

• સમયસમાપ્તિ 0
  સમય કે જેના પછી નિષ્ક્રિય જોડાણો બંધ થાય છે (સેકંડમાં). 0 - બંધ કરશો નહીં
  અમારી દરેક લાઇબ્રેરી યોગ્ય રીતે જોડાણો બંધ કરવામાં સક્ષમ ન હતી. આ સેટિંગને અક્ષમ કરીને, અમે ક્લાયંટની સંખ્યાની મર્યાદા સુધી પહોંચવાનું જોખમ લઈએ છીએ. બીજી બાજુ, જો આવી કોઈ સમસ્યા હોય, તો ખોવાયેલા કનેક્શન્સનું સ્વચાલિત સમાપ્તિ તેને માસ્ક કરશે, અને અમે કદાચ ધ્યાન આપીશું નહીં. વધુમાં, પર્સિસ્ટ કનેક્શન્સનો ઉપયોગ કરતી વખતે તમારે આ સેટિંગને સક્ષમ કરવી જોઈએ નહીં.
• xy સાચવો અને ફક્ત હા
  RDB સ્નેપશોટ સાચવી રહ્યું છે.
  અમે નીચે વિગતવાર RDB/AOF મુદ્દાઓની ચર્ચા કરીશું.
• સ્ટોપ-રાઇટ્સ-ઓન-બીજીસેવ-એરર ના અને સ્લેવ-સર્વ-વાસી-ડેટા હા
  જો સક્ષમ હોય, જો RDB સ્નેપશોટ તૂટી જાય, તો માસ્ટર ફેરફારની વિનંતીઓ સ્વીકારવાનું બંધ કરશે. જો માસ્ટર સાથેનું જોડાણ ખોવાઈ ગયું હોય, તો ગુલામ વિનંતીઓનો જવાબ આપવાનું ચાલુ રાખી શકે છે (હા). અથવા પ્રતિસાદ આપવાનું બંધ કરશે (ના)
  રેડિસ કોળામાં ફેરવાય છે તે પરિસ્થિતિથી અમે ખુશ નથી.
• repl-ping-slave-period 5
  આ સમયગાળા પછી, અમે ચિંતા કરવાનું શરૂ કરીશું કે માસ્ટર તૂટી ગયો છે અને તે નિષ્ફળતા પ્રક્રિયા હાથ ધરવાનો સમય છે.
  તમારે ખોટા સકારાત્મક અને ફેલઓવરને ટ્રિગર કરવા વચ્ચે મેન્યુઅલી સંતુલન શોધવું પડશે. અમારી પ્રેક્ટિસમાં આ 5 સેકન્ડ છે.
• repl-backlog-size 1024mb અને epl-backlog-ttl 0
  નિષ્ફળ પ્રતિકૃતિ માટે આપણે બફરમાં આટલો બરોબર ડેટા સ્ટોર કરી શકીએ છીએ. જો બફર સમાપ્ત થઈ જાય, તો તમારે સંપૂર્ણપણે સિંક્રનાઇઝ કરવું પડશે.
  પ્રેક્ટિસ સૂચવે છે કે ઉચ્ચ મૂલ્ય સેટ કરવું વધુ સારું છે. પુષ્કળ કારણો છે કે શા માટે પ્રતિકૃતિ પાછળ રહેવાનું શરૂ કરી શકે છે. જો તે પાછળ રહે છે, તો સંભવતઃ તમારો માસ્ટર પહેલેથી જ સામનો કરવા માટે સંઘર્ષ કરી રહ્યો છે, અને સંપૂર્ણ સિંક્રનાઇઝેશન એ છેલ્લું સ્ટ્રો હશે.
• મહત્તમ ક્લાયન્ટ્સ 10000
  એક વખતના ગ્રાહકોની મહત્તમ સંખ્યા.
  અમારા અનુભવમાં, ઉચ્ચ મૂલ્ય સેટ કરવું વધુ સારું છે. Redis 10k કનેક્શનને બરાબર હેન્ડલ કરે છે. ફક્ત ખાતરી કરો કે સિસ્ટમ પર પૂરતી સોકેટ્સ છે.
• maxmemory-policy volatile-ttl
  જ્યારે ઉપલબ્ધ મેમરી મર્યાદા પહોંચી જાય ત્યારે કીઓ કાઢી નાખવામાં આવે છે તે નિયમ.
  અહીં શું મહત્વનું છે તે પોતે નિયમ નથી, પરંતુ આ કેવી રીતે થશે તેની સમજ છે. જ્યારે મેમરી મર્યાદા પહોંચી જાય ત્યારે સામાન્ય રીતે કામ કરવાની ક્ષમતા માટે રેડિસની પ્રશંસા કરી શકાય છે.

RDB અને AOF સમસ્યાઓ

જોકે Redis પોતે RAM માં બધી માહિતી સંગ્રહિત કરે છે, ડિસ્ક પર ડેટા સાચવવા માટેની એક પદ્ધતિ પણ છે. વધુ સ્પષ્ટ રીતે, ત્રણ મિકેનિઝમ્સ:

• RDB-સ્નેપશોટ - તમામ ડેટાનો સંપૂર્ણ સ્નેપશોટ. સેવ XY રૂપરેખાંકનનો ઉપયોગ કરીને સેટ કરો અને "જો ઓછામાં ઓછી Y કી બદલાઈ ગઈ હોય તો દર X સેકન્ડે તમામ ડેટાનો સંપૂર્ણ સ્નેપશોટ સાચવો."
• ફક્ત-એન્ડ-ફાઇલ - ઑપરેશન્સની સૂચિ જે ક્રમમાં તેઓ કરવામાં આવે છે. ફાઇલમાં દર X સેકન્ડે અથવા દરેક Y ઑપરેશનમાં નવા ઇનકમિંગ ઑપરેશન્સ ઉમેરે છે.
• RDB અને AOF એ અગાઉના બેનું સંયોજન છે.

બધી પદ્ધતિઓમાં તેમના ફાયદા અને ગેરફાયદા છે, હું તે બધાને સૂચિબદ્ધ કરીશ નહીં, હું ફક્ત એવા મુદ્દાઓ પર ધ્યાન દોરીશ જે, મારા મતે, સ્પષ્ટ નથી.

પ્રથમ, RDB સ્નેપશોટ સાચવવા માટે ફોર્કને કૉલ કરવાની જરૂર છે. જો ત્યાં ઘણો ડેટા હોય, તો આ તમામ Redisને થોડા મિલીસેકન્ડથી સેકન્ડના સમયગાળા માટે અટકી શકે છે. વધુમાં, સિસ્ટમને આવા સ્નેપશોટ માટે મેમરી ફાળવવાની જરૂર છે, જે લોજિકલ મશીન પર RAM નો ડબલ સપ્લાય રાખવાની જરૂરિયાત તરફ દોરી જાય છે: જો Redis માટે 8 GB ફાળવવામાં આવે, તો વર્ચ્યુઅલ મશીન પર 16 GB ઉપલબ્ધ હોવું જોઈએ. તે

બીજું, આંશિક સિંક્રનાઇઝેશન સાથે સમસ્યાઓ છે. AOF મોડમાં, જ્યારે સ્લેવ ફરીથી કનેક્ટ થાય છે, ત્યારે આંશિક સિંક્રનાઇઝેશનને બદલે, સંપૂર્ણ સિંક્રનાઇઝેશન કરી શકાય છે. આવું કેમ થાય છે, હું સમજી શક્યો નહીં. પરંતુ આ યાદ રાખવું યોગ્ય છે.

આ બે મુદ્દાઓ પહેલાથી જ અમને વિચારે છે કે શું અમને ડિસ્ક પર આ ડેટાની ખરેખર જરૂર છે જો બધું પહેલેથી જ ગુલામો દ્વારા ડુપ્લિકેટ કરવામાં આવ્યું હોય. જો બધા ગુલામો નિષ્ફળ જાય તો જ ડેટા ખોવાઈ શકે છે, અને આ "ડીસીમાં આગ" સ્તરની સમસ્યા છે. સમાધાન તરીકે, તમે ફક્ત ગુલામો પર જ ડેટા બચાવવાનો પ્રસ્તાવ મૂકી શકો છો, પરંતુ આ કિસ્સામાં તમારે ખાતરી કરવાની જરૂર છે કે આ ગુલામો આપત્તિ પુનઃપ્રાપ્તિ દરમિયાન ક્યારેય માસ્ટર નહીં બને (આ માટે તેમની રૂપરેખામાં ગુલામ અગ્રતા સેટિંગ છે). આપણા માટે, દરેક ચોક્કસ કિસ્સામાં આપણે ડિસ્ક પર ડેટા સાચવવો જરૂરી છે કે કેમ તે વિશે વિચારીએ છીએ, અને મોટાભાગે જવાબ "ના" છે.

નિષ્કર્ષ

નિષ્કર્ષમાં, હું આશા રાખું છું કે હું તે લોકો માટે રીડીસ-ક્લસ્ટર કેવી રીતે કાર્ય કરે છે તે વિશે સામાન્ય વિચાર આપવા સક્ષમ હતો, અને જેઓ તેનો ઉપયોગ કરી રહ્યાં છે તેમના માટે કેટલાક બિન-સ્પષ્ટ મુદ્દાઓ તરફ પણ ધ્યાન દોર્યું. ઘણા સમય સુધી.
તમારા સમય માટે આભાર અને, હંમેશની જેમ, વિષય પરની ટિપ્પણીઓનું સ્વાગત છે.

સોર્સ: www.habr.com