🥇 Билдирүү брокерлерин түшүнүү. ActiveMQ жана Kafka менен кабарлашуунун механикасын үйрөнүү. 3-бөлүм. Кафка

Чакан китептин котормосунун уландысы:
Билдирүү брокерлерин түшүнүү
автор: Якуб Кораб, басып чыгаруучу: O'Reilly Media, Inc., жарыяланган датасы: июнь 2017, ISBN: 9781492049296.

Мурунку которулган бөлүгү: Билдирүү брокерлерин түшүнүү. ActiveMQ жана Kafka менен кабарлашуунун механикасын үйрөнүү. 1-глава Киришүү

3-ГЛАВА

Татарча

Кафка LinkedIn тарабынан салттуу билдирүү брокерлеринин айрым чектөөлөрүн айланып өтүү жана ар кандай чекиттен чекитке өз ара аракеттенүү үчүн бир нече билдирүү брокерлерин орнотуудан качуу үчүн иштелип чыккан, бул китепте 28-беттеги "Масштабды жогорулатуу жана кичирейтүү" бөлүмүндө сүрөттөлөт. Колдонуу учурлары LinkedIn негизинен баракты чыкылдатуулар жана кирүү журналдары сыяктуу өтө чоң көлөмдөгү маалыматтарды бир тараптуу кабыл алууга таянган, ошол эле учурда ал маалыматтарды өндүрүүчүлөрдүн же башка керектөөчүлөрдүн өндүрүмдүүлүгүнө таасир этпестен бир нече системалар тарабынан колдонууга мүмкүндүк берет. Чындыгында, Кафканын бар болушунун себеби - Универсал маалымат түтүгү сүрөттөгөн билдирүүлөрдүн архитектурасын алуу.

Мына ушул түпкү максатты эске алганда, табигый түрдө башка талаптар да пайда болду. Кафка керек:

Абдан тез бол
Кабарлар менен иштөөдө көбүрөөк өткөрүү жөндөмдүүлүгүн камсыз кылыңыз
Publisher-Abonent жана Point-to-Point моделдерин колдоо
Керектөөчүлөрдү кошуу менен жайлатпаңыз. Мисалы, ActiveMQ ичиндеги кезектин да, теманын да иштеши бара турган жерде керектөөчүлөрдүн саны өскөн сайын начарлайт.
горизонталдуу масштабда болуу; эгер билдирүүлөр сакталып турган бир брокер муну максималдуу диск ылдамдыгында гана жасай алса, анда өндүрүмдүүлүктү жогорулатуу үчүн бир брокер инстанциясына өтүү мааниси бар.
Кабарларды сактоо жана кайра алуу мүмкүнчүлүгүн чектөө

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

Бирдиктүү көздөгөн модели

Жогоруда сүрөттөлгөн талаптарды аткаруу үчүн Кафка жарыялоо-жазылуу жана чекиттен чекитке билдирүүлөрдү бир түрдөгү көздөгөн жердин астында бириктирди - тема. Бул билдирүүлөр тутумдары менен иштеген адамдарды чаташтырат, мында "тема" деген сөз (темадан) окууга туруштук бере албаган берүү механизмин билдирет. Кафка темалары бул китептин кириш сөзүндө аныкталгандай, гибриддик багыт катары каралышы керек.

Бул бөлүмдүн калган бөлүгүндө, эгерде биз башкасын ачык айтпасак, "тема" термини Кафка темасына тиешелүү болот.

Темалар кандайча иштээрин жана алар кандай кепилдиктерди берерин толук түшүнүү үчүн алгач алардын Кафкада кантип ишке ашырылып жатканын карап чыгышыбыз керек.
Кафкадагы ар бир теманын өзүнүн журналы бар.
Кафкага билдирүү жөнөткөн продюсерлор бул журналга жазышат, ал эми керектөөчүлөр тынымсыз алдыга жылган көрсөткүчтөрдү колдонуп журналдан окушат. Мезгил-мезгили менен Кафка журналдын эң эски бөлүктөрүн өчүрүп турат, ал бөлүктөрдөгү билдирүүлөр окулганбы же окулганбы. Кафканын дизайнынын негизги бөлүгү - брокер билдирүүлөрдүн окулушу же окулбоосу маанилүү эмес - бул кардардын жоопкерчилиги.

"журнал" жана "көрсөткүч" деген терминдер жок Кафка документтери. Бул белгилүү терминдер түшүнүүгө жардам берүү үчүн бул жерде колдонулат.

Бул модель ActiveMQдан такыр башкача, мында бардык кезектердеги билдирүүлөр бир журналда сакталат жана брокер билдирүүлөрдү окулгандан кийин өчүрүлгөн деп белгилейт.
Эми бир аз тереңирээк казып, тема журналын кененирээк карап көрөлү.
Кафка журналы бир нече бөлүктөрдөн турат (3-1-сүрөт). Кафка ар бир бөлүмдө катуу тартипке кепилдик берет. Бул бөлүмгө белгилүү бир тартипте жазылган билдирүүлөр ошол эле тартипте окулат дегенди билдирет. Ар бир бөлүм камтылган жылма журнал файлы катары ишке ашырылат ички топтому анын өндүрүүчүлөрү тарабынан темага жөнөтүлгөн бардык билдирүүлөрдүн (подборщиктер). Түзүлгөн тема демейки боюнча бир бөлүмдү камтыйт. Бөлмөлөр идеясы Кафканын горизонталдуу масштабдоо үчүн негизги идеясы болуп саналат.

3-1-сүрөт. Кафка бөлүктөр

Продюсер Кафка темасына билдирүү жөнөткөндө, ал билдирүүнү кайсы бөлүмгө жөнөтүүнү чечет. Муну кийинчерээк кененирээк карап чыгабыз.

Билдирүүлөрдү окуу

Билдирүүлөрдү окугусу келген кардар аталган көрсөткүчтү башкарат керектөөчүлөр тобу, кайсыны көрсөтөт офсет бөлүмдөгү билдирүүлөр. Оффсет - бул бөлүмдүн башталышында 0дөн башталган кошумча позиция. API'де колдонуучу аныктаган group_id аркылуу шилтеме берилген бул керектөөчүлөр тобуна дал келет бир логикалык керектөөчү же система.

Көпчүлүк билдирүү системалары параллелдүү билдирүүлөрдү иштетүү үчүн бир нече инстанцияларды жана жиптерди колдонуу менен көздөгөн жерден маалыматтарды окушат. Ошентип, адатта, бир эле керектөөчүлөр тобун бөлүшкөн көптөгөн керектөөчүлөр болот.

Окуу проблемасын төмөнкүчө чагылдырууга болот:

Темада бир нече бөлүмдөр бар
Керектөөчүлөрдүн бир нече топтору бир эле учурда теманы колдоно алышат
Керектөөчүлөрдүн тобу бир нече өзүнчө инстанцияларга ээ болушу мүмкүн

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

Керектөөчүлөр жана керектөөчүлөр топтору

Баштапкы чекит катары бир бөлүмдөн турган теманы алалы (3-2-сүрөт).

3-2-сүрөт. Керектөөчү бөлүмдөн окуйт

Керектөөчү инстанция бул темага өзүнүн group_id менен туташканда, ага окуу бөлүмү жана ошол бөлүмдө офсет дайындалат. Бул офсеттин абалы кардарда эң акыркы абалга (эң жаңы билдирүү) же эң алгачкы позицияга (эң эски билдирүү) көрсөткүч катары конфигурацияланган. Керектөөчү темадан билдирүүлөрдү сурайт (сурамжылоо), бул аларды журналдан ырааттуу окууга алып келет.
Оффсеттик позиция дайыма Кафкага берилет жана ички темада билдирүүлөр катары сакталат _керектөөчүнүн_офсеттери. Кадимки брокерден айырмаланып, окулган билдирүүлөр дагы деле жок кылынбайт жана кардар мурунтан каралган билдирүүлөрдү кайра иштетүү үчүн офсетти артка түрө алат.

Экинчи логикалык керектөөчү башка group_id аркылуу туташканда, ал биринчиден көз карандысыз экинчи көрсөткүчтү башкарат (3-3-сүрөт). Ошентип, Кафка темасы бир керектөөчү бар кезек сыяктуу иштейт жана бир нече керектөөчүлөр жазылган кадимки жарыялоо-жазылуу (pub-sub) темасы сыяктуу, кошумча пайда менен бардык билдирүүлөр сакталып, бир нече жолу иштетилет.

3-3-сүрөт. Ар кандай керектөө топторундагы эки керектөөчү бир эле бөлүмдөн окушат

Керектөөчүлөр тобунда керектөөчүлөр

Бир керектөөчү инстанция бөлүмдөн маалыматтарды окуганда, ал көрсөткүчтү толук көзөмөлдөйт жана мурунку бөлүмдө сүрөттөлгөндөй билдирүүлөрдү иштетет.
Эгерде керектөөчүлөрдүн бир нече учурлары бир эле group_id менен бир бөлүм менен темага туташтырылган болсо, анда акыркы жолу кошулган инстанция көрсөткүчтү башкарууга ээ болот жана ошол учурдан тартып ал бардык билдирүүлөрдү алат (3-4-сүрөт).

3-4-сүрөт. Бир керектөөчүлөр тобунда эки керектөөчү бир эле бөлүмдөн окушат

Керектөөчү инстанциялардын саны бөлүмдөрдүн санынан ашкан иштетүүнүн бул режимин өзгөчө керектөөчү катары кароого болот. Бул сизге керектөөчү инстанцияларыңыздын "активдүү-пассивдүү" (же "ысык-жылы") кластерлешүүсү керек болсо, пайдалуу болушу мүмкүн, бирок бир нече керектөөчүлөрдү параллелдүү иштетүү («активдүү-активдүү» же «ысык-ысык») бир топ мүнөздүү. керектөөчүлөр Күтүү режиминде.

Жогоруда сүрөттөлгөн бул билдирүү таратуу жүрүм-туруму кадимки JMS кезеги менен салыштырганда таң калыштуу болушу мүмкүн. Бул моделде кезекке жөнөтүлгөн билдирүүлөр эки керектөөчүнүн ортосунда бирдей бөлүштүрүлөт.

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

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

Кафкада бул маселени чечүүнүн канондук жолу бОкөбүрөөк бөлүктөр.

Бөлүү

Бөлүмдөр бир брокер инстанциясынын өткөрүү жөндөмдүүлүгүнөн тышкары теманы окуунун жана масштабын параллелдештирүүнүн негизги механизми болуп саналат. Муну жакшыраак түшүнүү үчүн, эки бөлүктөн турган тема бар жана бир керектөөчү бул темага жазылган жагдайды карап көрөлү (3-5-сүрөт).

Сүрөт 3-5. Бир керектөөчү бир нече бөлүмдөн окуйт

Бул сценарийде керектөөчүгө эки бөлүмдө тең өзүнүн group_id идентификаторуна туура келген көрсөткүчтөрдү көзөмөлдөө берилет жана эки бөлүмдөн тең билдирүүлөрдү окуй баштайт.
Ушул эле group_id үчүн кошумча керектөөчү бул темага кошулганда, Кафка бөлүмдөрдүн бирин биринчиден экинчи керектөөчүгө кайра бөлүштүрөт. Андан кийин керектөөчүнүн ар бир инстанциясы теманын бир бөлүгүнөн окуйт (3-6-сүрөт).

Кабарлар 20 жипте параллелдүү иштетилишин камсыз кылуу үчүн, сизге жок дегенде 20 бөлүм керек. Бөлүмдөр азыраак болсо, сиз эксклюзивдүү керектөөчүлөрдүн талкуусунда айтылгандай, иштей турган эч нерсеси жок керектөөчүлөр менен каласыз.

3-6-сүрөт. Бир эле керектөөчү тобундагы эки керектөөчү ар башка бөлүктөрдөн окушат

Бул схема JMS кезегин сактоо үчүн зарыл болгон билдирүү бөлүштүрүүгө салыштырмалуу Кафка брокеринин татаалдыгын кыйла азайтат. Бул жерде сиз төмөнкү жагдайлар жөнүндө тынчсыздануунун кереги жок:

Кайсы керектөөчү тегерек-робин бөлүштүрүү, алдын ала жүктөө буферлеринин учурдагы сыйымдуулугу же мурунку билдирүүлөрдүн негизинде кийинки билдирүүнү алышы керек (JMS билдирүү топтору үчүн).
Кайсы билдирүүлөр кайсы керектөөчүлөргө жөнөтүлөт жана алар иштебей калган учурда кайра жеткирилиши керекпи.

Кафка брокери керектөөчү сураганда билдирүүлөрдү ырааттуу түрдө жөнөтүшү керек.

Бирок, текшерүүнү параллелдештирүүгө жана аткарылбай калган билдирүүлөрдү кайра жөнөтүүгө карата талаптар жоголбойт - алар үчүн жоопкерчилик жөн гана брокерден кардарга өтөт. Бул алар сиздин кодуңузда эске алынышы керек дегенди билдирет.

Билдирүүлөрдү жөнөтүү

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

JMSте биз метаберилиштер (башаттар жана касиеттер) жана пайдалуу жүктү (пайдалуу жүгүн) камтыган денеси бар билдирүү түзүмүн колдонсок, Кафкада билдирүү жуп "ачкыч-маани". Билдирүү жүктөө мааниси катары жөнөтүлөт. Ачкыч, экинчи жагынан, негизинен бөлүү үчүн колдонулат жана камтышы керек бизнес логикасы өзгөчө ачкычтиешелүү билдирүүлөрдү бир эле бөлүмгө коюу.

2-бөлүмдө биз онлайн букмекерлик сценарийин талкууладык, анда байланышкан окуялар бир керектөөчү тарабынан иреттелет:

Колдонуучунун каттоо эсеби конфигурацияланган.
Акча эсепке которулат.
Эсептен акча алуу коюм жасалат.

Ар бир окуя темага жарыяланган билдирүү болсо, анда табигый ачкыч аккаунттун идентификатору болот.
Кафка Продюсер API аркылуу билдирүү жөнөтүлгөндө, ал билдирүүнү жана Кафка кластеринин учурдагы абалын эске алып, билдирүү жөнөтүлүшү керек болгон бөлүмдүн идентификаторун кайтарып берүүчү бөлүм функциясына өткөрүлүп берилет. Бул функция Java'да Partitioner интерфейси аркылуу ишке ашырылат.

Бул интерфейс мындай көрүнөт:

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

Partitioner ишке ашыруу бөлүмдү аныктоо үчүн ачкычтын үстүнөн демейки жалпы максаттагы хэширлөө алгоритмин колдонот же ачкыч көрсөтүлбөсө, тегерек-робин. Бул демейки маани көпчүлүк учурларда жакшы иштейт. Бирок, келечекте сиз өзүңүздү жазгыңыз келет.

Өзүңүздүн бөлүү стратегияңызды жазуу

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

Мааниси банктык которуунун пайдалуу жүгү болгондуктан, биз бүтүндүгүн сактап калгыбыз келет, ачкычта колдонула турган маалымат структурасын аныктоодон башка аргабыз жок. Бөлүү үчүн аккаунттун идентификатору керек деп ойлосок, эсепке тиешелүү бардык билдирүүлөр ирети менен иштетилиши керек, биз төмөнкү 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);

Дароо белгилей кетүү керек, эки ыкма тең Future кайтарып берет, бул жөнөтүү операциясы дароо аткарылбай тургандыгын көрсөтөт. Натыйжада билдирүү (ProducerRecord) ар бир активдүү бөлүм үчүн жөнөтүү буферине жазылат жана Кафка кардар китепканасында фондо жип катары брокерге жөнөтүлөт. Бул укмуштуудай тездик менен иш кылганы менен, тажрыйбасыз колдонмо процесси токтоп калса, билдирүүлөрдү жоготуп коюшу мүмкүн дегенди билдирет.

Адаттагыдай эле, жөнөтүү операциясын аткаруунун баасы боюнча ишенимдүү кылуунун жолу бар. Бул буфердин өлчөмүн 0гө коюуга болот жана жөнөтүүчү тиркеме жипти брокерге билдирүү жөнөтүү аяктаганга чейин күтүүгө аргасыз болот, төмөнкүдөй:

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

Билдирүүлөрдү окуу жөнүндө көбүрөөк

Билдирүүлөрдү окуу кошумча татаалдыктарга ээ, алар жөнүндө божомолдоо керек. Кабарга жооп катары билдирүү угуучуну иштете алган JMS APIден айырмаланып, керектөөчү Кафка сурамжылоодо гана. Келгиле, ыкманы кененирээк карап көрөлү сурамжылоо()бул максатта колдонулат:

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

Методдун кайтарылган мааниси бир нече объектилерди камтыган контейнер структурасы керектөөчү рекорд мүмкүн болгон бир нече бөлүктөрдөн. керектөөчү рекорд өзү ал алынган бөлүм сыяктуу байланышкан метаберилиштер менен ачкыч-маани жуптары үчүн кармоочу объект болуп саналат.

2-бөлүмдө талкуулангандай, биз билдирүүлөр ийгиликтүү же ийгиликсиз иштетилгенден кийин эмне болорун эстен чыгарбашыбыз керек, мисалы, эгер кардар билдирүүнү иштете албаса же ал токтоп калса. JMSде бул тастыктоо режими аркылуу чечилген. Брокер же ийгиликтүү иштетилген билдирүүнү жок кылат, же чийки же жасалма билдирүүнү кайра жеткирет (транзакциялар колдонулган болсо).
Кафка такыр башкача иштейт. Корректордон өткөндөн кийин билдирүүлөр брокерде жок кылынбайт, ал эми иштебей калса эмне болот, бул корректордук коддун өзүнө жүктөлөт.

Жогоруда айтылгандай, керектөөчү тобу журналда офсет менен байланышкан. Бул офсет менен байланышкан журналдын абалы жооп катары бериле турган кийинки билдирүүгө туура келет сурамжылоо(). Бул офсеттин көбөйгөн учуру окуу үчүн чечүүчү мааниге ээ.

Мурда талкууланган окуу моделине кайрылсак, билдирүүнү иштетүү үч этаптан турат:

Окуу үчүн билдирүүнү алыңыз.
Кабарды иштетүү.
Кабарды ырастоо.

Кафка керектөөчүсү конфигурация опциясы менен келет 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()билдирүүлөрдү иштеп чыккандан кийин дароо бул буйрукту аткаруу менен.

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

Жалган билдирүүнү автоматтык түрдө артка кайтаруу. Керектөөчүлөр өздөрү билдирүүлөрдү кайра жеткирүү үчүн брокерге ишене албагандыктан, көйгөйлүү жүктөөлөрдөн жана резервдик үзгүлтүктөрдөн келип чыккан өзгөчөлүктөрдү чечиши керек.
Бир атомдук операцияда бир нече темага билдирүүлөрдү жөнөтүңүз. Бир аздан кийин көрө турганыбыздай, ар кандай темаларды жана бөлүмдөрдү башкаруу Кафка кластериндеги ар кандай машиналарда болушу мүмкүн, алар жөнөтүлгөндө транзакцияларды координациялабайт. Бул макала жазылып жаткан учурда КИП-98 менен муну мүмкүн кылуу үчүн кээ бир иштер аткарылды.
Бир темадан бир билдирүүнү окууну башка темага башка билдирүү жөнөтүү менен байланыштырыңыз. Кайрадан, Кафканын архитектурасы бир автобус катары иштеген көптөгөн көз карандысыз машиналардан көз каранды жана муну жашырууга эч кандай аракет жасалбайт. Мисалы, байланыштырууга мүмкүндүк бере турган API компоненттери жок керектөөчү и чыгаруучу транзакцияда. JMSде бул объект тарабынан камсыз кылынат жыйналышалардан жаралган MessageProducers и MessageConsumers.

Эгерде транзакцияларга таяна албасак, анда салттуу билдирүү системалары тарабынан берилгендерге жакыныраак семантиканы кантип бере алабыз?

Эгер керектөөчүнүн офсети билдирүү иштетилгенге чейин көбөйүшү мүмкүн болсо, мисалы, керектөөчүнүн кыйроосу учурунда, анда керектөөчүнүн анын керектөөчү тобу билдирүүнү өткөрүп жибербегендигин билүүгө эч кандай мүмкүнчүлүк жок. Ошентип, стратегиялардын бири - офсетти мурунку абалга кайтаруу. Kafka керектөөчү API бул үчүн төмөнкү ыкмаларды камсыз кылат:

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

ыкма издөө() ыкмасы менен колдонсо болот
ofsetsForTimes(Карта timetampsToSearch) өтмүштө кандайдыр бир белгилүү бир абалга кайтуу.

Кыскасы, бул ыкманы колдонуу мурда иштетилген кээ бир билдирүүлөр кайра окулуп, кайра иштетилет дегенди билдирет. Мунун алдын алуу үчүн, 4-бөлүмдө сүрөттөлгөндөй, мурда көрүлгөн билдирүүлөргө көз салуу жана кайталанмаларды жок кылуу үчүн idempotent окууну колдонсок болот.

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

Жеке байкоолор көрсөткөндөй, билдирүүлөрдүн интенсивдүүлүгү жогорулаган сайын ар бир жеке билдирүүнүн баасы төмөндөйт. Чоң билдирүүлөр жалпыланган түрдө каралып жатканда баалуу болот.

Жогорку жеткиликтүүлүк

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

Кафка кластери ар кандай серверлерде иштеген бир нече брокер инстанцияларынан турат. Кафка кадимки өз алдынча аппараттык жабдыкта иштөө үчүн иштелип чыккан, мында ар бир түйүн өзүнүн атайын сактагычына ээ. Тармакка тиркелген сактагычты (SAN) колдонуу сунушталбайт, анткени бир нече эсептөө түйүндөрү убакыт үчүн атаандаша алат.Ыэлектрондук сактоо интервалдары жана чыр-чатактарды жаратат.

Кафка ар дайым күйүк системасы. Көптөгөн ири Кафка колдонуучулары кластерлерин эч качан өчүрүшпөйт жана программалык камсыздоо ар дайым ырааттуу кайра ишке киргизүү менен жаңырып турат. Бул билдирүүлөр жана брокерлердин ортосундагы өз ара аракеттенүү үчүн мурунку версия менен шайкеш келүүсүнө кепилдик берүү менен жетишилет.

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

Негизги учурда, Кафка кластеринде төмөнкү касиеттерге ээ тема түзүлөт:

Бөлүмдөрдүн саны. Мурда талкуулангандай, бул жерде колдонулган так маани параллелдүү окуунун каалаган деңгээлине жараша болот.
Репликация фактору (фактор) кластердеги канча брокер инстанцияларында бул бөлүм үчүн журналдарды камтышы керектигин аныктайт.

Координациялоо үчүн ZooKeepers колдонуп, Кафка кластердеги брокерлер арасында жаңы бөлүмдөрдү адилеттүү бөлүштүрүүгө аракет кылат. Бул Контроллердин ролун аткарган бир гана инстанция тарабынан аткарылат.

Иш учурунда ар бир тема бөлүмү үчүн Controller брокерге ролдорду дайындоо лидер (жетекчи, агай, алып баруучу) жана жолдоочулары (эрдикчилер, кулдар, кол алдындагылар). Бул бөлүмдүн лидери катары иш алып барган брокер өндүрүүчүлөр тарабынан ага жөнөтүлгөн бардык билдирүүлөрдү кабыл алуу жана керектөөчүлөргө билдирүүлөрдү таратуу үчүн жооптуу. Билдирүүлөр тема бөлүгүнө жөнөтүлгөндө, алар ошол бөлүмдүн жолдоочуларынын ролун аткарган бардык брокер түйүндөрүнө көчүрүлөт. Бөлүм үчүн журналдарды камтыган ар бир түйүн деп аталат реплика. Брокер кээ бир бөлүмдөр үчүн лидер, башкалары үчүн жолдоочу катары чыга алат.

Жетекчинин бардык билдирүүлөрүн камтыган ээрчиүүчү чакырылат синхрондуу реплика (синхрондолгон абалда болгон реплика, синхрондогон реплика). Бөлүмдүн лидери катары иш алып барган брокер иштебей калса, ошол бөлүм үчүн жаңыртылган же шайкештештирилген каалаган брокер лидердин ролун ээлей алат. Бул укмуштуудай туруктуу дизайн.

Продюсер конфигурациясынын бир бөлүгү параметр болуп саналат acks, бул колдонмонун жиптери жөнөтүүнү улантуудан мурун канча реплика билдирүүнүн кабыл алынышын ырасташ керек экенин аныктайт: 0, 1 же бардыгы. деп коюлган болсо бардык, андан кийин билдирүү келип түшкөндө, лидер теманын жөндөөсү тарабынан аныкталган бир нече сигналдардан (анын ичинде өзү да) жазуунун ырастоолорун (тааныштырууларын) алгандан кийин, продюсерге ырастоо жөнөтөт. min.insync.replicas (демейки 1). Эгер билдирүү ийгиликтүү кайталана албаса, анда продюсер колдонмонун өзгөчөлүгүн ыргытат (NotEnoughReplicas же NotEnoughReplicasAfterAppend).

Кадимки конфигурация 3 репликация коэффициенти (1 лидер, ар бир бөлүмгө 2 жолдоочу) жана параметр менен теманы түзөт min.insync.replicas 2 деп коюлган. Бул учурда, кластер теманы бөлүүнү башкарган брокерлердин бирине кардар тиркемелерине таасир этпестен түшүп кетүүгө мүмкүндүк берет.

Бул бизди аткаруу менен ишенимдүүлүктүн ортосундагы мурунтан эле тааныш болгон соодалоого кайра алып келет. Репликация жолдоочулардан ырастоолорду (тааныштырууларды) күтүү үчүн кошумча убакыттын эсебинен ишке ашат. Бирок, ал параллелдүү иштегендиктен, жок дегенде үч түйүнгө репликация экиге бирдей көрсөткүчкө ээ (тармактын өткөрүү жөндөмдүүлүгүн колдонуунун өсүшүнө көңүл бурбай).

Бул репликация схемасын колдонуу менен Кафка операция менен дискке ар бир билдирүүнү физикалык түрдө жазуудан акылдуу түрдө качат. синхрондоштуруу(). Продюсер жөнөткөн ар бир билдирүү бөлүү журналына жазылат, бирок 2-бөлүмдө талкуулангандай, файлга жазуу алгач операциялык системанын буферинде аткарылат. Эгерде бул билдирүү башка Кафка инстанциясына репликацияланса жана анын эсинде болсо, лидердин жоголушу кабардын өзү жоголду дегенди билдирбейт - аны синхрондуу реплика кабыл алса болот.
Операция жасоодон баш тартуу синхрондоштуруу() Кафка билдирүүлөрдү эс тутумга жаза тургандай тез кабыл ала алат дегенди билдирет. Тескерисинче, эстутумду дискке канчалык узакка жууп албасаңыз, ошончолук жакшы. Ушул себептен улам, Кафка брокерлерине 64 ГБ же андан көп эстутум бөлүнүшү сейрек эмес. Бул эстутум колдонуу Кафканын бир эле инстанциясы кадимки билдирүү брокерине караганда миңдеген эсе ылдамыраак ылдамдыкта иштей алат дегенди билдирет.

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

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

натыйжалары

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

Мурунку которулган бөлүгү: Билдирүү брокерлерин түшүнүү. ActiveMQ жана Kafka менен кабарлашуунун механикасын үйрөнүү. 1-бөлүм

Котормо аткарылды: tele.gg/middle_java

Уландысы бар…

Сурамжылоого катталган колдонуучулар гана катыша алышат. Кирүү, өтүнөмүн.

Сиздин уюмда Кафка колдонулабы?

ошол
жок
Мурда колдонулчу, азыр жок
колдонууну пландап жатабыз

38 колдонуучу добуш берди. 8 колдонуучу добуш берүүдөн баш тартты.

Source: www.habr.com

Билдирүү брокерлерин түшүнүү. ActiveMQ жана Kafka менен кабарлашуунун механикасын үйрөнүү. 3-бөлүм. Кафка