ProHoster > Блог > Захиргаа > Мессежийн брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механикийг сурах. Бүлэг 3. Кафка

Мессежийн брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механикийг сурах. Бүлэг 3. Кафка

Жижиг номын орчуулгын үргэлжлэл:
Мессеж брокеруудыг ойлгох
зохиогч: Якуб Кораб, нийтлэгч: O'Reilly Media, Inc., хэвлэгдсэн огноо: 2017 оны 9781492049296-р сар, ISBN: XNUMX.

Өмнөх орчуулсан хэсэг: Мессежийн брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механикийг сурах. 1-р бүлэг Оршил

БҮЛЭГ 3

Kaфка

Кафкаг LinkedIn боловсруулсан бөгөөд уламжлалт мессеж брокеруудын зарим хязгаарлалтыг даван туулах, өөр өөр цэг хоорондын харилцан үйлчлэлд зориулж олон мессеж брокер тохируулах шаардлагагүй болохын тулд үүнийг энэ номонд 28-р хуудасны "Өсөх, багасгах" хэсэгт тайлбарласан болно. . Хэрэглэх тохиолдол LinkedIn нь хуудасны товшилт, хандалтын бүртгэл гэх мэт маш их хэмжээний өгөгдлийг нэг талын залгихад голлон тулгуурласан бөгөөд энэ өгөгдлийг үйлдвэрлэгчид болон бусад хэрэглэгчдийн бүтээмжид нөлөөлөхгүйгээр олон системд ашиглах боломжийг олгодог. Үнэндээ Кафка оршин тогтнож байгаа шалтгаан нь Universal Data Pipeline-д тодорхойлсон мессежийн архитектурыг олж авах явдал юм.

Энэхүү эцсийн зорилгыг харгалзан үзвэл бусад шаардлага аяндаа гарч ирэв. Кафка хийх ёстой:

  • Маш хурдан байх
  • Мессежтэй ажиллахдаа илүү их зурвасын өргөнөөр хангах
  • Publisher-Subscriber болон Point-to-Point загваруудыг дэмжинэ
  • Хэрэглэгч нэмэхдээ удаашрах хэрэггүй. Жишээлбэл, ActiveMQ дээрх дараалал болон сэдвийн гүйцэтгэл нь очих газрын хэрэглэгчдийн тоо өсөх тусам буурдаг.
  • Хэвтээ байдлаар өргөтгөх боломжтой байх; Хэрэв мессеж хэвээр байгаа нэг брокер үүнийг зөвхөн дискний хамгийн дээд хурдаар л хийх боломжтой бол гүйцэтгэлийг нэмэгдүүлэхийн тулд нэг брокерын жишээнээс цааш явах нь зүйтэй юм.
  • Мессежийг хадгалах, дахин сэргээх хандалтыг хязгаарлах

Энэ бүхэнд хүрэхийн тулд Кафка үйлчлүүлэгч болон мессежийн брокеруудын үүрэг, хариуцлагыг дахин тодорхойлсон архитектурыг баталсан. JMS загвар нь брокерын чиг баримжаатай бөгөөд брокер нь мессеж түгээх үүрэгтэй бөгөөд үйлчлүүлэгчид зөвхөн мессеж илгээх, хүлээн авах талаар санаа зовох ёстой. Харин Кафка нь үйлчлүүлэгч төвтэй бөгөөд үйлчлүүлэгч нь маш хурдан бөгөөд өргөн цар хүрээтэй брокерын оронд холбогдох мессежийг хэрэглэгчдэд шударга хүргэх гэх мэт уламжлалт брокерын олон шинж чанарыг өөртөө авдаг. Уламжлалт мессежийн системтэй ажиллаж байсан хүмүүсийн хувьд Кафкатай ажиллах нь сэтгэлгээний үндсэн өөрчлөлтийг шаарддаг.
Энэхүү инженерийн чиглэл нь ердийн брокертой харьцуулахад дамжуулалтыг олон удаа нэмэгдүүлэх чадвартай мессежийн дэд бүтцийг бий болгоход хүргэсэн. Бидний харж байгаагаар энэ арга нь харилцан тохиролцсоны дагуу ирдэг бөгөөд энэ нь Кафка нь тодорхой төрлийн ажлын ачаалал болон суулгасан програм хангамжид тохиромжгүй гэсэн үг юм.

Очих газрын нэгдсэн загвар

Дээр дурдсан шаардлагуудыг биелүүлэхийн тулд Кафка нийтлэх-захиалах, цэгээс-цэг рүү илгээх мессежийг нэг төрлийн очих газар дор нэгтгэсэн. сэдэв. Энэ нь мессежийн системтэй ажиллаж байсан хүмүүсийг төөрөлдүүлж байгаа бөгөөд "сэдэв" гэдэг үг нь (сэдвээс) уншихад тэсвэргүй өргөн нэвтрүүлгийн механизмыг хэлдэг. Энэ номын оршил хэсэгт тодорхойлсон Кафкагийн сэдвүүдийг эрлийз очих газар гэж үзэх нь зүйтэй.

Энэ бүлгийн үлдсэн хэсэгт, хэрэв бид өөрөөр заагаагүй бол "сэдэв" гэсэн нэр томъёо нь Кафкагийн сэдэвтэй холбоотой байх болно.

Сэдвүүд хэрхэн ажилладаг, ямар баталгаа өгч байгааг бүрэн ойлгохын тулд эхлээд Кафка дээр хэрхэн хэрэгжиж байгааг харах хэрэгтэй.
Кафкагийн сэдэв бүр өөрийн гэсэн бүртгэлтэй байдаг.
Кафка руу мессеж илгээж буй үйлдвэрлэгчид энэ бүртгэлд бичдэг бөгөөд хэрэглэгчид байнга урагшилдаг заагч ашиглан бүртгэлээс уншдаг. Үе үе Кафка бүртгэлийн хамгийн эртний хэсгүүдийг устгадаг, тэдгээр хэсгүүдэд байгаа мессежүүд уншсан эсэхээс үл хамааран устгадаг. Кафкагийн дизайны гол хэсэг бол брокер нь мессежийг уншсан эсэхээс үл хамаарна - энэ нь үйлчлүүлэгчийн үүрэг юм.

"Лог" болон "заагч" гэсэн нэр томъёо энд харагдахгүй байна Кафкагийн баримт бичиг. Эдгээр сайн мэддэг нэр томъёог ойлгоход туслах зорилгоор энд ашигладаг.

Энэ загвар нь ActiveMQ-аас огт өөр бөгөөд бүх дарааллын мессежүүд нэг бүртгэлд хадгалагддаг бөгөөд брокер нь уншсаны дараа мессежийг устгасан гэж тэмдэглэдэг.
Одоо бага зэрэг гүнзгийрүүлж, сэдвийн бүртгэлийг илүү нарийвчлан харцгаая.
Кафкагийн бүртгэл нь хэд хэдэн хуваалтаас бүрдэнэ (Зураг 3-1). Кафка хуваалт бүрт хатуу дарааллыг баталгаажуулдаг. Энэ нь хуваалт руу тодорхой дарааллаар бичигдсэн мессежийг ижил дарааллаар уншина гэсэн үг юм. Хуваалт бүрийг агуулсан гулсмал бүртгэлийн файл хэлбэрээр хэрэгждэг дэд олонлог (дэд багц) нь түүний үйлдвэрлэгчдээс сэдэв рүү илгээсэн бүх мессеж. Үүсгэсэн сэдэв нь анхдагчаар нэг хуваалтыг агуулна. Хуваалтын санаа нь Кафкагийн хэвтээ масштабын гол санаа юм.

Мессежийн брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механикийг сурах. Бүлэг 3. Кафка
Зураг 3-1. Кафка хуваалтууд

Продюсер Кафкагийн сэдэв рүү мессеж илгээхдээ аль хэсэг рүү мессеж илгээхээ шийддэг. Үүнийг бид дараа нь илүү дэлгэрэнгүй авч үзэх болно.

Зурвас уншиж байна

Зурвасуудыг уншихыг хүссэн үйлчлүүлэгч нь нэртэй заагчийг удирддаг хэрэглэгчийн бүлэг, аль нь зааж байна офсет хуваалт дахь мессежүүд. Офсет гэдэг нь хуваалтын эхэнд 0-ээс эхэлдэг өсөлтийн байрлал юм. Хэрэглэгчийн тодорхойлсон group_id-ээр дамжуулан API-д иш татсан энэ хэрэглэгчийн бүлэг нь тохирч байна нэг логик хэрэглэгч эсвэл систем.

Ихэнх мессежийн системүүд мессежийг зэрэгцүүлэн боловсруулахын тулд олон тохиолдлууд болон хэлхээг ашиглан очих газраас өгөгдлийг уншдаг. Тиймээс ихэвчлэн ижил хэрэглэгчийн бүлгийг хуваалцдаг олон хэрэглэгчийн тохиолдол байх болно.

Унших асуудлыг дараах байдлаар илэрхийлж болно.

  • Сэдэв нь олон хуваалттай
  • Хэрэглэгчдийн хэд хэдэн бүлэг сэдвийг нэгэн зэрэг ашиглаж болно
  • Хэрэглэгчдийн бүлэг хэд хэдэн тусдаа тохиолдолтой байж болно

Энэ бол өчүүхэн бус олон-олон асуудал юм. Кафка хэрэглэгчийн бүлгүүд, хэрэглэгчийн инстанцууд болон хуваалтуудын хоорондын харилцааг хэрхэн зохицуулдгийг ойлгохын тулд аажмаар илүү төвөгтэй унших хувилбаруудыг авч үзье.

Хэрэглэгчид ба хэрэглэгчдийн бүлэг

Эхлэх цэг болгон нэг хэсэгтэй сэдвийг авч үзье (Зураг 3-2).

Мессежийн брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механикийг сурах. Бүлэг 3. Кафка
Зураг 3-2. Хэрэглэгч хуваалтаас уншдаг

Хэрэглэгчийн инстанц энэ сэдэвтэй өөрийн group_id-тай холбогдох үед түүнд унших хуваалт болон уг хуваалт дахь офсет оноогдсон байна. Энэ офсетийн байрлалыг үйлчлүүлэгчид хамгийн сүүлийн байрлал (хамгийн шинэ мессеж) эсвэл хамгийн эртний байрлал (хамгийн эртний мессеж) руу заагч болгон тохируулах боломжтой. Хэрэглэгч тухайн сэдвээс мессеж авах хүсэлт (санал асуулга) явуулдаг бөгөөд энэ нь тэдгээрийг бүртгэлээс дараалан уншихад хүргэдэг.
Оффсет байрлалыг байнга Кафка руу буцаан өгч, дотоод сэдэвт мессеж хэлбэрээр хадгалдаг _хэрэглэгчийн_офсет. Уншсан мессежүүд нь ердийн брокероос ялгаатай нь устгагдаагүй хэвээр байгаа бөгөөд үйлчлүүлэгч аль хэдийн үзсэн мессежийг дахин боловсруулахын тулд офсетийг буцааж болно.

Хоёрдахь логик хэрэглэгч өөр group_id ашиглан холбогдох үед энэ нь эхний (Зураг 3-3). Тиймээс, Кафкагийн сэдэв нь нэг хэрэглэгчтэй дараалал шиг ажилладаг ба олон хэрэглэгчид бүртгүүлдэг энгийн нийтлэгдэх-захиалах (pub-sub) сэдэв шиг ажилладаг бөгөөд бүх мессежийг хадгалж, олон удаа боловсруулах боломжтой байдаг.

Мессежийн брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механикийг сурах. Бүлэг 3. Кафка
Зураг 3-3. Өөр өөр хэрэглэгчийн бүлгүүдийн хоёр хэрэглэгч нэг хуваалтаас уншдаг

Хэрэглэгчийн бүлэгт багтдаг хэрэглэгчид

Нэг хэрэглэгчийн инстанц нь хуваалтаас өгөгдлийг унших үед заагчийг бүрэн удирдаж, өмнөх хэсэгт тайлбарласны дагуу мессежийг боловсруулдаг.
Хэрэглэгчдийн хэд хэдэн тохиолдлуудыг нэг хэсэгтэй сэдэвтэй ижил group_id-тэй холбосон бол хамгийн сүүлд холбогдсон инстанц нь заагч дээрх хяналтыг өгөх бөгөөд тэр мөчөөс эхлэн бүх мессежийг хүлээн авах болно (Зураг 3-4).

Мессежийн брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механикийг сурах. Бүлэг 3. Кафка
Зураг 3-4. Нэг хэрэглэгчийн бүлгийн хоёр хэрэглэгч нэг хуваалтаас уншдаг

Хэрэглэгчийн тохиолдлын тоо нь хуваалтын тооноос давсан боловсруулалтын энэ горимыг онцгой хэрэглэгч гэж үзэж болно. Хэдийгээр олон хэрэглэгчийг зэрэгцүүлэн ажиллуулах ("идэвхтэй-идэвхтэй" эсвэл "халуун-халуун") нь ердийнхөөс хамаагүй ердийн зүйл боловч танд "идэвхтэй-идэвхгүй" (эсвэл "халуун-халуун") хэрэглэгчийн инстанцуудыг нэгтгэх шаардлагатай бол энэ нь ашигтай байж болно. хэрэглэгчид. Хүлээлгийн горимд.

Дээр тайлбарласан энэхүү мессежийг түгээх үйлдэл нь ердийн JMS дараалал хэрхэн ажилладагтай харьцуулахад гайхалтай байж болох юм. Энэ загварт дараалалд илгээсэн мессежийг хоёр хэрэглэгчийн хооронд жигд хуваарилах болно.

Ихэнх тохиолдолд бид хэрэглэгчдийн олон тохиолдлыг үүсгэхдээ мессежийг зэрэгцүүлэн боловсруулах, унших хурдыг нэмэгдүүлэх эсвэл унших үйл явцын тогтвортой байдлыг нэмэгдүүлэхийн тулд үүнийг хийдэг. Нэг удаад зөвхөн нэг хэрэглэгчийн инстанц нь хуваалтаас өгөгдлийг уншиж чаддаг тул Кафка үүнийг хэрхэн хийдэг вэ?

Үүнийг хийх нэг арга бол нэг хэрэглэгчийн жишээг ашиглан бүх мессежийг уншиж, урсгалын сан руу дамжуулах явдал юм. Энэ арга нь боловсруулалтын хурдыг нэмэгдүүлэхийн зэрэгцээ хэрэглэгчийн логикийн нарийн төвөгтэй байдлыг нэмэгдүүлж, унших системийн бат бөх байдлыг нэмэгдүүлэхийн тулд юу ч хийдэггүй. Хэрэв цахилгааны тасалдал эсвэл үүнтэй төстэй үйл явдлын улмаас хэрэглэгчийн нэг хуулбар унтарвал хасах үйлдлийг зогсооно.

Кафкагийн энэ асуудлыг шийдэх каноник арга бол bОилүү олон хуваалтууд.

Хуваалт

Хуваалтууд нь нэг брокерын жишээний зурвасын өргөнөөс давсан сэдвийг унших, масштаблах үндсэн механизм юм. Үүнийг илүү сайн ойлгохын тулд хоёр хуваалттай сэдэв байгаа бөгөөд нэг хэрэглэгч энэ сэдвийг захиалсан нөхцөл байдлыг авч үзье (Зураг 3-5).

Мессежийн брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механикийг сурах. Бүлэг 3. Кафка
Зураг 3-5. Нэг хэрэглэгч олон хуваалтаас уншдаг

Энэ хувилбарт хэрэглэгч хоёр хуваалт дахь өөрийн group_id-д харгалзах заагчийг хянах эрхийг өгч, хоёр хуваалтаас мессеж уншиж эхэлнэ.
Энэ сэдэвт ижил group_id-д зориулсан нэмэлт хэрэглэгч нэмэгдэхэд Кафка хуваалтуудын аль нэгийг эхний хэрэглэгчээс хоёр дахь хэрэглэгч рүү дахин хуваарилдаг. Үүний дараа хэрэглэгчийн тохиолдол бүр сэдвийн нэг хэсгээс унших болно (Зураг 3-6).

Зурвасуудыг 20 хэлхээнд зэрэгцүүлэн боловсруулахын тулд танд дор хаяж 20 хуваалт хэрэгтэй. Хэрэв хуваалтууд цөөхөн байвал онцгой хэрэглэгчдийн талаар өмнө дурдсанчлан ажиллах зүйлгүй хэрэглэгчид үлдэх болно.

Мессежийн брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механикийг сурах. Бүлэг 3. Кафка
Зураг 3-6. Нэг хэрэглэгчийн бүлгийн хоёр хэрэглэгч өөр өөр хуваалтаас уншдаг

Энэ схем нь JMS-ийн дарааллыг хадгалахад шаардагдах мессежийн хуваарилалттай харьцуулахад Кафка брокерын нарийн төвөгтэй байдлыг ихээхэн бууруулдаг. Энд та дараах зүйлсийн талаар санаа зовох хэрэггүй болно.

  • Тойргийн хуваарилалт, урьдчилан ачаалах буферын одоогийн багтаамж эсвэл өмнөх мессежүүд (JMS мессежийн бүлгүүдийн хувьд) дээр үндэслэн аль хэрэглэгч дараагийн мессежийг хүлээн авах ёстой.
  • Аль хэрэглэгчдэд ямар мессеж илгээгдэж, алдаа гарсан тохиолдолд дахин хүргэх шаардлагатай эсэх.

Кафка брокерын хийх ёстой зүйл бол хэрэглэгч нь хүссэн мессежийг хэрэглэгч рүү дараалан дамжуулах явдал юм.

Гэсэн хэдий ч алдаатай мессежийг шалгах, дахин илгээх зэрэгт тавигдах шаардлагууд арилдаггүй - тэдгээрийн хариуцлагыг брокероос үйлчлүүлэгчид шилжүүлдэг. Энэ нь таны кодонд тэдгээрийг харгалзан үзэх ёстой гэсэн үг юм.

Зурвас илгээх

Аль хэсэг рүү мессеж илгээхээ шийдэх нь тухайн мессежийн үйлдвэрлэгчийн үүрэг юм. Үүнийг хийх механизмыг ойлгохын тулд эхлээд бид яг юу илгээж байгаагаа анхаарч үзэх хэрэгтэй.

JMS-д бид мета өгөгдөл (толгой ба шинж чанарууд) бүхий мессежийн бүтцийг ашигладаг бол ачаа (ачаа) агуулсан биетийг ашигладаг бол Кафка дахь мессеж нь "түлхүүр-утга"-г хослуулах. Мессежийн ачааллыг утга болгон илгээдэг. Нөгөө талаас түлхүүрийг хуваахад голчлон ашигладаг бөгөөд заавал байх ёстой бизнесийн логик тодорхой түлхүүрХолбогдох зурвасуудыг нэг хэсэгт оруулах.

2-р бүлэгт бид холбогдох үйл явдлуудыг нэг хэрэглэгч дарааллаар нь боловсруулах шаардлагатай онлайн бооцооны хувилбарын талаар ярилцав.

  1. Хэрэглэгчийн бүртгэл тохируулагдсан байна.
  2. Мөнгө дансанд орно.
  3. Данснаас мөнгө авах бооцоо тавьдаг.

Хэрэв үйл явдал бүр сэдэвт нийтэлсэн мессеж бол байгалийн түлхүүр нь дансны ID байх болно.
Kafka Producer API ашиглан мессежийг илгээх үед энэ нь тухайн зурвас болон Кафка кластерын одоогийн төлөвийг харгалзан хуваалтын функцэд дамжуулагддаг бөгөөд мессежийг илгээх ёстой хуваалтын ID-г буцаадаг. Энэ функцийг Java хэл дээр Partitioner интерфейсээр дамжуулан хэрэгжүүлдэг.

Энэ интерфэйс дараах байдлаар харагдаж байна.

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

Partitioner хэрэгжүүлэлт нь хуваалтыг тодорхойлохын тулд түлхүүр дээр ерөнхий зориулалтын өгөгдмөл алгоритмыг ашигладаг, эсвэл ямар ч түлхүүр заагаагүй бол round-robin ашигладаг. Энэ анхдагч утга нь ихэнх тохиолдолд сайн ажилладаг. Гэсэн хэдий ч ирээдүйд та өөрөө бичихийг хүсэх болно.

Өөрийнхөө хуваах стратегийг бичих

Мета өгөгдлийг мессежийн ачааллын хамт илгээхийг хүссэн жишээг харцгаая. Бидний жишээн дээрх ачаалал нь тоглоомын дансанд мөнгө байршуулах заавар юм. Заавар гэдэг нь дамжуулалтанд өөрчлөлт орохгүй байх баталгааг өгөхийг хүсч буй зүйл бөгөөд зөвхөн итгэмжлэгдсэн дээд систем энэ зааварчилгааг эхлүүлж чадна гэдэгт итгэлтэй байхыг хүсдэг. Энэ тохиолдолд илгээх болон хүлээн авах систем нь мессежийг баталгаажуулахын тулд гарын үсэг ашиглах талаар тохиролцдог.
Энгийн JMS-д бид зүгээр л "мессежийн гарын үсэг" шинж чанарыг тодорхойлж, мессеж рүү нэмнэ. Гэсэн хэдий ч Кафка бидэнд мета өгөгдөл дамжуулах механизмыг өгдөггүй, зөвхөн түлхүүр ба утгыг өгдөг.

Үнэ цэнэ нь бидний бүрэн бүтэн байдлыг хадгалахыг хүсч буй банкны шилжүүлгийн ачаалал учраас түлхүүрт ашиглах өгөгдлийн бүтцийг тодорхойлохоос өөр сонголт бидэнд байхгүй. Бүртгэлтэй холбоотой бүх мессежийг дарааллаар нь боловсруулах ёстой тул хуваахад дансны ID хэрэгтэй гэж үзвэл бид дараах JSON бүтцийг гаргаж ирнэ.

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

Гарын үсгийн утга нь ачааллаас хамаарч өөр өөр байх тул Partitioner интерфейсийн анхдагч хэшлэх стратеги нь холбогдох мессежүүдийг найдвартай бүлэглэхгүй. Тиймээс бид энэ түлхүүрийг задлан шинжилж, accountId утгыг хуваах стратегиа бичих хэрэгтэй болно.

Кафка нь дэлгүүрт байгаа мессежийн эвдрэлийг илрүүлэх хяналтын нийлбэрийг багтаасан бөгөөд хамгаалалтын бүрэн багц функцтэй. Гэсэн хэдий ч дээр дурдсан гэх мэт салбарын тусгай шаардлага заримдаа гарч ирдэг.

Хэрэглэгчийн хуваах стратеги нь холбогдох бүх мессежүүд нэг хуваалтад дуусахыг баталгаажуулах ёстой. Хэдийгээр энэ нь энгийн мэт боловч холбогдох мессежийг захиалахын ач холбогдол, тухайн сэдэв дэх хуваалтын тоог хэр тогтоодог зэргээс шалтгаалан шаардлага нь төвөгтэй байж болно.

Сэдвийн хуваалтуудын тоо цаг хугацааны явцад өөрчлөгдөж болох тул ачаалал нь эхний хүлээлтээс давсан тохиолдолд нэмж болно. Тиймээс мессежийн түлхүүрүүд нь анх илгээсэн хуваалттай холбоотой байж болох бөгөөд энэ нь үйлдвэрлэгчийн тохиолдлуудын хооронд хуваалцах төлөвийг илэрхийлдэг.

Анхаарах өөр нэг хүчин зүйл бол мессежийг хуваалтуудаар жигд хуваарилах явдал юм. Ихэвчлэн товчлуурууд нь мессежүүдэд жигд тархдаггүй бөгөөд хэш функц нь цөөн тооны товчлуурын хувьд мессежийг шударга хуваарилах баталгаа болдоггүй.
Мессежийг хуваахаар сонгосон хэдий ч тусгаарлагчийг дахин ашиглах шаардлагатай гэдгийг анхаарах нь чухал юм.

Газарзүйн өөр өөр байршил дахь Кафка кластеруудын хооронд өгөгдлийг хуулбарлах шаардлагыг авч үзье. Энэ зорилгоор Кафка нь MirrorMaker хэмээх командын мөрийн хэрэгсэлтэй ирдэг бөгөөд үүнийг нэг кластераас мессеж уншиж, нөгөө рүү шилжүүлэхэд ашигладаг.

Хоёр кластерт тухайн сэдвийн хуваалтын тоо ижил биш байж болох тул кластеруудын хооронд хуулбарлах үед мессеж хоорондын харьцангуй дарааллыг хадгалахын тулд MirrorMaker нь хуулбарласан сэдвийн түлхүүрүүдийг ойлгох ёстой.

Өгөгдмөл хэшинг эсвэл дугуй эргэлт нь ихэнх тохиолдолд сайн ажилладаг тул тусгай хуваах стратеги нь харьцангуй ховор байдаг. Гэсэн хэдий ч, хэрэв танд захиалгын хүчтэй баталгаа шаардлагатай эсвэл ачааллаас мета өгөгдлийг гаргаж авах шаардлагатай бол хуваалт нь таны анхааралтай авч үзэх ёстой зүйл юм.

Кафкагийн өргөтгөх чадвар, гүйцэтгэлийн давуу тал нь уламжлалт брокерын зарим үүрэг хариуцлагыг үйлчлүүлэгч рүү шилжүүлснээр ирдэг. Энэ тохиолдолд зэрэгцээ ажиллаж байгаа хэд хэдэн хэрэглэгчдийн дунд холбоотой байж болзошгүй мессежийг түгээх шийдвэр гаргана.

JMS брокерууд ч гэсэн ийм шаардлагыг шийдвэрлэх хэрэгтэй. Сонирхолтой нь, JMS Message Groups-ээр хэрэгждэг ижил хэрэглэгч рүү холбогдох мессежийг илгээх механизм (наалдамхай ачааллын тэнцвэржүүлэх (SLB) стратегийн хувилбар) нь илгээгчээс мессежийг холбоотой гэж тэмдэглэхийг шаарддаг. JMS-ийн хувьд брокер нь энэ бүлэг холбоотой мессежийг олон хэрэглэгчээс нэг хэрэглэгч рүү илгээх, хэрэв хэрэглэгч унавал группын өмчлөлийг шилжүүлэх үүрэгтэй.

Үйлдвэрлэгчийн гэрээ

Мессеж илгээхдээ зөвхөн хуваах нь анхаарах зүйл биш юм. Java API дахь Producer ангийн 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();

Хэрэв та "дор хаяж нэг удаа" гэсэн мессежийг боловсруулахыг хүсвэл офсетийг гараар хийх ёстой commitSync()мессежийг боловсруулсны дараа шууд энэ тушаалыг гүйцэтгэх замаар.

Эдгээр аргууд нь мессежийг боловсруулахаас өмнө хүлээн зөвшөөрөхийг зөвшөөрдөггүй, гэхдээ тэдгээр нь гүйлгээтэй мэт харагдахын зэрэгцээ боловсруулалтын саатлыг арилгахын тулд юу ч хийдэггүй. Кафкад ямар ч гүйлгээ байхгүй. Үйлчлүүлэгч дараахь зүйлийг хийх чадваргүй.

  • Хуурамч мессежийг автоматаар буцаах. Мессежийг дахин хүргэхийн тулд брокерт найдах боломжгүй тул хэрэглэгчид өөрсдөө асуудалтай ачаалал болон арын хэсгийн тасалдлаас үүссэн онцгой тохиолдлуудыг шийдвэрлэх ёстой.
  • Нэг атомын үйл ажиллагаанд олон сэдэвт мессеж илгээх. Бидний удахгүй харах болно, өөр өөр сэдэв, хуваалтуудыг хянах нь Кафка кластерт илгээсэн үед гүйлгээг зохицуулдаггүй өөр өөр машинууд дээр байж болно. Үүнийг бичиж байх үед KIP-98-ийн тусламжтайгаар үүнийг хийх боломжтой болгохын тулд зарим ажил хийгдсэн.
  • Нэг сэдвээс нэг мессеж уншихыг өөр сэдэв рүү өөр мессеж илгээхтэй холбоно. Дахин хэлэхэд Кафкагийн архитектур нь нэг автобус шиг ажилладаг олон бие даасан машинуудаас хамаардаг бөгөөд үүнийг нуух гэж оролддоггүй. Жишээлбэл, танд холбохыг зөвшөөрөх API бүрэлдэхүүн байхгүй байна хэрэглэгч и Үйлдвэрлэгч гүйлгээнд. JMS-д үүнийг объектоор хангадаг хуралдаанүүнээс бий болсон Мессеж үйлдвэрлэгчид и Хэрэглэгчид мессеж илгээх.

Хэрэв бид гүйлгээнд найдаж чадахгүй бол уламжлалт мессежийн системээр хангагдсан семантикийг хэрхэн яаж өгөх вэ?

Хэрэглэгчийн эвдрэлийн үед гэх мэт мессежийг боловсруулахаас өмнө хэрэглэгчийн офсет нэмэгдэх магадлал байгаа бол хэрэглэгч өөрийн бүлэгт хуваалт өгөх үед мессежийг алдсан эсэхийг мэдэх боломжгүй болно. Тиймээс нэг стратеги бол офсетийг өмнөх байрлал руу буцаах явдал юм. Кафка хэрэглэгчийн API нь үүнд дараах аргуудыг өгдөг:

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

арга хайх() аргаар хэрэглэж болно
ofsetsForTimes(Газрын зураг Хайлт хийх цагийн тэмдэг) өнгөрсөн үеийн тодорхой нэг цэгийн төлөв рүү буцах.

Энэ аргыг ашиглах нь өмнө нь боловсруулсан зарим мессежийг уншиж, дахин боловсруулах магадлал өндөр байна гэсэн үг юм. Үүнээс зайлсхийхийн тулд 4-р бүлэгт тайлбарласны дагуу бид өмнө нь үзсэн мессежүүдийг хянаж, давхардлыг арилгахын тулд idempotent унших аргыг ашиглаж болно.

Эсвэл мессеж алдагдах эсвэл давхардсан тохиолдолд таны хэрэглэгчийн кодыг энгийн байлгах боломжтой. Бүртгэлийн үйл явдлуудыг зохицуулах, хэмжигдэхүүн, товшилтыг хянах гэх мэт Кафкагийн түгээмэл хэрэглэгддэг хэрэглээний тохиолдлуудыг авч үзэхэд бид бие даасан мессежийг алдах нь эргэн тойрон дахь програмуудад мэдэгдэхүйц нөлөө үзүүлэхгүй гэдгийг бид ойлгож байна. Ийм тохиолдолд анхдагч утгууд нь бүрэн хүлээн зөвшөөрөгддөг. Нөгөөтэйгүүр, хэрэв таны өргөдөл төлбөрөө илгээх шаардлагатай бол мессеж бүрийг анхааралтай авч үзэх хэрэгтэй. Энэ бүхэн контекстээс хамаарна.

Хувийн ажиглалтаас харахад мессежийн эрч хүч нэмэгдэх тусам мессеж бүрийн үнэ цэнэ буурдаг. Том мессежийг нэгтгэсэн хэлбэрээр үзэхэд үнэ цэнэтэй байх хандлагатай байдаг.

Өндөр хүртээмжтэй

Кафкагийн өндөр хүртээмжтэй байх хандлага нь ActiveMQ-ийн арга барилаас тэс өөр юм. Кафка нь бүх брокерын инстанцууд нэгэн зэрэг мессеж хүлээн авч түгээдэг томруулсан кластеруудыг тойрон бүтээгдсэн.

Кафка кластер нь өөр өөр сервер дээр ажилладаг олон брокерын жишээнээс бүрдэнэ. Кафка нь энгийн бие даасан техник хангамж дээр ажиллахаар зохион бүтээгдсэн бөгөөд зангилаа бүр өөрийн гэсэн хадгалах сантай байдаг. Олон тооны тооцооллын цэгүүд цаг хугацааны төлөө өрсөлдөж чаддаг тул сүлжээнд холбогдсон санах ойг (SAN) ашиглахыг зөвлөдөггүй.Ыe хадгалах интервал болон зөрчил үүсгэх.

Кафка бол үргэлж систем. Кафкагийн олон томоохон хэрэглэгчид хэзээ ч кластераа хаадаггүй бөгөөд програм хангамж нь дараалсан дахин асаалтаар үргэлж шинэчлэгддэг. Энэ нь брокеруудын хоорондох мессеж, харилцан үйлчлэлийн өмнөх хувилбартай нийцэж байгаа эсэхийг баталгаажуулснаар хүрдэг.

Серверийн кластерт холбогдсон брокерууд Амьтны хүрээлэнгийн ажилтан, энэ нь тохиргооны өгөгдлийн бүртгэлийн үүрэг гүйцэтгэдэг бөгөөд брокер бүрийн үүргийг зохицуулахад ашиглагддаг. ZooKeeper нь өөрөө түгээх систем бөгөөд мэдээллийн хуулбарлах замаар өндөр хүртээмжтэй байх боломжийг олгодог. чуулга.

Үндсэн тохиолдолд Кафка кластерт дараах шинж чанаруудтай сэдвийг үүсгэдэг.

  • Хуваалтын тоо. Өмнө дурьдсанчлан, энд ашигласан яг утга нь зэрэгцээ уншихыг хүссэн түвшингээс хамаарна.
  • Хуулбарлах хүчин зүйл (хүчин зүйл) нь кластер дахь брокерын хэдэн тохиолдол энэ хуваалтын бүртгэлийг агуулж байхыг тодорхойлдог.

Зохицуулах зорилгоор ZooKeepers-ийг ашиглан Кафка кластер дахь брокеруудын дунд шинэ хуваалтыг шударгаар хуваарилахыг оролддог. Үүнийг Controller-ийн үүрэг гүйцэтгэдэг нэг инстанц хийдэг.

Ажиллах үед сэдэв хуваалт бүрийн хувьд Хянагч брокерт үүрэг хуваарилах удирдагч (удирдагч, мастер, хөтлөгч) ба дагалдагчид (дагагчид, боолууд, захирагчид). Брокер нь энэ хуваалтын удирдагчийн үүрэг гүйцэтгэдэг бөгөөд үйлдвэрлэгчдээс түүнд илгээсэн бүх мессежийг хүлээн авч, хэрэглэгчдэд мессежийг түгээх үүрэгтэй. Мессежийг сэдвийн хуваалт руу илгээх үед тэдгээр нь тухайн хуваалтын дагалдагчаар ажилладаг бүх брокерын зангилаа руу хуулбарлагдана. Хуваалтын бүртгэлийг агуулсан зангилаа бүрийг дууддаг хуулбар. Брокер нь зарим хуваалтуудад удирдагч болж, заримд нь дагагч болж чаддаг.

Удирдагчийн эзэмшдэг бүх мессежийг агуулсан дагагчийг дуудна синхрончлогдсон хуулбар (синхрончлогдсон төлөвт байгаа хуулбар, синхрончлогдсон хуулбар). Хэрэв хуваалтын удирдагчийн үүрэг гүйцэтгэгч брокер ажиллахаа больсон тохиолдолд тухайн хуваалтын хувьд шинэчлэгдсэн эсвэл синхрончлогдсон аливаа брокер удирдагчийн үүргийг гүйцэтгэж болно. Энэ бол гайхалтай тогтвортой загвар юм.

Үйлдвэрлэгчийн тохиргооны нэг хэсэг нь параметр юм акк, энэ нь аппликешны хэлхээг үргэлжлүүлэн илгээхээс өмнө мессежийг хүлээн авсныг хүлээн зөвшөөрөх (хүлээн зөвшөөрөх) ёстойг тодорхойлдог: 0, 1 эсвэл бүгд. Хэрэв тохируулсан бол бүх, дараа нь мессеж хүлээн авсны дараа удирдагч сэдвийн тохиргоогоор тодорхойлсон хэд хэдэн дохионоос (өөрийгөө оруулаад) бичлэгийн баталгааг (хүлээн зөвшөөрлийг) хүлээн авмагц продюсер руу баталгаажуулалтыг илгээнэ. min.insync.replicas (өгөгдмөл 1). Хэрэв мессежийг амжилттай хуулбарлах боломжгүй бол продюсер нь програмын онцгой тохиолдол гаргах болно (NotEnoughReplicas буюу NotEnoughReplicasAfterAppend).

Ердийн тохиргоо нь хуулбарлах хүчин зүйл нь 3 (1 удирдагч, хуваалт бүрт 2 дагагч) болон параметртэй сэдвийг үүсгэдэг. min.insync.replicas 2 гэж тохируулсан. Энэ тохиолдолд кластер нь сэдвийн хуваалтыг удирдаж буй брокеруудын аль нэгийг үйлчлүүлэгчийн програмуудад нөлөөлөхгүйгээр доош буулгах боломжийг олгоно.

Энэ нь биднийг гүйцэтгэл ба найдвартай байдлын хоорондох аль хэдийн танил болсон солилцоонд буцааж авчирдаг. Хуулбарлах нь дагагчдаас баталгаажуулах (хүлээн зөвшөөрөх) нэмэлт хүлээх хугацаа зардлаар хийгддэг. Хэдийгээр энэ нь зэрэгцээ ажилладаг тул дор хаяж гурван зангилаа руу хуулбарлах нь хоёртой ижил гүйцэтгэлтэй байдаг (сүлжээний зурвасын өргөн ашиглалтын өсөлтийг үл тоомсорлодог).

Энэхүү хуулбарлах схемийг ашигласнаар Кафка мэссэж бүрийг диск рүү физикээр бичих шаардлагаас ухаалгаар зайлсхийдэг. синк(). Үйлдвэрлэгчийн илгээсэн мессеж бүр нь хуваалтын бүртгэлд бичигдэх боловч 2-р бүлэгт авч үзсэнчлэн файл руу бичих нь эхлээд үйлдлийн системийн буферт хийгддэг. Хэрэв энэ мессежийг өөр Кафкагийн жишээнд хуулбарласан бөгөөд түүний санах ойд байгаа бол удирдагчийг алдсан нь мессеж өөрөө алдагдсан гэсэн үг биш юм - үүнийг синхрончлогдсон хуулбараар авах боломжтой.
Мэс засал хийхээс татгалзах синк() Энэ нь Кафка мессежийг санах ойд бичиж чадахуйц хурдан хүлээн авах боломжтой гэсэн үг юм. Эсрэгээр, санах ойг диск рүү угаахаас зайлсхийх тусам сайн. Энэ шалтгааны улмаас Кафкагийн брокеруудад 64 ГБ ба түүнээс дээш санах ой хуваарилах нь ердийн зүйл биш юм. Энэхүү санах ойн хэрэглээ нь нэг Кафка жишээ нь уламжлалт мессеж брокероос олон мянган дахин хурдан хурдан ажиллах боломжтой гэсэн үг юм.

Мөн Кафка үйлдлийг хэрэгжүүлэхээр тохируулж болно синк() мессежийн багц руу. Кафка дахь бүх зүйл багцад чиглэсэн байдаг тул энэ нь олон төрлийн хэрэглээнд маш сайн ажилладаг бөгөөд маш хүчтэй баталгаа шаарддаг хэрэглэгчдэд хэрэгтэй хэрэгсэл юм. Кафкагийн цэвэр гүйцэтгэлийн ихэнх хэсэг нь брокер руу пакет хэлбэрээр илгээгдсэн мессежүүдээс ирдэг бөгөөд эдгээр мессежийг брокероос дараалсан блокуудыг ашиглан уншдаг. тэг хуулбар үйлдлүүд (нэг санах ойн хэсгээс нөгөө рүү өгөгдлийг хуулах даалгаврыг гүйцэтгэдэггүй үйлдлүүд). Сүүлийнх нь том гүйцэтгэл, нөөцийн ашиг бөгөөд зөвхөн хуваалтын схемийг тодорхойлсон үндсэн бүртгэлийн өгөгдлийн бүтцийг ашиглах замаар л боломжтой юм.

Нэг Кафка брокероос илүү сайн гүйцэтгэлийг Кафка кластерт хийх боломжтой, учир нь сэдвийн хуваалтууд нь олон тусдаа машинууд дээр өргөжин тэлж чаддаг.

Үр дүн

Энэ бүлэгт бид Кафкагийн архитектур нь ердийн мессеж брокероос хэд дахин илүү дамжуулах чадвар бүхий гайхалтай бат бөх мессеж дамжуулах шугамыг хангахын тулд үйлчлүүлэгч болон брокеруудын хоорондын харилцааг хэрхэн шинэчлэн төсөөлж байгааг харлаа. Бид үүнд хүрэхийн тулд ашигладаг функцүүдийн талаар ярилцаж, энэ функцийг хангадаг програмуудын архитектурыг товч авч үзсэн. Дараагийн бүлэгт бид мессеж бичихэд суурилсан програмуудыг шийдвэрлэхэд шаардлагатай нийтлэг асуудлуудыг авч үзэж, тэдгээрийг шийдвэрлэх стратегийн талаар ярилцах болно. Мессежийн технологийн талаар ерөнхийд нь хэрхэн ярихыг тайлбарласнаар бид бүлгийг төгсгөх бөгөөд ингэснээр та тэдгээрийн хэрэглээний тохиолдлуудад тохирох эсэхийг үнэлэх болно.

Өмнөх орчуулсан хэсэг: Мессеж брокеруудыг ойлгох. ActiveMQ болон Кафка ашиглан мессеж бичих механизмд суралцах. 1-р бүлэг

Орчуулга хийгдсэн: tele.gg/middle_java

Үргэлжлэл бий…

Зөвхөн бүртгэлтэй хэрэглэгчид санал асуулгад оролцох боломжтой. Нэвтрэх, гуйя.

Танай байгууллагад Кафка ашигладаг уу?

  • Тийм

  • Ямар ч

  • Өмнө нь хэрэглэж байсан, одоо ашиглахгүй

  • Бид ашиглахаар төлөвлөж байна

38 хэрэглэгч санал өгсөн. 8 хэрэглэгч түдгэлзсэн.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх