В છેલ્લા લેખ અમે ખામી સહિષ્ણુતા અને ઉચ્ચ ઉપલબ્ધતા માટે RabbitMQ ક્લસ્ટરિંગ તરફ જોયું. હવે ચાલો અપાચે કાફકામાં ઊંડા ઉતરીએ.

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

ચોખા. 1. ત્રણ દલાલોમાં ચાર વિભાગો વહેંચવામાં આવ્યા છે

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

પાર્ટીશન નિષ્ફળતા

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

બ્રોકર 3 નેટવર્ક છોડી દે છે, અને બ્રોકર 2 પર વિભાગ 2 માટે એક નવો નેતા ચૂંટાય છે.

ચોખા. 2. બ્રોકર 3નું અવસાન થયું અને બ્રોકર 2 પર તેના અનુયાયીને પાર્ટીશન 2 ના નવા નેતા તરીકે ચૂંટવામાં આવ્યા

પછી બ્રોકર 1 છોડી દે છે અને વિભાગ 1 પણ તેના નેતાને ગુમાવે છે, જેની ભૂમિકા બ્રોકર 2 ને પસાર થાય છે.

ચોખા. 3. એક બ્રોકર બાકી છે. બધા નેતાઓ શૂન્ય રીડન્ડન્સી સાથે એક બ્રોકર પર છે

જ્યારે બ્રોકર 1 ઓનલાઈન પાછું આવે છે, ત્યારે તે ચાર અનુયાયીઓ ઉમેરે છે, જે દરેક પાર્ટીશનને કેટલીક રીડન્ડન્સી પ્રદાન કરે છે. પરંતુ તમામ નેતાઓ હજુ પણ દલાલ 2 પર જ રહ્યા હતા.

ચોખા. 4. નેતાઓ બ્રોકર 2 પર રહે છે

જ્યારે બ્રોકર 3 આવે છે, અમે પાર્ટીશન દીઠ ત્રણ પ્રતિકૃતિઓ પર પાછા આવીએ છીએ. પરંતુ તમામ નેતાઓ હજુ પણ દલાલ 2 પર છે.

ચોખા. 5. દલાલોની પુનઃસ્થાપના 1 અને 3 પછી નેતાઓનું અસંતુલિત પ્લેસમેન્ટ

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

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

આને ઠીક કરવા માટે, કાફકા બે વિકલ્પો પ્રદાન કરે છે:

• વિકલ્પ auto.leader.rebalance.enable=true કંટ્રોલર નોડને આપમેળે નેતાઓને પસંદગીની પ્રતિકૃતિઓ પર ફરીથી સોંપવાની મંજૂરી આપે છે અને ત્યાંથી સમાન વિતરણ પુનઃસ્થાપિત કરે છે.
• એડમિનિસ્ટ્રેટર સ્ક્રિપ્ટ ચલાવી શકે છે kafka-preferred-replica-election.sh મેન્યુઅલ ફરીથી સોંપણી માટે.

ચોખા. 6. પુનઃસંતુલન પછી પ્રતિકૃતિઓ

આ નિષ્ફળતાનું એક સરળ સંસ્કરણ હતું, પરંતુ વાસ્તવિકતા વધુ જટિલ છે, જો કે અહીં કંઈપણ જટિલ નથી. તે બધું સિંક્રનાઇઝ્ડ પ્રતિકૃતિઓ (ઇન-સિંક પ્રતિકૃતિઓ, ISR) પર આવે છે.

સિંક્રનાઇઝ્ડ પ્રતિકૃતિઓ (ISR)

ISR એ પાર્ટીશનની પ્રતિકૃતિઓનો સમૂહ છે જેને "સિંક્રોનાઇઝ્ડ" (ઇન-સિંક) ગણવામાં આવે છે. ત્યાં એક નેતા છે, પરંતુ અનુયાયીઓ ન હોઈ શકે. અનુયાયીને સમન્વયિત ગણવામાં આવે છે જો તેણે અંતરાલ સમાપ્ત થાય તે પહેલાં તમામ નેતાના સંદેશાઓની ચોક્કસ નકલો બનાવી હોય. replica.lag.time.max.ms.

અનુયાયીને ISR સેટમાંથી દૂર કરવામાં આવે છે જો તે:

• અંતરાલ માટે પસંદ કરવાની વિનંતી કરી નથી replica.lag.time.max.ms (મૃત માનવામાં આવે છે)
• અંતરાલ દરમિયાન અપડેટ કરવાનું મેનેજ કર્યું નથી replica.lag.time.max.ms (ધીમી ગણવામાં આવે છે)

અનુયાયીઓ અંતરાલમાં નમૂનાની વિનંતીઓ કરે છે replica.fetch.wait.max.ms, જે ડિફોલ્ટ 500ms છે.

ISR ના હેતુને સ્પષ્ટ રીતે સમજાવવા માટે, અમારે નિર્માતા તરફથી પુષ્ટિકરણ અને કેટલાક નિષ્ફળતાના દૃશ્યો જોવાની જરૂર છે. જ્યારે બ્રોકર પુષ્ટિ મોકલે ત્યારે ઉત્પાદકો પસંદ કરી શકે છે:

• acks=0, પુષ્ટિકરણ મોકલેલ નથી
• acks=1, નેતાએ તેના સ્થાનિક લોગ પર સંદેશ લખ્યા પછી પુષ્ટિ મોકલવામાં આવે છે
• acks=all, ISR માં તમામ પ્રતિકૃતિઓએ સ્થાનિક લોગ પર સંદેશ લખ્યા પછી પુષ્ટિકરણ મોકલવામાં આવે છે.

કાફકા પરિભાષામાં, જો ISR એ સંદેશ સાચવ્યો હોય, તો તે "પ્રતિબદ્ધ" છે. Acks=all એ સૌથી સલામત વિકલ્પ છે, પરંતુ વધારાનો વિલંબ પણ ઉમેરે છે. ચાલો નિષ્ફળતાના બે ઉદાહરણો જોઈએ અને કેવી રીતે વિવિધ 'એક્સ' વિકલ્પો ISR ખ્યાલ સાથે ક્રિયાપ્રતિક્રિયા કરે છે.

Acks=1 અને ISR

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

આ ઉદાહરણમાં, ઉત્પાદક પાસે acks=1 મૂલ્ય છે. આ વિભાગ ત્રણેય બ્રોકરોમાં વહેંચાયેલો છે. બ્રોકર 3 પાછળ છે, તે આઠ સેકન્ડ પહેલા લીડર સાથે સિંક્રનાઇઝ થયું હતું અને હવે 7456 મેસેજ પાછળ છે. બ્રોકર 1 માત્ર એક સેકન્ડ પાછળ હતો. અમારા નિર્માતા એક સંદેશ મોકલે છે અને ધીમા અથવા મૃત અનુયાયીઓ કે જેની નેતા રાહ જોતા નથી તેના ઓવરહેડ વિના, ઝડપથી એક ack પ્રાપ્ત કરે છે.

ચોખા. 7. ત્રણ પ્રતિકૃતિઓ સાથે ISR

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

ચોખા. 8. જ્યારે તે ક્રેશ થાય છે ત્યારે સંદેશાઓ ખોવાઈ જાય છે

રૂપરેખાંકનમાં bootstrap.servers ઉત્પાદક પાસે ઘણા બ્રોકર્સ લિસ્ટેડ છે અને તે બીજા બ્રોકરને પૂછી શકે છે કે નવા સેક્શન લીડર કોણ છે. તે પછી બ્રોકર 1 સાથે જોડાણ સ્થાપિત કરે છે અને સંદેશા મોકલવાનું ચાલુ રાખે છે.

ચોખા. 9. ટૂંકા વિરામ પછી સંદેશા મોકલવાનું ફરી શરૂ થાય છે

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

ચોખા. 10. બ્રોકર 3 પરના અનુયાયીને ISRમાંથી દૂર કરવામાં આવે છે

બ્રોકર 1 નીચે જાય છે અને 3 સંદેશાઓની ખોટ સાથે લીડરશિપ રોલ બ્રોકર 15286 પાસે જાય છે! ઉત્પાદકને કનેક્શન ભૂલ સંદેશ પ્રાપ્ત થાય છે. ISR ની બહારના નેતાનું સંક્રમણ ફક્ત સેટિંગને કારણે જ શક્ય હતું unclean.leader.election.enable=true. જો તે માં સ્થાપિત થયેલ છે ખોટું, પછી સંક્રમણ થશે નહીં અને બધી વાંચવા અને લખવાની વિનંતીઓ નકારવામાં આવશે. આ કિસ્સામાં, અમે પ્રતિકૃતિમાં તેના અકબંધ ડેટા સાથે બ્રોકર 1 પરત આવે તેની રાહ જોઈ રહ્યા છીએ, જે ફરીથી નેતૃત્વ સંભાળશે.

ચોખા. 11. બ્રોકર 1 પડે છે. જ્યારે નિષ્ફળતા થાય છે, ત્યારે મોટી સંખ્યામાં સંદેશાઓ ખોવાઈ જાય છે

નિર્માતા છેલ્લા બ્રોકર સાથે જોડાણ સ્થાપિત કરે છે અને જુએ છે કે તે હવે વિભાગનો નેતા છે. તે બ્રોકર 3 ને સંદેશા મોકલવાનું શરૂ કરે છે.

ચોખા. 12. ટૂંકા વિરામ પછી, સંદેશાઓ ફરીથી વિભાગ 0 પર મોકલવામાં આવે છે

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

Acks=all અને ISR

ચાલો આ દૃશ્ય ફરીથી પુનરાવર્તન કરીએ, પરંતુ સાથે acks=બધા. બ્રોકર 3 ની સરેરાશ લેટન્સી ચાર સેકન્ડ છે. ઉત્પાદક સાથે સંદેશ મોકલે છે acks=બધા, અને હવે ઝડપી પ્રતિસાદ પ્રાપ્ત થતો નથી. નેતા ISR માં તમામ પ્રતિકૃતિઓ દ્વારા સંદેશ સાચવવામાં આવે તેની રાહ જુએ છે.

ચોખા. 13. ત્રણ પ્રતિકૃતિઓ સાથે ISR. એક ધીમું છે, પરિણામે રેકોર્ડિંગમાં વિલંબ થાય છે

વધારાના ચાર સેકન્ડના વિલંબ પછી, બ્રોકર 2 એક ack મોકલે છે. બધી પ્રતિકૃતિઓ હવે સંપૂર્ણપણે અપડેટ થઈ ગઈ છે.

ચોખા. 14. બધી પ્રતિકૃતિઓ સંદેશાઓ સાચવે છે અને ack મોકલે છે

બ્રોકર 3 હવે વધુ પાછળ પડી ગયો છે અને તેને ISRમાંથી દૂર કરવામાં આવ્યો છે. લેટન્સી નોંધપાત્ર રીતે ઘટી છે કારણ કે ISR માં કોઈ ધીમી પ્રતિકૃતિ બાકી નથી. બ્રોકર 2 હવે માત્ર બ્રોકર 1 ની રાહ જુએ છે, અને તેની પાસે સરેરાશ 500 ms છે.

ચોખા. 15. બ્રોકર 3 પરની પ્રતિકૃતિ ISRમાંથી દૂર કરવામાં આવી છે

પછી બ્રોકર 2 ઘટે છે અને સંદેશાઓની ખોટ વિના નેતૃત્વ બ્રોકર 1 પાસે જાય છે.

ચોખા. 16. બ્રોકર 2 પડે છે

ઉત્પાદક એક નવો નેતા શોધે છે અને તેને સંદેશા મોકલવાનું શરૂ કરે છે. વિલંબ વધુ ઘટ્યો છે કારણ કે ISR હવે એક પ્રતિકૃતિ ધરાવે છે! તેથી વિકલ્પ acks=બધા રીડન્ડન્સી ઉમેરતું નથી.

ચોખા. 17. બ્રોકર 1 પરની પ્રતિકૃતિ સંદેશાઓ ગુમાવ્યા વિના આગેવાની લે છે

પછી બ્રોકર 1 ક્રેશ થાય છે અને 3 સંદેશાઓના નુકશાન સાથે લીડ બ્રોકર 14238 પર જાય છે!

ચોખા. 18. બ્રોકર 1 મૃત્યુ પામે છે અને અસ્વચ્છ સેટિંગ સાથે નેતૃત્વ સંક્રમણ વ્યાપક ડેટા નુકશાનમાં પરિણમે છે

અમે વિકલ્પ ઇન્સ્ટોલ કરી શક્યા નથી unclean.leader.election.enable અર્થમાં સાચું. મૂળભૂત રીતે તે બરાબર છે ખોટું. સેટિંગ્સ acks=બધા с unclean.leader.election.enable=true કેટલીક વધારાની ડેટા સુરક્ષા સાથે સુલભતા પૂરી પાડે છે. પરંતુ જેમ તમે જોઈ શકો છો, અમે હજુ પણ સંદેશાઓ ગુમાવી શકીએ છીએ.

પરંતુ જો આપણે ડેટા સુરક્ષા વધારવી હોય તો શું? તમે મૂકી શકો છો unclean.leader.election.enable = ખોટા, પરંતુ આ જરૂરી નથી કે ડેટાના નુકશાનથી અમને રક્ષણ આપે. જો નેતા સખત પડી ગયો અને તેની સાથે ડેટા લઈ ગયો, તો સંદેશા હજી પણ ખોવાઈ જશે, વત્તા વ્યવસ્થાપક પરિસ્થિતિને પુનઃસ્થાપિત કરે ત્યાં સુધી ઉપલબ્ધતા ખોવાઈ જશે.

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

Acks=all, min.insync.replicas અને ISR

વિષય રૂપરેખાંકન સાથે min.insync.replicas અમે ડેટા સુરક્ષાનું સ્તર વધારી રહ્યા છીએ. ચાલો પાછલા દૃશ્યના છેલ્લા ભાગમાં ફરી જઈએ, પરંતુ આ વખતે સાથે min.insync.replicas=2.

તેથી બ્રોકર 2 પાસે પ્રતિકૃતિ લીડર છે અને બ્રોકર 3 પર અનુયાયીને ISR માંથી દૂર કરવામાં આવે છે.

ચોખા. 19. બે પ્રતિકૃતિઓમાંથી ISR

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

ચોખા. 20. ISR ની સંખ્યા min.insync.replicas માં ઉલ્લેખિત કરતા એક ઓછી છે

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

જ્યારે ડેટા સુરક્ષા માટે સુલભતા જરૂરી છે

જેમ RabbitMQ સાથે કેસ, કેટલીકવાર ડેટા સુરક્ષા માટે સુલભતા જરૂરી છે. તમારે જે વિશે વિચારવાની જરૂર છે તે અહીં છે:

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

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

ISR નો અર્થ

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

અમે અર્થ જાતે પસંદ કરીએ છીએ replica.lag.time.max.ms તમારી જરૂરિયાતો અનુસાર. અનિવાર્યપણે, આ પરિમાણનો અર્થ એ છે કે અમે ક્યારે સ્વીકારવા માટે કેટલો વિલંબ કરવા તૈયાર છીએ acks=બધા. ડિફૉલ્ટ મૂલ્ય દસ સેકન્ડ છે. જો આ તમારા માટે ખૂબ લાંબુ છે, તો તમે તેને ઘટાડી શકો છો. પછી ISR માં ફેરફારોની આવર્તન વધશે, કારણ કે અનુયાયીઓને દૂર કરવામાં આવશે અને વધુ વખત ઉમેરવામાં આવશે.

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

ક્લાયન્ટ કનેક્શન ગેરંટી

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

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

કાફકા સર્વસંમતિ આર્કિટેક્ચર

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

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

ઝૂકીપર ક્લસ્ટરની સ્થિતિનો સંગ્રહ કરે છે:

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

કંટ્રોલર નોડ એ કાફકા દલાલોમાંનું એક છે જે પ્રતિકૃતિ નેતાઓને પસંદ કરવા માટે જવાબદાર છે. ઝૂકીપર ક્લસ્ટર સભ્યપદ અને વિષય ફેરફારો વિશે નિયંત્રકને સૂચનાઓ મોકલે છે, અને નિયંત્રકે આ ફેરફારો પર કાર્ય કરવું જોઈએ.

ઉદાહરણ તરીકે, ચાલો દસ પાર્ટીશનો અને 3 ના પ્રતિકૃતિ પરિબળ સાથે એક નવો વિષય લઈએ. નિયંત્રકે દરેક પાર્ટીશન માટે એક નેતા પસંદ કરવો જોઈએ, બ્રોકરો વચ્ચે નેતાઓને શ્રેષ્ઠ રીતે વિતરિત કરવાનો પ્રયાસ કરે છે.

દરેક વિભાગ નિયંત્રક માટે:

• ISR અને લીડર વિશે ઝૂકીપરમાં માહિતી અપડેટ કરે છે;
• દરેક બ્રોકરને લીડરઅનેઆઈએસઆરકમાન્ડ મોકલે છે જે આ પાર્ટીશનની પ્રતિકૃતિ હોસ્ટ કરે છે, બ્રોકરોને ISR અને લીડર વિશે જાણ કરે છે.

જ્યારે લીડર સાથેનો બ્રોકર પડે છે, ત્યારે ઝૂકીપર નિયંત્રકને સૂચના મોકલે છે અને તે નવા લીડરને પસંદ કરે છે. ફરીથી, નિયંત્રક સૌપ્રથમ ઝૂકીપરને અપડેટ કરે છે અને પછી દરેક બ્રોકરને નેતૃત્વ પરિવર્તનની સૂચના આપતો આદેશ મોકલે છે.

દરેક નેતા ISR ની ભરતી માટે જવાબદાર છે. સેટિંગ્સ replica.lag.time.max.ms ત્યાં કોણ પ્રવેશ કરશે તે નક્કી કરે છે. જ્યારે ISR બદલાય છે, ત્યારે લીડર ઝૂકીપરને નવી માહિતી પ્રસારિત કરે છે.

ઝૂકીપરને હંમેશા કોઈપણ ફેરફારોની જાણ કરવામાં આવે છે જેથી નિષ્ફળતાની સ્થિતિમાં, મેનેજમેન્ટ નવા લીડરને સરળતાથી સંક્રમિત કરી શકે.

ચોખા. 21. કાફકા સર્વસંમતિ

પ્રતિકૃતિ પ્રોટોકોલ

પ્રતિકૃતિની વિગતોને સમજવાથી તમને સંભવિત ડેટા ગુમાવવાના દૃશ્યોને વધુ સારી રીતે સમજવામાં મદદ મળે છે.

સેમ્પલિંગ ક્વેરીઝ, લોગ એન્ડ ઓફસેટ (LEO) અને હાઇવોટર માર્ક (HW)

અમે માન્યું કે અનુયાયીઓ સમયાંતરે નેતાને આનયન વિનંતીઓ મોકલે છે. ડિફૉલ્ટ અંતરાલ 500ms છે. આ RabbitMQ થી અલગ છે કારણ કે RabbitMQ માં પ્રતિકૃતિ કતાર મિરર દ્વારા નહીં પરંતુ માસ્ટર દ્વારા શરૂ કરવામાં આવે છે. માસ્ટર અરીસાઓમાં ફેરફારોને દબાણ કરે છે.

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

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

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

નેતા નિષ્ફળતા

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

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

અનુયાયીને નીચેના કારણોસર લોગને કાપવાની જરૂર પડી શકે છે:

• જ્યારે કોઈ નેતા નિષ્ફળ જાય છે, ત્યારે ઝૂકીપર સાથે નોંધાયેલ ISR સેટમાં પ્રથમ અનુયાયી ચૂંટણી જીતે છે અને નેતા બને છે. ISR પરના બધા અનુયાયીઓ, જો કે "સમન્વયમાં" માનવામાં આવે છે, તેમ છતાં તેઓ ભૂતપૂર્વ નેતાના તમામ સંદેશાઓની નકલો પ્રાપ્ત કરી શક્યા નથી. તે સંપૂર્ણપણે શક્ય છે કે વૈશિષ્ટિકૃત અનુયાયી પાસે સૌથી અપ-ટુ-ડેટ નકલ નથી. કાફકા ખાતરી કરે છે કે પ્રતિકૃતિઓ વચ્ચે કોઈ ભિન્નતા નથી. આમ, વિસંગતતાઓને ટાળવા માટે, દરેક અનુયાયીએ તેની ચૂંટણી સમયે નવા નેતાના HW મૂલ્યમાં તેના લોગને કાપી નાખવો જોઈએ. સેટિંગ શા માટે આ બીજું કારણ છે acks=બધા સુસંગતતા માટે ખૂબ જ મહત્વપૂર્ણ.
• સંદેશાઓ સમયાંતરે ડિસ્ક પર લખવામાં આવે છે. જો બધા ક્લસ્ટર નોડ્સ એક જ સમયે નિષ્ફળ જાય, તો પછી વિવિધ ઑફસેટ્સ સાથેની પ્રતિકૃતિઓ ડિસ્ક પર સંગ્રહિત કરવામાં આવશે. શક્ય છે કે જ્યારે બ્રોકર્સ ઓનલાઈન પાછા આવે, ત્યારે નવા નેતા જે ચૂંટાય છે તે તેના અનુયાયીઓ પાછળ હશે કારણ કે તે અન્ય લોકો પહેલા ડિસ્કમાં સાચવવામાં આવ્યો હતો.

ક્લસ્ટર સાથે પુનઃમિલન

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

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

નવા અથવા ફરીથી જોડાનારા અનુયાયીઓ ISR ની બહાર શરૂ થાય છે અને કમિટ્સમાં ભાગ લેતા નથી. તેઓ ફક્ત જૂથની સાથે કામ કરે છે, જ્યાં સુધી તેઓ નેતા સાથે સંપર્ક ન કરે અને ISR માં પ્રવેશ ન કરે ત્યાં સુધી તેઓ શક્ય તેટલી ઝડપથી સંદેશાઓ પ્રાપ્ત કરે છે. ત્યાં કોઈ લોક-ઇન નથી અને તમારો બધો ડેટા ફેંકી દેવાની જરૂર નથી.

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

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

નીચે કેટલાક કનેક્ટિવિટી નિષ્ફળતાના દૃશ્યો છે:

• દૃશ્ય 1: અનુયાયી નેતાને જોતો નથી, પરંતુ તેમ છતાં ઝૂકીપરને જુએ છે.
• દૃશ્ય 2: નેતા કોઈ અનુયાયીઓને જોતા નથી, પરંતુ તેમ છતાં તે ઝૂકીપરને જુએ છે.
• દૃશ્ય 3: અનુયાયી નેતાને જુએ છે, પરંતુ ઝૂકીપરને જોતો નથી.
• દૃશ્ય 4: નેતા અનુયાયીઓને જુએ છે, પરંતુ ઝૂકીપરને જોતો નથી.
• દૃશ્ય 5: અનુયાયી અન્ય કાફકા નોડ્સ અને ઝૂકીપર બંનેથી સંપૂર્ણપણે અલગ છે.
• દૃશ્ય 6: લીડર અન્ય કાફકા નોડ્સ અને ઝૂકીપર બંનેથી સંપૂર્ણપણે અલગ છે.
• દૃશ્ય 7: કાફકા કંટ્રોલર નોડ અન્ય કાફકા નોડ જોઈ શકતું નથી.
• દૃશ્ય 8: કાફકા નિયંત્રક ઝૂકીપરને જોતો નથી.

દરેક દૃશ્યનું પોતાનું વર્તન હોય છે.

દૃશ્ય 1: અનુયાયી લીડરને જોતો નથી, પરંતુ તેમ છતાં ઝૂકીપરને જુએ છે

ચોખા. 22. દૃશ્ય 1: ત્રણ પ્રતિકૃતિઓનું ISR

કનેક્ટિવિટી નિષ્ફળતા બ્રોકર 3 ને બ્રોકર્સ 1 અને 2 થી અલગ કરે છે, પરંતુ ઝૂકીપરથી નહીં. બ્રોકર 3 હવે આનયન વિનંતીઓ મોકલી શકશે નહીં. સમય વીતી ગયા પછી replica.lag.time.max.ms તે ISR માંથી દૂર કરવામાં આવે છે અને સંદેશ કમિટ્સમાં ભાગ લેતો નથી. એકવાર કનેક્ટિવિટી પુનઃસ્થાપિત થઈ જાય તે પછી, તે ફરીથી વિનંતીઓ મેળવવાનું શરૂ કરશે અને જ્યારે તે નેતા સાથે સંપર્ક કરશે ત્યારે ISR સાથે જોડાશે. ઝૂકીપર પિંગ્સ મેળવવાનું ચાલુ રાખશે અને માની લેશે કે બ્રોકર જીવિત છે અને સ્વસ્થ છે.

ચોખા. 23. દૃશ્ય 1: જો replica.lag.time.max.ms અંતરાલમાં બ્રોકર પાસેથી કોઈ આનયન વિનંતી પ્રાપ્ત ન થાય તો તેને ISRમાંથી દૂર કરવામાં આવે છે.

RabbitMQ ની જેમ કોઈ સ્પ્લિટ-બ્રેઈન અથવા નોડ સસ્પેન્શન નથી. તેના બદલે, નિરર્થકતા ઓછી થાય છે.

દૃશ્ય 2: નેતા કોઈ અનુયાયીઓને જોતા નથી, પરંતુ તેમ છતાં તે ઝૂકીપરને જુએ છે

ચોખા. 24. દૃશ્ય 2. નેતા અને બે અનુયાયીઓ

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

ચોખા. 25. દૃશ્ય 2. ISR માત્ર નેતા સુધી સંકોચાઈ ગયું છે

દૃશ્ય 3. અનુયાયી નેતાને જુએ છે, પરંતુ ઝૂકીપરને જોતો નથી

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

ચોખા. 26. દૃશ્ય 3: અનુયાયી નેતાને વિનંતીઓ મોકલવાનું ચાલુ રાખે છે

દૃશ્ય 4. નેતા અનુયાયીઓને જુએ છે, પરંતુ ઝૂકીપરને જોતા નથી

ચોખા. 27. દૃશ્ય 4. નેતા અને બે અનુયાયીઓ

નેતા ઝૂકીપરથી અલગ છે, પરંતુ અનુયાયીઓ સાથેના દલાલોથી નહીં.

ચોખા. 28. દૃશ્ય 4: નેતા ઝૂકીપરથી અલગ

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

સંદેશાઓ acks=બધા સ્વીકૃતિ પ્રાપ્ત થશે નહીં કારણ કે ISR પ્રથમ બધી પ્રતિકૃતિઓ ચાલુ કરે છે, અને સંદેશાઓ તેમના સુધી પહોંચતા નથી. જ્યારે મૂળ નેતા તેમને ISRમાંથી દૂર કરવાનો પ્રયાસ કરશે, ત્યારે તે આમ કરવામાં અસમર્થ રહેશે અને કોઈપણ સંદેશાને સ્વીકારવાનું બિલકુલ બંધ કરશે.

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

ચોખા. 29. દૃશ્ય 4. નેટવર્ક પુનઃસ્થાપિત થયા પછી બ્રોકર 1 પર લીડર અનુયાયી બને છે

દૃશ્ય 5: અનુયાયી અન્ય કાફકા નોડ્સ અને ઝૂકીપર બંનેથી સંપૂર્ણપણે અલગ છે

અનુયાયી અન્ય કાફકા નોડ્સ અને ઝૂકીપર બંનેથી સંપૂર્ણપણે અલગ છે. જ્યાં સુધી નેટવર્ક પુનઃસ્થાપિત ન થાય ત્યાં સુધી તે ફક્ત પોતાને ISRમાંથી દૂર કરે છે, અને પછી અન્ય લોકો સાથે સંપર્ક કરે છે.

ચોખા. 30. દૃશ્ય 5: આઇસોલેટેડ ફોલોઅરને ISRમાંથી દૂર કરવામાં આવે છે

દૃશ્ય 6: લીડર અન્ય કાફકા નોડ્સ અને ઝૂકીપર બંનેથી સંપૂર્ણપણે અલગ છે

ચોખા. 31. દૃશ્ય 6. નેતા અને બે અનુયાયીઓ

નેતા તેના અનુયાયીઓ, નિયંત્રક અને ઝૂકીપરથી સંપૂર્ણપણે અલગ છે. ટૂંકા ગાળા માટે તે તરફથી પ્રવેશો સ્વીકારવાનું ચાલુ રહેશે acks=1.

ચોખા. 32. દૃશ્ય 6: અન્ય કાફકા અને ઝૂકીપર નોડ્સમાંથી નેતાને અલગ પાડવું

સમાપ્તિ પછી વિનંતીઓ પ્રાપ્ત થઈ નથી replica.lag.time.max.ms, તે ISR ને પોતાની તરફ સંકોચવાનો પ્રયત્ન કરશે, પરંતુ તે કરી શકશે નહીં કારણ કે Zookeeper સાથે કોઈ સંચાર નથી, તો તે લખાણો સ્વીકારવાનું બંધ કરશે.

દરમિયાન, ઝૂકીપર અલગ થયેલા બ્રોકરને મૃત તરીકે ચિહ્નિત કરશે અને નિયંત્રક નવા નેતાને પસંદ કરશે.

ચોખા. 33. દૃશ્ય 6. બે નેતાઓ

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

ચોખા. 34. દૃશ્ય 6: ઉત્પાદકો નવા નેતા પર સ્વિચ કરે છે

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

ચોખા. 35. દૃશ્ય 6: નેટવર્ક કનેક્ટિવિટી પુનઃસ્થાપિત થયા પછી મૂળ નેતા અનુયાયી બને છે

આ પરિસ્થિતિમાં, તાર્કિક વિભાજન ટૂંકા ગાળા માટે થઈ શકે છે, પરંતુ માત્ર જો acks=1 и min.insync.replicas પણ 1. તાર્કિક વિભાજન ક્યાં તો નેટવર્ક પુનઃસ્થાપિત થયા પછી આપમેળે સમાપ્ત થાય છે, જ્યારે મૂળ લીડરને ખબર પડે છે કે તે હવે લીડર નથી, અથવા જ્યારે બધા ક્લાયન્ટ્સ સમજે છે કે લીડર બદલાઈ ગયો છે અને નવા લીડરને લખવાનું શરૂ કરે છે - જે પણ પહેલા થાય છે. કોઈ પણ સંજોગોમાં, કેટલાક સંદેશાઓ ખોવાઈ જશે, પરંતુ માત્ર સાથે acks=1.

આ દૃશ્યનો બીજો પ્રકાર છે જ્યાં, નેટવર્ક વિભાજિત થાય તે પહેલાં, અનુયાયીઓ પાછળ પડી ગયા અને નેતાએ ISR ને ફક્ત પોતાની સાથે સંકુચિત કર્યું. તે પછી કનેક્ટિવિટી ગુમાવવાના કારણે અલગ પડી જાય છે. નવો નેતા ચૂંટાય છે, પરંતુ મૂળ નેતા પ્રવેશો સ્વીકારવાનું ચાલુ રાખે છે acks=બધા, કારણ કે તેના સિવાય ISR માં બીજું કોઈ નથી. એકવાર નેટવર્ક પુનઃસ્થાપિત થઈ જાય પછી આ રેકોર્ડ્સ ખોવાઈ જશે. આ વિકલ્પને ટાળવાનો એકમાત્ર રસ્તો છે min.insync.replicas = 2.

દૃશ્ય 7: કાફકા કંટ્રોલર નોડ અન્ય કાફકા નોડ જોઈ શકતું નથી

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

દૃશ્ય 8: કાફકા નિયંત્રક ઝૂકીપરને જોતો નથી

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

દૃશ્યોમાંથી તારણો

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

જો નેતા કનેક્ટિવિટી ગુમાવવાને કારણે ઝૂકીપરથી અલગ થઈ જાય, તો આના પરિણામે સંદેશાઓ ગુમ થઈ શકે છે. acks=1. ઝૂકીપર સાથે વાતચીતનો અભાવ બંને નેતાઓ સાથે સંક્ષિપ્ત તાર્કિક વિભાજનનું કારણ બને છે. આ સમસ્યા પરિમાણ દ્વારા ઉકેલી છે acks=બધા.

પેરામીટર min.insync.replicas બે અથવા વધુ પ્રતિકૃતિઓમાં વધારાની ખાતરી આપે છે કે આવા ટૂંકા ગાળાના દૃશ્યો 6 ની જેમ ખોવાયેલા સંદેશાઓમાં પરિણમશે નહીં.

ખોવાયેલા સંદેશાઓનો સારાંશ

ચાલો કાફકામાં તમે ડેટા ગુમાવી શકો તે બધી રીતોની સૂચિ બનાવીએ:

• જો સંદેશાઓનો ઉપયોગ કરીને પુષ્ટિ કરવામાં આવી હોય તો કોઈપણ નેતા નિષ્ફળતા acks=1
• નેતૃત્વનું કોઈપણ અશુદ્ધ સંક્રમણ, એટલે કે, ISR ની બહારના અનુયાયીમાં, સાથે પણ acks=બધા
• જો સંદેશાઓનો ઉપયોગ કરીને પુષ્ટિ થઈ હોય તો ઝૂકીપરથી નેતાને અલગ પાડવું acks=1
• ISR જૂથને પહેલાથી જ સંકોચાઈ ગયેલા નેતાનું સંપૂર્ણ અલગતા. બધા સંદેશાઓ પણ ખોવાઈ જશે acks=બધા. આ તો જ સાચું છે min.insync.replicas=1.
• બધા પાર્ટીશન નોડ્સની એક સાથે નિષ્ફળતા. કારણ કે સંદેશાઓ મેમરીમાંથી સ્વીકારવામાં આવે છે, કેટલાક હજુ સુધી ડિસ્ક પર લખી શકાતા નથી. સર્વર્સ રીબૂટ કર્યા પછી, કેટલાક સંદેશા ખૂટે છે.

અશુદ્ધ નેતૃત્વ સંક્રમણોને કાં તો તેમને પ્રતિબંધિત કરીને અથવા ઓછામાં ઓછા બે નિરર્થકતાને સુનિશ્ચિત કરીને ટાળી શકાય છે. સૌથી ટકાઉ રૂપરેખાંકન એ સંયોજન છે acks=બધા и min.insync.replicas 1 થી વધુ.

રેબિટએમક્યુ અને કાફકાની વિશ્વસનીયતાની સીધી સરખામણી

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

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

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

• fsync દર થોડાક સો મિલિસેકંડે
• દરેક નોડ (નેટ ટિક) ની ઉપલબ્ધતા તપાસતા પેકેટોના જીવનકાળ પછી જ અરીસાની નિષ્ફળતાની નોંધ થઈ શકે છે. જો અરીસો ધીમો પડી જાય અથવા પડી જાય, તો આ વિલંબ ઉમેરે છે.

કાફકાની શરત એ છે કે જો કોઈ સંદેશ બહુવિધ નોડ પર સંગ્રહિત હોય, તો તે સંદેશાઓને મેમરીને સ્પર્શતાની સાથે જ તેને સ્વીકારી શકે છે. આને કારણે, કોઈપણ પ્રકારના સંદેશાઓ ગુમાવવાનું જોખમ રહેલું છે (પણ acks=બધા, min.insync.replicas=2) એક સાથે નિષ્ફળતાના કિસ્સામાં.

એકંદરે, કાફકા વધુ સારું સોફ્ટવેર પ્રદર્શન દર્શાવે છે અને ક્લસ્ટરો માટે ગ્રાઉન્ડ ઉપરથી ડિઝાઇન કરવામાં આવ્યું છે. જો વિશ્વસનીયતા માટે જરૂરી હોય તો અનુયાયીઓની સંખ્યા વધારીને 11 કરી શકાય છે. પ્રતિકૃતિ પરિબળ 5 અને સિંક્રનાઇઝેશનમાં પ્રતિકૃતિઓની ન્યૂનતમ સંખ્યા min.insync.replicas=3 સંદેશ ખોવાઈ જવાને ખૂબ જ દુર્લભ ઘટના બનાવશે. જો તમારું ઈન્ફ્રાસ્ટ્રક્ચર આ પ્રતિકૃતિ ગુણોત્તર અને રીડન્ડન્સીના સ્તરને સમર્થન આપી શકે, તો તમે આ વિકલ્પ પસંદ કરી શકો છો.

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

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

છેલ્લે, RabbitMQ અને Kafka બંનેના ક્લસ્ટરિંગ અને રિપ્લિકેશન મિકેનિઝમ્સમાં સંખ્યાબંધ ભૂલો વિશે ભૂલશો નહીં. સમય જતાં, સિસ્ટમો વધુ પરિપક્વ અને સ્થિર બની છે, પરંતુ કોઈપણ સંદેશ ક્યારેય નુકસાનથી 100% સુરક્ષિત રહેશે નહીં! વધુમાં, ડેટા સેન્ટરોમાં મોટા પાયે અકસ્માતો થાય છે!

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

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

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

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

સોર્સ: www.habr.com