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

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

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

અમે જોશું કે સુસંગતતા અને પ્રાપ્યતા સ્પેક્ટ્રમના વિરુદ્ધ છેડે છે, અને તમારે કઈ રીતને ઑપ્ટિમાઇઝ કરવી તે પસંદ કરવાની જરૂર છે. સારા સમાચાર એ છે કે RabbitMQ સાથે આ પસંદગી શક્ય છે. સંતુલનને વધુ સુસંગતતા અથવા વધુ સુલભતા તરફ ખસેડવા માટે તમારી પાસે આ પ્રકારના "નર્ડી" લિવર છે.

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

સિંગલ નોડ રેઝિલિયન્સ પ્રિમિટિવ્સ

સ્થિતિસ્થાપક કતાર/રાઉટીંગ

RabbitMQ માં બે પ્રકારની કતાર છે: ટકાઉ અને બિન-ટકાઉ. બધી કતાર Mnesia ડેટાબેઝમાં સાચવેલ છે. નોડ સ્ટાર્ટઅપ વખતે ટકાઉ કતારોની ફરીથી જાહેરાત કરવામાં આવે છે અને આ રીતે પુનઃપ્રારંભ, સિસ્ટમ ક્રેશ અથવા સર્વર ક્રેશ (જ્યાં સુધી ડેટા ચાલુ રહે ત્યાં સુધી) બચી જાય છે. આનો અર્થ એ છે કે જ્યાં સુધી તમે રૂટીંગ (એક્સચેન્જ) અને કતારને સ્થિતિસ્થાપક હોવાનું જાહેર કરશો, ત્યાં સુધી કતાર/રાઉટીંગ ઈન્ફ્રાસ્ટ્રક્ચર પાછું ઓનલાઈન આવશે.

જ્યારે નોડ પુનઃપ્રારંભ થાય ત્યારે અસ્થિર કતાર અને રૂટીંગ દૂર કરવામાં આવે છે.

સતત સંદેશા

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

ચોખા. 1. ટકાઉપણું મેટ્રિક્સ

કતાર મિરરિંગ સાથે ક્લસ્ટરિંગ

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

કતાર મિરરિંગ:

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

ચોખા. 2. કતાર મિરરિંગ

મિરરિંગ યોગ્ય નીતિ દ્વારા સેટ કરવામાં આવે છે. તેમાં તમે પ્રતિકૃતિ ગુણાંક અને તે ગાંઠો પણ પસંદ કરી શકો છો કે જેના પર કતાર હોવી જોઈએ. ઉદાહરણો:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (એક માસ્ટર અને એક અરીસો)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

પ્રકાશક પુષ્ટિ

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

ફેલઓવર કતાર

જ્યારે બ્રોકર છોડે છે અથવા ક્રેશ થાય છે, ત્યારે તે નોડ પરના તમામ કતારના નેતાઓ (માસ્ટર્સ) તેની સાથે ક્રેશ થાય છે. પછી ક્લસ્ટર દરેક માસ્ટરના સૌથી જૂના અરીસાને પસંદ કરે છે અને તેને નવા માસ્ટર તરીકે પ્રમોટ કરે છે.

ચોખા. 3. બહુવિધ પ્રતિબિંબિત કતાર અને તેમની નીતિઓ

બ્રોકર 3 નીચે જાય છે. નોંધ કરો કે બ્રોકર 2 પર કતાર C મિરરને માસ્ટર તરીકે બઢતી આપવામાં આવી રહી છે. એ પણ નોંધ કરો કે બ્રોકર 1 પર કતાર C માટે એક નવો અરીસો બનાવવામાં આવ્યો છે. RabbitMQ હંમેશા તમારી નીતિઓમાં ઉલ્લેખિત પ્રતિકૃતિ પરિબળને જાળવવાનો પ્રયાસ કરે છે.

ચોખા. 4. બ્રોકર 3 નિષ્ફળ જાય છે, જેના કારણે કતાર C નિષ્ફળ થાય છે

આગામી બ્રોકર 1 ઘટે છે! અમારી પાસે માત્ર એક બ્રોકર બાકી છે. કતાર B મિરરને માસ્ટર તરીકે બઢતી આપવામાં આવે છે.

Рис. .

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

આ કિસ્સામાં, બ્રોકર 1 ની ખોટ સંપૂર્ણ હતી, જેમ કે ડેટા હતો, તેથી અમીરર વિનાની કતાર B સંપૂર્ણપણે ખોવાઈ ગઈ હતી.

ચોખા. 6. બ્રોકર 1 સેવામાં પાછો ફરે છે

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

ચોખા. 7. બ્રોકર 3 સેવામાં પરત ફરે છે. એક નોડ પર બધી મુખ્ય કતારો!

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

Синхронизация

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

આ સિંક્રનાઇઝેશન આપમેળે અથવા મેન્યુઅલી કરવામાં આવે છે અને કતાર નીતિનો ઉપયોગ કરીને સંચાલિત થાય છે. ચાલો એક ઉદાહરણ જોઈએ.

અમારી પાસે બે અરીસાવાળી કતાર છે. કતાર A આપમેળે સમન્વયિત થાય છે, અને કતાર B મેન્યુઅલી સમન્વયિત થાય છે. બંને કતારોમાં દસ સંદેશા છે.

ચોખા. 8. વિવિધ સિંક્રનાઇઝેશન મોડ્સ સાથે બે કતાર

હવે આપણે બ્રોકર 3 ગુમાવી રહ્યા છીએ.

ચોખા. 9. બ્રોકર 3 પડ્યો

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

ચોખા. 10. કતાર Aનો નવો અરીસો હાલના તમામ સંદેશાઓ પ્રાપ્ત કરે છે, પરંતુ કતાર Bનો નવો અરીસો મળતો નથી.

બંને કતારોમાં વધુ દસ સંદેશાઓ આવે છે. બ્રોકર 2 પછી ક્રેશ થાય છે અને કતાર A સૌથી જૂના અરીસા પર પાછું ફરે છે, જે બ્રોકર 1 પર છે. જ્યારે તે નિષ્ફળ જાય છે ત્યારે કોઈ ડેટા નુકશાન થતું નથી. કતાર B માં, માસ્ટરમાં વીસ સંદેશાઓ છે અને અરીસામાં માત્ર દસ છે કારણ કે આ કતાર મૂળ દસ સંદેશાઓની નકલ કરતી નથી.

ચોખા. 11. કતાર A સંદેશાઓ ગુમાવ્યા વિના બ્રોકર 1 પર પાછા ફરે છે

બંને કતારોમાં વધુ દસ સંદેશાઓ આવે છે. હવે બ્રોકર 1 ક્રેશ થાય છે. કતાર A સંદેશાઓ ગુમાવ્યા વિના સરળતાથી અરીસા પર સ્વિચ કરે છે. જો કે, કતાર Bમાં સમસ્યા આવી રહી છે. આ બિંદુએ આપણે ઉપલબ્ધતા અથવા સુસંગતતાને ઑપ્ટિમાઇઝ કરી શકીએ છીએ.

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

ચોખા. 12. સંદેશાઓ ગુમાવ્યા વિના કતાર A બ્રોકર 3 પર પાછી લાવવામાં આવે છે. દસ સંદેશાઓ ખોવાઈ જવા સાથે કતાર B બ્રોકર 3 પર પાછા ફરે છે

અમે પણ ઇન્સ્ટોલ કરી શકીએ છીએ ha-promote-on-failure અર્થમાં when-synced. આ કિસ્સામાં, અરીસા પર પાછા ફરવાને બદલે, બ્રોકર 1 તેના ડેટા સાથે ઓનલાઈન મોડ પર પાછા ફરે ત્યાં સુધી કતાર રાહ જોશે. તે પાછું આવે તે પછી, મુખ્ય કતાર કોઈપણ ડેટા નુકશાન વિના બ્રોકર 1 પર પાછી આવે છે. ડેટા સુરક્ષા માટે ઉપલબ્ધતાનું બલિદાન આપવામાં આવે છે. પરંતુ આ એક જોખમી મોડ છે જે સંપૂર્ણ ડેટા નુકશાન તરફ પણ દોરી શકે છે, જેને અમે ટૂંક સમયમાં જોઈશું.

ચોખા. 13. બ્રોકર 1 ગુમાવ્યા પછી કતાર B અનુપલબ્ધ રહે છે

તમે પૂછી શકો છો, "શું ક્યારેય સ્વચાલિત સિંક્રનાઇઝેશનનો ઉપયોગ ન કરવો તે વધુ સારું છે?" જવાબ એ છે કે સિંક્રનાઇઝેશન એ અવરોધિત કામગીરી છે. સિંક્રનાઇઝેશન દરમિયાન, મુખ્ય કતાર કોઈપણ વાંચવા અથવા લખવાની ક્રિયાઓ કરી શકતી નથી!

ચાલો એક ઉદાહરણ જોઈએ. હવે અમારી પાસે ઘણી લાંબી કતારો છે. તેઓ આવા કદમાં કેવી રીતે વૃદ્ધિ કરી શકે છે? ઘણા કારણોસર:

• કતારોનો સક્રિય રીતે ઉપયોગ થતો નથી
• આ હાઇ-સ્પીડ કતાર છે, અને અત્યારે ગ્રાહકો ધીમા છે
• તે હાઇ-સ્પીડ કતારો છે, ત્યાં એક ખામી છે અને ઉપભોક્તાઓ પકડી રહ્યા છે

ચોખા. 14. વિવિધ સિંક્રોનાઇઝેશન મોડ્સ સાથે બે મોટી કતાર

હવે બ્રોકર 3 ઘટે છે.

ચોખા. 15. બ્રોકર 3 ફોલ્સ, દરેક કતારમાં એક માસ્ટર અને મિરર છોડીને

બ્રોકર 3 ઓનલાઈન પાછો આવે છે અને નવા મિરર્સ બનાવવામાં આવે છે. મુખ્ય કતાર A વર્તમાન સંદેશાઓને નવા અરીસામાં નકલ કરવાનું શરૂ કરે છે, અને આ સમય દરમિયાન કતાર અનુપલબ્ધ છે. ડેટાની નકલ કરવામાં બે કલાક લાગે છે, પરિણામે આ કતાર માટે બે કલાકનો ડાઉનટાઇમ મળે છે!

જો કે, કતાર B સમગ્ર સમયગાળા દરમિયાન ઉપલબ્ધ રહે છે. તેણીએ સુલભતા માટે કેટલીક નિરર્થકતાનું બલિદાન આપ્યું.

ચોખા. 16. સિંક્રનાઇઝેશન દરમિયાન કતાર અનુપલબ્ધ રહે છે

બે કલાક પછી, કતાર A પણ ઉપલબ્ધ થાય છે અને ફરીથી વાંચન અને લખવાનું સ્વીકારવાનું શરૂ કરી શકે છે.

અપડેટ્સ

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

• always= સિંક્રનાઇઝ્ડ મિરર્સ પર સંક્રમણ સક્ષમ છે
• when-synced= માત્ર સિંક્રનાઇઝ્ડ મિરરમાં સંક્રમણ, અન્યથા કતાર વાંચી ન શકાય તેવી અને લખી ન શકાય તેવી બની જાય છે. બ્રોકર પાછા ફરે કે તરત જ કતાર સેવામાં પાછી આવે છે

એક યા બીજી રીતે, મોટી કતારો સાથે તમારે ડેટા નુકશાન અને અનુપલબ્ધતા વચ્ચે પસંદગી કરવી પડશે.

જ્યારે ઉપલબ્ધતા ડેટા સુરક્ષામાં સુધારો કરે છે

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

અહીં તમારે નીચેનાને ધ્યાનમાં લેવાની જરૂર છે:

• શું પ્રકાશક ફક્ત એક ભૂલ પરત કરી શકે છે અને અપસ્ટ્રીમ સેવા અથવા વપરાશકર્તાને પછીથી ફરી પ્રયાસ કરી શકે છે?
• શું પ્રકાશક પછીથી ફરી પ્રયાસ કરવા માટે સ્થાનિક રીતે અથવા ડેટાબેઝમાં સંદેશ સાચવી શકે છે?

જો પ્રકાશક માત્ર સંદેશને જ કાઢી શકે છે, તો હકીકતમાં, ઍક્સેસિબિલિટીમાં સુધારો કરવાથી ડેટા સુરક્ષામાં પણ સુધારો થાય છે.

આમ, સંતુલન શોધવું આવશ્યક છે, અને ઉકેલ ચોક્કસ પરિસ્થિતિ પર આધાર રાખે છે.

ha-promote-on-failure=when-sync સાથે સમસ્યાઓ

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

પરંતુ (અને આ એક મોટું છે પરંતુ) જો બ્રોકરે તેનો ડેટા ગુમાવ્યો હોય, તો અમારી પાસે એક મોટી સમસ્યા છે: કતાર ખોવાઈ ગઈ છે! બધો ડેટા ગયો! જો તમારી પાસે અરીસાઓ હોય જે મોટે ભાગે મુખ્ય કતાર સાથે પકડે છે, તો તે અરીસાઓ પણ કાઢી નાખવામાં આવે છે.

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

તેથી, મેન્યુઅલ સિંક્રનાઇઝેશન (અને સિંક્રનાઇઝ કરવામાં નિષ્ફળતા) સાથે સંયોજનમાં ha-promote-on-failure=when-synced, મારા મતે, તદ્દન જોખમી. દસ્તાવેજો કહે છે કે આ વિકલ્પ ડેટા સુરક્ષા માટે અસ્તિત્વમાં છે, પરંતુ તે બેધારી છરી છે.

માસ્ટર રિબેલેન્સિંગ

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

પુનઃસંતુલિત માસ્ટર્સ બે કારણોસર સમસ્યારૂપ હોઈ શકે છે:

• પુનઃસંતુલન કરવા માટે કોઈ સારા સાધનો નથી
• કતાર સિંક્રનાઇઝેશન

પુનઃસંતુલન માટે ત્રીજો પક્ષ છે માં નાખો, જે સત્તાવાર રીતે સમર્થિત નથી. RabbitMQ મેન્યુઅલમાં તૃતીય પક્ષ પ્લગઈન્સ વિશે જણાવ્યું હતું: "પ્લગઇન કેટલાક વધારાના રૂપરેખાંકન અને રિપોર્ટિંગ સાધનો પ્રદાન કરે છે, પરંતુ RabbitMQ ટીમ દ્વારા સમર્થિત અથવા ચકાસાયેલ નથી. તમારા પોતાના જોખમે ઉપયોગ કરો."

HA નીતિઓ દ્વારા મુખ્ય કતારને ખસેડવાની બીજી યુક્તિ છે. મેન્યુઅલ ઉલ્લેખ કરે છે સ્ક્રિપ્ટ આ માટે. તે આની જેમ કાર્ય કરે છે:

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

નુકસાન એ છે કે જો તમારી પાસે મોટી કતારો હોય અથવા સખત રીડન્ડન્સી જરૂરિયાતો હોય તો આ અભિગમ કામ કરી શકશે નહીં.

હવે ચાલો જોઈએ કે RabbitMQ ક્લસ્ટર્સ નેટવર્ક પાર્ટીશનો સાથે કેવી રીતે કામ કરે છે.

કનેક્ટિવિટી ગુમાવવી

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

RabbitMQ સાથે અમારી પાસે બે મુખ્ય વિકલ્પો છે:

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

પરંતુ તાર્કિક અલગતા શું છે? આ ત્યારે થાય છે જ્યારે નેટવર્ક કનેક્શન ગુમાવવાને કારણે ક્લસ્ટર બે ભાગમાં વિભાજિત થાય છે. દરેક બાજુએ, અરીસાઓને એક માસ્ટર તરીકે બઢતી આપવામાં આવે છે, જેથી અંતે વળાંક દીઠ ઘણા માસ્ટર હોય.

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

જો પ્રકાશકો બંને માસ્ટર્સને ડેટા મોકલે છે, તો અમે કતારની બે અલગ અલગ નકલો સાથે સમાપ્ત કરીએ છીએ.

RabbitMQ ના વિવિધ મોડ્સ ઉપલબ્ધતા અથવા સુસંગતતા પ્રદાન કરે છે.

અવગણો મોડ (ડિફૉલ્ટ)

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

ચોખા. 18. ત્રણ પ્રકાશકો ત્રણ બ્રોકર્સ સાથે સંકળાયેલા છે. આંતરિક રીતે, ક્લસ્ટર તમામ વિનંતીઓને બ્રોકર 2 પરની મુખ્ય કતારમાં લઈ જાય છે.

હવે આપણે બ્રોકર 3 ને ગુમાવી રહ્યા છીએ. તે જુએ છે કે અન્ય બ્રોકર્સ પડી ગયા છે અને તેના અરીસાને માસ્ટર તરફ પ્રમોટ કરે છે. આ રીતે તાર્કિક વિભાજન થાય છે.

ચોખા. 19. લોજિકલ ડિવિઝન (સ્પ્લિટ-બ્રેઈન). રેકોર્ડ્સ બે મુખ્ય કતારોમાં જાય છે, અને બે નકલો અલગ પડે છે.

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

ચોખા. 20. એડમિનિસ્ટ્રેટર બ્રોકર 3 ને અક્ષમ કરે છે.

ચોખા. 21. એડમિનિસ્ટ્રેટર બ્રોકર 3 શરૂ કરે છે અને તે ક્લસ્ટરમાં જોડાય છે, ત્યાં બાકી રહેલા તમામ સંદેશાઓ ગુમાવે છે.

કનેક્ટિવિટી ખોવાઈ જવા દરમિયાન અને તેની પુનઃસ્થાપન પછી, ક્લસ્ટર અને આ કતાર વાંચવા અને લખવા માટે ઉપલબ્ધ હતી.

ઓટોહીલ મોડ

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

લઘુમતી મોડને થોભાવો

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

ચોખા. 22. ત્રણ પ્રકાશકો ત્રણ બ્રોકર્સ સાથે સંકળાયેલા છે. આંતરિક રીતે, ક્લસ્ટર તમામ વિનંતીઓને બ્રોકર 2 પરની મુખ્ય કતારમાં લઈ જાય છે.

બ્રોકર્સ 1 અને 2 પછી બ્રોકર 3 થી વિભાજિત થાય છે. તેમના મિરરને માસ્ટરમાં પ્રમોટ કરવાને બદલે, બ્રોકર 3 સસ્પેન્ડ કરે છે અને અનુપલબ્ધ બને છે.

ચોખા. 23. બ્રોકર 3 થોભાવે છે, બધા ક્લાયન્ટ્સને ડિસ્કનેક્ટ કરે છે અને કનેક્શન વિનંતીઓને નકારી કાઢે છે.

એકવાર કનેક્ટિવિટી પુનઃસ્થાપિત થઈ જાય, તે ક્લસ્ટર પર પાછી આવે છે.

ચાલો બીજું ઉદાહરણ જોઈએ જ્યાં મુખ્ય કતાર બ્રોકર 3 પર છે.

ચોખા. 24. બ્રોકર 3 પર મુખ્ય કતાર.

પછી કનેક્ટિવિટીની સમાન ખોટ થાય છે. બ્રોકર 3 થોભો કારણ કે તે નાની બાજુ છે. બીજી બાજુ, નોડ્સ જુએ છે કે બ્રોકર 3 બંધ થઈ ગયો છે, તેથી બ્રોકર્સ 1 અને 2 ના જૂના મિરરને માસ્ટર તરીકે બઢતી આપવામાં આવે છે.

ચોખા. 25. જો બ્રોકર 2 અનુપલબ્ધ હોય તો બ્રોકર 3 માં સંક્રમણ.

જ્યારે કનેક્ટિવિટી પુનઃસ્થાપિત થશે, ત્યારે બ્રોકર 3 ક્લસ્ટરમાં જોડાશે.

ચોખા. 26. ક્લસ્ટર સામાન્ય કામગીરીમાં પાછું આવ્યું છે.

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

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

ગ્રાહક જોડાણની ખાતરી કરવી

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

અમારા વિકલ્પો:

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

તારણો

RabbitMQ ક્લસ્ટરિંગના તેના ફાયદા અને ગેરફાયદા છે. સૌથી ગંભીર ગેરફાયદા એ છે કે:

• જ્યારે ક્લસ્ટરમાં જોડાય છે, ત્યારે નોડ્સ તેમનો ડેટા કાઢી નાખે છે;
• સિંક્રનાઇઝેશનને અવરોધિત કરવાથી કતાર અનુપલબ્ધ થાય છે.

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

• અવિશ્વસનીય નેટવર્ક.
• અવિશ્વસનીય સ્ટોરેજ.
• ખૂબ લાંબી કતારો.

જ્યારે ઉચ્ચ ઉપલબ્ધતા સેટિંગ્સની વાત આવે છે, ત્યારે નીચેનાનો વિચાર કરો:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (અથવા autoheal)
• સતત સંદેશાઓ
• જ્યારે કેટલાક નોડ નિષ્ફળ જાય ત્યારે ક્લાયન્ટ સક્રિય નોડ સાથે કનેક્ટ થાય તેની ખાતરી કરો

સુસંગતતા (ડેટા સુરક્ષા) માટે, નીચેની સેટિંગ્સ ધ્યાનમાં લો:

• પ્રકાશક કન્ફર્મ કરે છે અને ઉપભોક્તા તરફથી મેન્યુઅલ સ્વીકૃતિઓ
• ha-promote-on-failure=when-synced, જો પ્રકાશકો પછીથી ફરી પ્રયાસ કરી શકે અને જો તમારી પાસે ખૂબ જ વિશ્વસનીય સ્ટોરેજ હોય ​​તો! અન્યથા મૂકો =always.
• ha-sync-mode=automatic (પરંતુ મોટી નિષ્ક્રિય કતાર માટે મેન્યુઅલ મોડની જરૂર પડી શકે છે; એ પણ ધ્યાનમાં લો કે શું અનુપલબ્ધતા સંદેશાઓ ગુમાવવાનું કારણ બનશે)
• લઘુમતી મોડને થોભાવો
• સતત સંદેશાઓ

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

જો હું બીજું કંઈ ચૂકી ગયો હોય, તો કૃપા કરીને મને જણાવો.

મારા પણ જુઓ પોસ્ટ, જ્યાં હું આ લેખમાં વર્ણવેલ સંદેશાના નુકશાનની કેટલીક પરિસ્થિતિઓને ચકાસવા માટે Docker અને Blockade નો ઉપયોગ કરીને RabbitMQ ક્લસ્ટર પર પાયમાલ કરું છું.

શ્રેણીમાં અગાઉના લેખો:
નંબર 1 - habr.com/ru/company/itsumma/blog/416629
નંબર 2 - habr.com/ru/company/itsumma/blog/418389
નંબર 3 - habr.com/ru/company/itsumma/blog/437446

સોર્સ: www.habr.com