કાફકા કેવી રીતે વાસ્તવિકતા બની

હે હબર!

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

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

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

ખાતરીપૂર્વકની ડિલિવરી અને વધુ

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

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

org.apache.kafka.common.utils.AppInfoParser — Error registering AppInfo mbean javax.management.InstanceAlreadyExistsException: kafka.consumer:type=app-info,id=kafka.test-0

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

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

• 0 - સ્વીકૃતિ ધ્યાનમાં લેવામાં આવશે નહીં.
• 1 એ ડિફૉલ્ટ પરિમાણ છે, માત્ર 1 પ્રતિકૃતિ સ્વીકારવા માટે જરૂરી છે.
• −1 — બધી સિંક્રનાઇઝ્ડ પ્રતિકૃતિઓમાંથી સ્વીકાર જરૂરી છે (ક્લસ્ટર સેટઅપ min.insync.replicas).

સૂચિબદ્ધ મૂલ્યોમાંથી તે સ્પષ્ટ છે કે −1 ની બરાબર acks સૌથી મજબૂત ગેરંટી આપે છે કે સંદેશ ખોવાઈ જશે નહીં.

જેમ આપણે બધા જાણીએ છીએ, વિતરિત સિસ્ટમો અવિશ્વસનીય છે. ક્ષણિક ખામીઓ સામે રક્ષણ આપવા માટે, કાફકા નિર્માતા વિકલ્પ પૂરો પાડે છે ફરી પ્રયાસ કરે છે, જે તમને અંદર ફરીથી મોકલવાના પ્રયાસોની સંખ્યા સેટ કરવાની મંજૂરી આપે છે વિતરણ.સમય સમાપ્તિ. પુનઃપ્રયાસ પરિમાણમાં Integer.MAX_VALUE (2147483647) નું ડિફૉલ્ટ મૂલ્ય હોવાથી, સંદેશના પુનઃપ્રયાસોની સંખ્યા ફક્ત delivery.timeout.ms બદલીને ગોઠવી શકાય છે.

અમે બરાબર એકવાર ડિલિવરી તરફ આગળ વધી રહ્યા છીએ

સૂચિબદ્ધ સેટિંગ્સ અમારા નિર્માતાને ઉચ્ચ ગેરંટી સાથે સંદેશા પહોંચાડવાની મંજૂરી આપે છે. ચાલો હવે વાત કરીએ કે કેવી રીતે ખાતરી કરવી કે સંદેશની માત્ર એક નકલ કાફકા વિષય પર લખાય છે? સરળ કિસ્સામાં, આ કરવા માટે, તમારે નિર્માતા પર પરિમાણ સેટ કરવાની જરૂર છે enable.idempotence સાચું. આઇડમ્પોટેન્સી બાંયધરી આપે છે કે એક વિષયના ચોક્કસ પાર્ટીશન પર માત્ર એક જ સંદેશ લખવામાં આવે છે. આઇડમ્પોટેન્સીને સક્ષમ કરવા માટેની પૂર્વશરત એ મૂલ્યો છે acks = બધા, ફરી પ્રયાસ > 0, max.in.flight.requests.per.connection ≤ 5. જો આ પરિમાણો વિકાસકર્તા દ્વારા ઉલ્લેખિત ન હોય, તો ઉપરોક્ત મૂલ્યો આપમેળે સેટ થઈ જશે.

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

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

ઉપરાંત, કીનો ઉપયોગ કરીને અને પરિમાણ સાથે મોકલવું max.in.flight.requests.per.connection = 1 તમને ઉપભોક્તા પર સુવ્યવસ્થિત સંદેશ પ્રક્રિયા આપે છે. તે યાદ રાખવું પણ યોગ્ય છે કે જો તમારા ક્લસ્ટર પર એક્સેસ કંટ્રોલ ગોઠવેલું હોય, તો તમારે કોઈ વિષય પર વિચારપૂર્વક લખવા માટે અધિકારોની જરૂર પડશે.

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

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

org.apache.kafka.common.errors.ProducerFencedException: Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker.

આ સમસ્યાને ઉકેલવા માટે, અમે યજમાનનામના રૂપમાં એપ્લિકેશન નામમાં એક પ્રત્યય ઉમેરીએ છીએ, જે આપણે પર્યાવરણ ચલોમાંથી મેળવીએ છીએ.

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

ઉપભોક્તા દ્વારા આવા સંદેશાને સમય પહેલા વાંચવામાં ન આવે તે માટે, તેણે પેરામીટર સેટ કરવાની જરૂર છે isolation.level પ્રતિબદ્ધ મૂલ્ય વાંચવા માટે. આવા ઉપભોક્તા પહેલાની જેમ બિન-ટ્રાન્ઝેક્શનલ સંદેશાઓ વાંચી શકશે અને પ્રતિબદ્ધતા પછી જ વ્યવહારિક સંદેશાઓ વાંચી શકશે.
જો તમે અગાઉ સૂચિબદ્ધ બધી સેટિંગ્સ સેટ કરી હોય, તો પછી તમે ડિલિવરી પછી બરાબર ગોઠવેલ છે. અભિનંદન!

પરંતુ ત્યાં એક વધુ સૂક્ષ્મતા છે. Transactional.id, જે અમે ઉપર ગોઠવેલ છે, તે વાસ્તવમાં ટ્રાન્ઝેક્શન ઉપસર્ગ છે. ટ્રાન્ઝેક્શન મેનેજર પર, તેમાં એક ક્રમ નંબર ઉમેરવામાં આવે છે. પ્રાપ્ત ઓળખકર્તાને જારી કરવામાં આવે છે transactional.id.expiration.ms, જે કાફકા ક્લસ્ટર પર ગોઠવેલ છે અને તેની મૂળભૂત કિંમત “7 દિવસ” છે. જો આ સમય દરમિયાન એપ્લિકેશનને કોઈ સંદેશો પ્રાપ્ત થયો નથી, તો પછી જ્યારે તમે આગલી ટ્રાન્ઝેક્શનલ મોકલવાનો પ્રયાસ કરશો ત્યારે તમને પ્રાપ્ત થશે InvalidPidMappingException. ટ્રાન્ઝેક્શન કોઓર્ડિનેટર પછીના વ્યવહાર માટે નવો ક્રમ નંબર જારી કરશે. જો કે, જો InvalidPidMappingException યોગ્ય રીતે હેન્ડલ કરવામાં ન આવે તો સંદેશ ગુમ થઈ શકે છે.

કુલ બદલે

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

નિર્માતા:

1. acks = બધા
2. ફરી પ્રયાસો > 0
3. enable.idempotence = સાચું
4. max.in.flight.requests.per.connection ≤ 5 (વ્યવસ્થિત રીતે મોકલવા માટે 1)
5. transactional.id = ${application-name}-${hostname}

ઉપભોક્તા:

1. isolation.level = વાંચન_પ્રતિબદ્ધ

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

સ્વ-અભ્યાસ માટે અહીં કેટલીક સામગ્રી છે:

• KIP-98 - બરાબર એકવાર ડિલિવરી અને ટ્રાન્ઝેક્શનલ મેસેજિંગ
• સેટિંગ્સનું વર્ણન

સોર્સ: www.habr.com