ካፍካ እንዴት እውን ሆነ

ሃይ ሀብር!

የራሱን የማሳወቂያ ማእከል በማዘጋጀት በ Tinkoff ቡድን ላይ እሰራለሁ። እኔ በአብዛኛው በጃቫ ውስጥ ስፕሪንግ ቡት በመጠቀም እገነባለሁ እና በፕሮጄክት ውስጥ የሚነሱ የተለያዩ ቴክኒካዊ ችግሮችን እፈታለሁ።

አብዛኛዎቹ ማይክሮ አገልግሎቶቻችን በመልዕክት ደላላ በኩል እርስ በርስ ይገናኛሉ። ከዚህ በፊት IBM MQ ን እንደ ደላላ እንጠቀም ነበር, ይህም ጭነቱን መቋቋም የማይችል, ግን በተመሳሳይ ጊዜ ከፍተኛ የመላኪያ ዋስትናዎች አሉት.

እንደ ምትክ፣ ከፍተኛ የመጠን አቅም ያለው Apache Kafka ሰጥተን ነበር፣ ነገር ግን በሚያሳዝን ሁኔታ፣ ለተለያዩ ሁኔታዎች ውቅረት ግለሰባዊ አቀራረብን ይፈልጋል። በተጨማሪም በካፍካ ውስጥ በነባሪነት የሚሰራው ቢያንስ አንድ ጊዜ የመላኪያ ዘዴ ከሳጥኑ ውስጥ የሚፈለገውን ወጥነት ያለው ደረጃ ለመጠበቅ አልፈቀደም። በመቀጠል, በካፍካ ውቅረት ውስጥ ያለንን ልምድ እናካፍላለን, በተለይም አንድ ጊዜ ማድረስ እንዴት ማዋቀር እና መኖር እንደሚችሉ እነግርዎታለሁ.

የተረጋገጠ ማድረስ እና ሌሎችም።

ከዚህ በታች የተብራሩት መቼቶች በነባሪ የግንኙነት ቅንብሮች ላይ በርካታ ችግሮችን ለመከላከል ይረዳሉ። ግን በመጀመሪያ ሊቻል የሚችል ማረም ለሚያመቻች አንድ ግቤት ትኩረት መስጠት እፈልጋለሁ።

ይህ ይረዳል ደንበኛ.መታወቂያ ለአምራች እና ለሸማች. በመጀመሪያ እይታ የመተግበሪያውን ስም እንደ ዋጋ መጠቀም ይችላሉ, እና በአብዛኛዎቹ ሁኔታዎች ይሄ ይሰራል. ምንም እንኳን አፕሊኬሽኑ ብዙ ሸማቾችን ሲጠቀም እና እርስዎ ተመሳሳይ ደንበኛ መታወቂያ ሲሰጧቸው ሁኔታው ​​የሚከተለውን ማስጠንቀቂያ ያስከትላል።

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

ከካፍካ ጋር ባለው መተግበሪያ ውስጥ JMX ን ለመጠቀም ከፈለጉ ይህ ችግር ሊሆን ይችላል። ለዚህ ጉዳይ የመተግበሪያውን ስም እና ለምሳሌ የርዕሱን ስም እንደ ደንበኛ መታወቂያ ዋጋ መጠቀም ጥሩ ነው። የእኛ ውቅረት ውጤት በትእዛዝ ውፅዓት ውስጥ ሊታይ ይችላል። kafka-የሸማቾች-ቡድኖች ከመገልገያዎች ከ Confluent:

አሁን የተረጋገጠ የመልእክት አሰጣጥ ሁኔታን እንመልከት። የካፍካ ፕሮዲዩሰር መለኪያ አለው። አክስ, ይህም የክላስተር መሪው መልእክቱን በተሳካ ሁኔታ የተጻፈውን ምን ያህል እውቅና ካገኘ በኋላ እንዲያዋቅሩ ያስችልዎታል. ይህ ግቤት የሚከተሉትን እሴቶች ሊወስድ ይችላል፡-

• 0 - እውቅና አይቆጠርም.
• 1 ነባሪ መለኪያ ነው፣ እውቅና ለመስጠት 1 ቅጂ ብቻ ያስፈልጋል።
• -1 — ከሁሉም የተመሳሰሉ ቅጂዎች እውቅና መስጠት ያስፈልጋል (ክላስተር ማዋቀር min.insync.replicas).

ከተዘረዘሩት እሴቶች ግልጽ የሆነው acks ከ -1 ጋር እኩል የሆነ መልእክቱ እንዳይጠፋ ጠንካራ ዋስትና ይሰጣል።

ሁላችንም እንደምናውቀው, የተከፋፈሉ ስርዓቶች አስተማማኝ አይደሉም. ጊዜያዊ ስህተቶችን ለመከላከል የካፍካ ፕሮዲዩሰር አማራጩን ይሰጣል እንደገና ይሞክራል።, ይህም ውስጥ እንደገና ለመላክ ሙከራዎች ብዛት እንዲያቀናብሩ ያስችልዎታል መላኪያ.የጊዜ ማብቂያ.ms. የዳግም ሙከራዎች መለኪያው ነባሪ የኢንቲጀር እሴት ስላለው።MAX_VALUE (2147483647)፣ የመልእክት መልሶ ማግኘቶች ቁጥር መላኪያ.timeout.ms ብቻ በመቀየር ማስተካከል ይቻላል።

ልክ አንድ ጊዜ ማድረስ ላይ እንገኛለን።

የተዘረዘሩት መቼቶች ፕሮዲውሰራችን ከፍተኛ ዋስትና ያለው መልእክት እንዲያደርስ ያስችለዋል። አሁን አንድ የመልእክት ቅጂ ለካፍካ ርዕስ መጻፉን እንዴት ማረጋገጥ እንደሚቻል እንነጋገር? በጣም ቀላል በሆነ ሁኔታ, ይህንን ለማድረግ, መለኪያውን በአምራች ላይ ማዘጋጀት ያስፈልግዎታል ማንቃት.idempotence ወደ እውነት። አለመቻል ለአንድ ርዕስ የተወሰነ ክፍል አንድ መልእክት ብቻ መጻፉን ያረጋግጣል። ራስን አቅምን ለማንቃት ቅድመ ሁኔታው ​​እሴቶቹ ናቸው። acks = ሁሉም፣ እንደገና ይሞክሩ > 0፣ max.in.flight.requests.per.connection ≤ 5. እነዚህ መለኪያዎች በገንቢው ካልተገለጹ, ከላይ ያሉት ዋጋዎች በራስ-ሰር ይቀናበራሉ.

አካላዊ አቅም ሲዋቀር ተመሳሳይ መልእክቶች በእያንዳንዱ ጊዜ በተመሳሳይ ክፍልፋዮች ውስጥ መጨረሳቸውን ማረጋገጥ ያስፈልጋል። ይህ partitioner.class ቁልፍ እና መለኪያውን ወደ ፕሮዲዩሰር በማቀናበር ሊከናወን ይችላል። በቁልፍ እንጀምር። ለእያንዳንዱ ግቤት ተመሳሳይ መሆን አለበት. ይህ ከዋናው ልጥፍ ውስጥ ማንኛውንም የንግድ መታወቂያ በመጠቀም በቀላሉ ማግኘት ይቻላል። partitioner.class መለኪያ ነባሪ እሴት አለው - ነባሪ ክፍልፋይ. በዚህ የመከፋፈል ስልት፣ በነባሪነት እንደዚህ እንሰራለን፡-

• መልእክቱን በሚልኩበት ጊዜ ክፋዩ በግልጽ ከተገለጸ, እንጠቀማለን.
• ክፋዩ ካልተገለጸ, ግን ቁልፉ ከተገለጸ, ክፋዩን በቁልፍ ሃሽ ይምረጡ.
• ክፋዩ እና ቁልፉ ካልተገለጹ ክፍሎቹን አንድ በአንድ ይምረጡ (ክብ-ሮቢን)።

እንዲሁም ቁልፍን እና ኢምፔርን በመጠቀም ከመለኪያ ጋር max.in.flight.requests.per.connection = 1 በተጠቃሚው ላይ የተሳለጠ የመልእክት ሂደት ይሰጥዎታል። እንዲሁም የመዳረሻ መቆጣጠሪያ በክላስተርዎ ላይ ከተዋቀረ ወደ አንድ ርዕስ በብቃት የመፃፍ መብቶች እንደሚያስፈልጉ ማስታወስ ጠቃሚ ነው።

በድንገት በቁልፍ የመላክ አቅም ከሌለዎት ወይም በአምራች በኩል ያለው አመክንዮ በተለያዩ ክፍፍሎች መካከል ያለውን የውሂብ ወጥነት መጠበቅን የሚጠይቅ ከሆነ ግብይቶች ወደ መዳን ይመጣሉ። በተጨማሪም፣ የሰንሰለት ግብይትን በመጠቀም፣ በካፍካ ውስጥ ያለ መዝገብ፣ ለምሳሌ በመረጃ ቋቱ ውስጥ ካለው መዝገብ ጋር በሁኔታዊ ሁኔታ ማመሳሰል ይችላሉ። ወደ ፕሮዲዩሰር መላክን ለማንቃት ኃይለኛ እና በተጨማሪነት የተዘጋጀ መሆን አለበት። ግብይት.መታወቂያ. የእርስዎ የካፍካ ክላስተር የመዳረሻ መቆጣጠሪያ ከተዋቀረ፣ የግብይት መዝገብ፣ ልክ እንደ ኢዲፖንት ሪከርድ፣ የመፃፍ ፍቃዶችን ይፈልጋል፣ ይህም በtransportal.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.

ይህንን ችግር ለመፍታት ከአካባቢ ተለዋዋጮች ያገኘነውን በአስተናጋጅ ስም በመተግበሪያው ስም ላይ ቅጥያ እንጨምራለን ።

አምራቹ ተዋቅሯል፣ ነገር ግን በካፍካ ላይ የሚደረጉ ግብይቶች የመልእክቱን ወሰን ብቻ ይቆጣጠራሉ። የግብይቱ ሁኔታ ምንም ይሁን ምን, መልእክቱ ወዲያውኑ ወደ ርዕሰ ጉዳዩ ይሄዳል, ነገር ግን ተጨማሪ የስርዓት ባህሪያት አሉት.

እንደዚህ አይነት መልዕክቶች በተጠቃሚው አስቀድሞ እንዳይነበቡ ለመከላከል መለኪያውን ማዘጋጀት ያስፈልገዋል ማግለል.ደረጃ የተገባ እሴት ለማንበብ እንደዚህ አይነት ሸማች እንደከዚህ ቀደሙ ሁሉ ከግብይት ውጪ የሆኑ መልእክቶችን እና የግብይት መልዕክቶችን ማንበብ የሚችለው ቃል ከገባ በኋላ ነው።
ቀደም ሲል የተዘረዘሩትን ሁሉንም መቼቶች ካዘጋጁ, አንድ ጊዜ ማድረስ በትክክል አዋቅረዋል. እንኳን ደስ አላችሁ!

ግን አንድ ተጨማሪ ልዩነት አለ. ከላይ ያዋቀርነው Transactional.id በትክክል የግብይት ቅድመ ቅጥያ ነው። በግብይት አስተዳዳሪው ላይ፣ ተከታታይ ቁጥር ተጨምሯል። የተቀበለው ለዪ ተሰጥቷል። ግብይት.መታወቂያ.ማለፊያ.ms, በካፍካ ክላስተር ላይ የተዋቀረ እና ነባሪ የ "7 ቀናት" እሴት አለው. በዚህ ጊዜ አፕሊኬሽኑ ምንም አይነት መልእክት ካልደረሰው ቀጣዩን የግብይት መላክ ሲሞክሩ ይቀበላሉ። ልክ ያልሆነ የPidMappingException. የግብይት አስተባባሪው ለቀጣዩ ግብይት አዲስ ተከታታይ ቁጥር ያወጣል። ሆኖም፣ InvalidPidMappingException በትክክል ካልተያዘ መልእክቱ ሊጠፋ ይችላል።

ከውጤቶች ይልቅ

እንደምታየው ወደ ካፍካ መልእክት መላክ ብቻ በቂ አይደለም። የመለኪያዎችን ጥምር መምረጥ እና ፈጣን ለውጦችን ለማድረግ ዝግጁ መሆን አለብዎት። በዚህ ጽሑፍ ውስጥ፣ በትክክል አንድ ጊዜ የመላኪያ መቼትን በዝርዝር ለማሳየት ሞከርኩ እና ያጋጠሙንን በደንበኛው.id እና በ‹transportal.id› አወቃቀሮች ላይ በርካታ ችግሮችን ገልጫለሁ። ከዚህ በታች የአምራች እና የሸማቾች ቅንጅቶች ማጠቃለያ አለ።

የአምራች:

1. acks = ሁሉም
2. ይሞክራል > 0
3. አንቃ.idempotence = እውነት
4. max.in.flight.requests.per.ግንኙነት ≤ 5 (1 በሥርዓት ለመላክ)
5. transactional.id = ${መተግበሪያ-ስም}-${አስተናጋጅ ስም}

ሸማች

1. isolation.level = read_committed

በወደፊት ትግበራዎች ላይ ስህተቶችን ለመቀነስ የራሳችንን መጠቅለያ በፀደይ ውቅረት ላይ አደረግን ፣ ለአንዳንድ የተዘረዘሩ ልኬቶች ቀድሞውኑ የተቀመጡ ናቸው።

እራስን ለማጥናት ሁለት ቁሳቁሶች እዚህ አሉ

• KIP-98 - በትክክል አንዴ መላኪያ እና የግብይት መልእክት
• የቅንብሮች መግለጫ

ምንጭ: hab.com