સંદેશ દલાલોને સમજવું. ActiveMQ અને Kafka સાથે મેસેજિંગની મિકેનિક્સ શીખવી. પ્રકરણ 3. કાફકા

એક નાનકડા પુસ્તકના અનુવાદનું સાતત્ય:
સંદેશ બ્રોકર્સને સમજવું
લેખક: જાકુબ કોરાબ, પ્રકાશક: O'Reilly Media, Inc., પ્રકાશનની તારીખ: જૂન 2017, ISBN: 9781492049296.

અગાઉનો અનુવાદિત ભાગ: સંદેશ દલાલોને સમજવું. ActiveMQ અને Kafka સાથે મેસેજિંગની મિકેનિક્સ શીખવી. પ્રકરણ 1 પરિચય

પ્રકરણ 3

કાફકા

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

આ અંતિમ ધ્યેયને જોતાં, અન્ય જરૂરિયાતો કુદરતી રીતે ઊભી થઈ. કાફકાએ જોઈએ:

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

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

યુનિફાઇડ ડેસ્ટિનેશન મોડલ

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

આ પ્રકરણના બાકીના ભાગ માટે, જ્યાં સુધી આપણે સ્પષ્ટપણે અન્યથા જણાવતા નથી, ત્યાં સુધી "વિષય" શબ્દ કાફકા વિષયનો સંદર્ભ આપશે.

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

"લોગ" અને "પોઇન્ટર" શબ્દોમાં દેખાતા નથી કાફકા દસ્તાવેજીકરણ. આ જાણીતા શબ્દોનો ઉપયોગ અહીં સમજવામાં મદદ કરવા માટે કરવામાં આવ્યો છે.

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

આકૃતિ 3-1. કાફકા પાર્ટીશનો

જ્યારે નિર્માતા કાફકા વિષય પર સંદેશ મોકલે છે, ત્યારે તે નક્કી કરે છે કે કયા પાર્ટીશનને સંદેશ મોકલવો. અમે આને પછીથી વધુ વિગતવાર જોઈશું.

સંદેશાઓ વાંચી રહ્યા છીએ

ક્લાયંટ કે જે સંદેશાઓ વાંચવા માંગે છે તે નામના નિર્દેશકનું સંચાલન કરે છે ગ્રાહક જૂથ, જે નિર્દેશ કરે છે ઓફસેટ પાર્ટીશનમાં સંદેશાઓ. ઑફસેટ એ વધતી જતી સ્થિતિ છે જે પાર્ટીશનની શરૂઆતમાં 0 થી શરૂ થાય છે. આ ઉપભોક્તા જૂથ, વપરાશકર્તા-વ્યાખ્યાયિત group_id દ્વારા API માં સંદર્ભિત, અનુલક્ષે છે એક તાર્કિક ઉપભોક્તા અથવા સિસ્ટમ.

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

વાંચનની સમસ્યાને નીચે પ્રમાણે રજૂ કરી શકાય છે:

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

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

ઉપભોક્તા અને ઉપભોક્તા જૂથો

ચાલો એક પાર્ટીશન સાથેના વિષયને પ્રારંભિક બિંદુ તરીકે લઈએ (આકૃતિ 3-2).

આકૃતિ 3-2. ઉપભોક્તા પાર્ટીશનમાંથી વાંચે છે

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

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

આકૃતિ 3-3. જુદા જુદા ઉપભોક્તા જૂથોમાં બે ઉપભોક્તાઓ એક જ પાર્ટીશનમાંથી વાંચે છે

ઉપભોક્તા જૂથમાં ગ્રાહકો

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

આકૃતિ 3-4. એક જ ઉપભોક્તા જૂથના બે ઉપભોક્તાઓ એક જ પાર્ટીશનમાંથી વાંચે છે

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

ઉપર વર્ણવેલ આ સંદેશ વિતરણ વર્તણૂક સામાન્ય JMS કતાર કેવી રીતે વર્તે છે તેની સરખામણીમાં આશ્ચર્યજનક હોઈ શકે છે. આ મોડેલમાં, કતારમાં મોકલવામાં આવેલા સંદેશાઓ બે ગ્રાહકો વચ્ચે સમાનરૂપે વિતરિત કરવામાં આવશે.

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

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

કાફકામાં આ સમસ્યાને હલ કરવાની પ્રામાણિક રીત છે b નો ઉપયોગ કરવોОવધુ પાર્ટીશનો.

પાર્ટીશન

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

આકૃતિ 3-5. એક ગ્રાહક બહુવિધ પાર્ટીશનોમાંથી વાંચે છે

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

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

આકૃતિ 3-6. એક જ ઉપભોક્તા જૂથના બે ઉપભોક્તાઓ જુદા જુદા પાર્ટીશનોમાંથી વાંચે છે

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

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

બધા કાફકા બ્રોકરે ગ્રાહકને અનુક્રમે સંદેશા મોકલવાનું હોય છે જ્યારે બાદમાં તેમને વિનંતી કરે છે.

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

સંદેશા મોકલી રહ્યાં છીએ

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

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

પ્રકરણ 2 માં, અમે ઓનલાઈન સટ્ટાબાજીના દૃશ્યની ચર્ચા કરી છે જ્યાં સંબંધિત ઘટનાઓને એક ગ્રાહક દ્વારા ક્રમમાં પ્રક્રિયા કરવાની જરૂર છે:

1. વપરાશકર્તા ખાતું ગોઠવેલું છે.
2. ખાતામાં પૈસા જમા થાય છે.
3. ખાતામાંથી પૈસા ઉપાડી લે તેવી શરત લગાવવામાં આવે છે.

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

આ ઇન્ટરફેસ આના જેવો દેખાય છે:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

તમારી પોતાની પાર્ટીશન વ્યૂહરચના લખી રહ્યા છીએ

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

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

સ્ટોરમાં સંદેશાઓના ભ્રષ્ટાચારને શોધવા માટે કાફકામાં ચેકસમનો સમાવેશ થાય છે અને તેમાં સુરક્ષા સુવિધાઓનો સંપૂર્ણ સેટ છે. તેમ છતાં, ઉદ્યોગ-વિશિષ્ટ જરૂરિયાતો, જેમ કે ઉપરોક્ત, ક્યારેક દેખાય છે.

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

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

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

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

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

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

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

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

નિર્માતા કરારો

સંદેશાઓ મોકલતી વખતે માત્ર પાર્ટીશનને ધ્યાનમાં લેવાની બાબત નથી. ચાલો Java API માં નિર્માતા વર્ગની send() પદ્ધતિઓ પર એક નજર કરીએ:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

સંદેશાઓ વાંચવા વિશે વધુ

સંદેશાઓ વાંચવામાં વધારાની જટિલતાઓ છે જેના વિશે અનુમાન કરવાની જરૂર છે. JMS API થી વિપરીત, જે સંદેશના જવાબમાં સંદેશ સાંભળનારને ચલાવી શકે છે કન્ઝ્યુમર કાફકા માત્ર મતદાન કરે છે. ચાલો પદ્ધતિ પર નજીકથી નજર કરીએ મતદાન()આ હેતુ માટે વપરાય છે:

ConsumerRecords < K, V > poll(long timeout);

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

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

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

અગાઉ ચર્ચા કરેલ રીડિંગ મોડલ પર પાછા ફરીને, મેસેજ પ્રોસેસિંગમાં ત્રણ તબક્કાઓનો સમાવેશ થાય છે:

1. વાંચવા માટે સંદેશ પુનઃપ્રાપ્ત કરો.
2. સંદેશ પર પ્રક્રિયા કરો.
3. સંદેશની પુષ્ટિ કરો.

કાફકા ગ્રાહક રૂપરેખાંકન વિકલ્પ સાથે આવે છે enable.auto.commit. આ વારંવાર ઉપયોગમાં લેવાતી ડિફોલ્ટ સેટિંગ છે, જેમ કે "ઓટો" શબ્દ ધરાવતી સેટિંગ્સમાં સામાન્ય છે.

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

કાફકા 0.10 માં, ક્લાયંટ કોડ બદલાઈ ગયો છે જેથી કમિટને ક્લાઈન્ટ લાઈબ્રેરી દ્વારા સમયાંતરે ટ્રિગર કરવામાં આવે, જેમ કે રૂપરેખાંકિત કરવામાં આવે છે. auto.commit.interval.ms. આ વર્તન JMS AUTO_ACKNOWLEDGE અને DUPS_OK_ACKNOWLEDGE મોડ્સ વચ્ચે ક્યાંક છે. ઑટોકમિટનો ઉપયોગ કરતી વખતે, સંદેશાઓ પર વાસ્તવમાં પ્રક્રિયા કરવામાં આવી હતી કે કેમ તે ધ્યાનમાં લીધા વિના પ્રતિબદ્ધ થઈ શકે છે - આ ધીમા ગ્રાહકના કિસ્સામાં થઈ શકે છે. જો કોઈ ઉપભોક્તા અવગણશે, તો સંદેશા આગામી ઉપભોક્તા દ્વારા લાવવામાં આવશે, પ્રતિબદ્ધ સ્થિતિમાંથી શરૂ થશે, જેના પરિણામે સંદેશ ચૂકી જશે. આ કિસ્સામાં, કાફકાએ સંદેશાઓ ગુમાવ્યા નહોતા, વાંચન કોડ ફક્ત તેમની પ્રક્રિયા કરતા ન હતા.

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

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

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

તમે પેરામીટર સેટ કરીને કાફકા કન્ઝ્યુમર API માં મેન્યુઅલ ઓફસેટ કમિટ પ્રક્રિયાને નિયંત્રિત કરી શકો છો enable.auto.commit નીચેની પદ્ધતિઓમાંથી એકને ખોટી અને સ્પષ્ટપણે કૉલ કરવા માટે:

void commitSync();
void commitAsync();

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

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

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

જો આપણે વ્યવહારો પર આધાર રાખી શકતા નથી, તો આપણે પરંપરાગત મેસેજિંગ સિસ્ટમ્સ દ્વારા પ્રદાન કરવામાં આવેલા સિમેન્ટિક્સની નજીક કેવી રીતે પ્રદાન કરી શકીએ?

જો એવી સંભાવના હોય કે સંદેશની પ્રક્રિયા કરવામાં આવે તે પહેલાં ગ્રાહકની ઑફસેટ વધી શકે છે, જેમ કે ગ્રાહક ક્રેશ દરમિયાન, તો ગ્રાહકને એ જાણવાની કોઈ રીત નથી કે તેના ગ્રાહક જૂથે જ્યારે તેને પાર્ટીશન સોંપવામાં આવે ત્યારે સંદેશ ચૂકી ગયો હતો કે કેમ. તેથી એક વ્યૂહરચના એ છે કે ઑફસેટને પાછલી સ્થિતિ પર રીવાઇન્ડ કરવાની છે. કાફકા ગ્રાહક API આ માટે નીચેની પદ્ધતિઓ પ્રદાન કરે છે:

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

પદ્ધતિ શોધો() પદ્ધતિથી વાપરી શકાય છે
offsetsForTimes(નકશો ટાઈમસ્ટેમ્પસર્ચ) ભૂતકાળમાં અમુક ચોક્કસ બિંદુએ રાજ્યમાં રીવાઇન્ડ કરવા માટે.

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

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

વ્યક્તિગત અવલોકનો દર્શાવે છે કે જેમ જેમ સંદેશાની તીવ્રતા વધે છે તેમ તેમ દરેક વ્યક્તિગત સંદેશનું મૂલ્ય ઘટતું જાય છે. એકંદર સ્વરૂપમાં જોવામાં આવે ત્યારે મોટા સંદેશાઓ મૂલ્યવાન હોય છે.

ઉચ્ચ ઉપલબ્ધતા

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

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

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

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

બેઝ કેસમાં, નીચેના ગુણધર્મો સાથે કાફકા ક્લસ્ટરમાં વિષય બનાવવામાં આવે છે:

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

સંકલન માટે ZooKeepers નો ઉપયોગ કરીને, કાફકા ક્લસ્ટરમાં બ્રોકર્સ વચ્ચે નવા પાર્ટીશનો યોગ્ય રીતે વિતરિત કરવાનો પ્રયાસ કરે છે. આ એક જ ઉદાહરણ દ્વારા કરવામાં આવે છે જે નિયંત્રક તરીકે કાર્ય કરે છે.

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

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

નિર્માતા રૂપરેખાંકનનો ભાગ પરિમાણ છે acks, જે નિર્ધારિત કરે છે કે એપ્લિકેશન થ્રેડ મોકલવાનું ચાલુ રાખે તે પહેલાં કેટલી પ્રતિકૃતિઓએ સંદેશની રસીદ (સ્વીકાર) સ્વીકારવી જોઈએ: 0, 1, અથવા બધા. જો સેટ કરેલ હોય બધા, પછી જ્યારે કોઈ સંદેશ પ્રાપ્ત થાય છે, ત્યારે નેતા નિર્માતાને વિષય સેટિંગ દ્વારા વ્યાખ્યાયિત કેટલાક સંકેતો (પોતાના સહિત)માંથી રેકોર્ડની પુષ્ટિ (સ્વીકૃતિઓ) મેળવતાની સાથે જ એક પુષ્ટિકરણ મોકલશે. min.insync.replicas (મૂળભૂત 1). જો સંદેશ સફળતાપૂર્વક નકલ કરી શકાતો નથી, તો નિર્માતા એપ્લિકેશન અપવાદ ફેંકશે (NotEnoughReplicas અથવા NotEnoughReplicasAfterAppend).

લાક્ષણિક રૂપરેખાંકન 3 (1 લીડર, પાર્ટીશન દીઠ 2 અનુયાયીઓ) અને પરિમાણના પ્રતિકૃતિ પરિબળ સાથે વિષય બનાવે છે. min.insync.replicas 2 પર સેટ કરેલ છે. આ કિસ્સામાં, ક્લસ્ટર વિષય પાર્ટીશનનું સંચાલન કરતા બ્રોકરોમાંના એકને ક્લાયન્ટ એપ્લિકેશનોને અસર કર્યા વિના નીચે જવાની મંજૂરી આપશે.

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

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

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

એક કાફકા બ્રોકર કરતાં કાફકા ક્લસ્ટરમાં વધુ સારું પ્રદર્શન શક્ય છે, કારણ કે વિષય પાર્ટીશનો ઘણા અલગ મશીનોમાં સ્કેલ કરી શકે છે.

પરિણામો

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

અગાઉનો અનુવાદિત ભાગ: સંદેશ દલાલોને સમજવું. ActiveMQ અને Kafka સાથે મેસેજિંગની મિકેનિક્સ શીખવી. પ્રકરણ 1

અનુવાદ થઈ ગયો: tele.gg/middle_java

ચાલુ રહી શકાય…

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

શું તમારી સંસ્થામાં કાફકાનો ઉપયોગ થાય છે?

• હા

• કોઈ

• પહેલાં ઉપયોગ થતો હતો, હવે નહીં

• અમે ઉપયોગ કરવાની યોજના બનાવીએ છીએ

38 વપરાશકર્તાઓએ મતદાન કર્યું. 8 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com