Իրադարձահեն համակարգեր՝ Kafka, RabbitMQ և հերթեր

01Իրադարձություններ, հրամաններ և բրոքերներ

Հրամանը (command) ինչ-որ մեկին խնդրում է ինչ-որ բան անել՝ «ուղարկիր այս email-ը», «գանձիր այս քարտից»։ Այն ունի մեկ նախատեսված handler և կարող է մերժվել։ Իրադարձությունը (event) արձանագրում է արդեն տեղի ունեցած փաստ՝ «42 պատվերը վճարված է»։ Նրան չի հետաքրքրում, թե ով է լսում․ կարող է արձագանքել զրո կամ տասը consumer։ Սրանք խառնելը խնդիրներ է ստեղծում․ SendEmail անունով «իրադարձությունը» producer-ին կապում է մեկ consumer-ի։ Message broker-ը նրանց միջև փոստատունն է։ Producer-ները հաղորդագրություններ են հրապարակում նրանում, այն դրանք պահում է կայուն, և consumer-ները ստանում են դրանք իրենց տեմպով։ Եթե consumer-ը ընկած է, հաղորդագրությունները սպասում են։ Եթե տրաֆիկը կտրուկ աճում է, մեծանում է backlog-ը, այլ ոչ թե «հալվում» է տվյալների բազան։ Գինը ասինխրոնությունն է․ producer-ն այլևս չգիտի, թե երբ կամ արդյոք աշխատանքն արված է, ուստի պետք է մոնիթորինգ backlog-ների և ձախողումների համար։

• Հրաման՝ հրամայական, մեկ handler, կարող է ձախողվել («ReserveStock»)։
• Իրադարձություն՝ անցյալ ժամանակ, շատ handler-ներ, անփոփոխ փաստ («StockReserved»)։
• Բրոքեր՝ կայուն բուֆեր և ռաութեր producer-ների և consumer-ների միջև։

02Kafka՝ topic-ներ, partition-ներ, offset-ներ և consumer group-եր

Kafka-ն բաշխված append-only log է։ Հաղորդագրությունները գրվում են topic-ի մեջ, որը բաժանված է partition-ների. յուրաքանչյուր partition դասավորված հաջորդականություն է, որտեղ ամեն հաղորդագրություն ստանում է offset (իր դիրքի համարը)։ Նույն key-ով հաղորդագրությունները միշտ գնում են նույն partition, ուստի հերթականությունը երաշխավորված է ըստ key-ի (օրինակ՝ ըստ պատվերի ID-ի), երբեք՝ ամբողջ topic-ի մասշտաբով։ Consumer-ները միանում են consumer group-ի. Kafka-ն յուրաքանչյուր partition հանձնում է խմբի ճիշտ մեկ consumer-ի, այնպես որ partition-ների քանակը սահմանափակում է զուգահեռությունը։ Յուրաքանչյուր խումբ հետևում է իր commit արված offset-ներին, ինչը նշանակում է, որ շատ խմբեր (billing, analytics, search) կարդում են նույն topic-ը անկախ։ Հաղորդագրությունները կարդալիս չեն ջնջվում․ դրանք մնում են retention-ի ժամկետի կամ չափի ընթացքում, կամ compact են արվում՝ ամեն key-ի համար թողնելով վերջին արժեքը։ Kafka 4.0-ից սկսած կլաստերներն աշխատում են KRaft-ով՝ առանց ZooKeeper-ի, իսկ Kafka 4.2-ը ավելացրեց production-ready share group-եր՝ հերթի ոճով սպառման համար։

1# Create a topic: 6 partitions, 3 replicas, 7-day retention
2kafka-topics.sh --bootstrap-server localhost:9092 --create \
3  --topic orders.v1 --partitions 6 --replication-factor 3 \
4  --config retention.ms=604800000 --config min.insync.replicas=2
5 
6# Produce keyed messages (same key -> same partition -> ordered)
7kafka-console-producer.sh --bootstrap-server localhost:9092 \
8  --topic orders.v1 --property parse.key=true --property key.separator=:
9 
10# Inspect a consumer group: current offset, end offset and lag per partition
11kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
12  --describe --group billing-service

03RabbitMQ և Redis հերթեր

RabbitMQ-ն հաղորդագրությունների ռաութեր է։ Producer-ները հրապարակում են exchange-ում, որը հաղորդագրությունները binding-ների միջոցով ուղղորդում է հերթեր՝ direct (ճշգրիտ routing key), topic (պատերններ, ինչպես «order.*»), fanout (ամեն կապված հերթ) կամ headers։ Consumer-ները վերցնում են հաղորդագրությունները հերթերից և հաստատում (acknowledge) դրանք. չհաստատվածները կրկին առաքվում են, իսկ մերժվածները կարող են գնալ dead-letter exchange։ Հաստատվելուց հետո հաղորդագրությունն անհետանում է, ուստի RabbitMQ-ն աշխատանք առաքելու մասին է, ոչ թե պատմություն պահելու (նրա stream queue-երը ավելացնում են log-անման ռեժիմ, երբ replay է պետք)։ Այն փայլում է ըստ հաղորդագրության routing-ում, առաջնահերթություններում և request-reply-ում։ Redis-ի վրա հիմնված հերթերը, ինչպես BullMQ-ն (Node) կամ Laravel-ի հերթերը Redis դրայվերով, ամենաթեթև տարբերակն են՝ job-եր կրկնակի փորձերով, backoff-ով, ուշացումներով, rate limit-երով, պլանավորված և կրկնվող job-երով, բոլորը այն Redis-ի վրա, որը հավանաբար արդեն ունես։ Նրանց սահմանը կայունությունն ու մասշտաբն է․ Redis-ը տվյալները պահում է հիշողության մեջ, ուստի կարգավորիր persistence-ը և հերթին վերաբերվիր որպես job runner-ի, ոչ թե մշտական event store-ի։

04Առաքման երաշխիքները գործնականում

Ամեն բրոքեր առաջարկում է երեք երաշխիքների որոշակի համադրություն։ At-most-once՝ consumer-ը commit է անում մինչև մշակելը, ուստի crash-ը կորցնում է հաղորդագրությունը, բայց երբեք չի կրկնօրինակում. ընդունելի է մետրիկաների համար, հազվադեպ՝ բիզնես տվյալների։ At-least-once՝ consumer-ը մշակում է, հետո հաստատում. այդ երկուսի միջև crash-ը նշանակում է կրկնակի առաքում, ուստի կրկնօրինակներ լինում են։ Սա իրատեսական լռելյայն տարբերակն է համակարգերի մեծ մասի համար։ Exactly-once՝ յուրաքանչյուր հաղորդագրություն ազդում է արդյունքի վրա մեկ անգամ։ Kafka-ն դա աջակցում է Kafka-ի ներսում՝ idempotent producer-ներով և տրանզակցիաներով, երբ consumer-ները կարդում են միայն commit արված տվյալները, read-process-write pipeline-ների համար Kafka topic-ների միջև։ Հենց որ կողմնակի էֆեկտը դուրս է գալիս Kafka-ից (գրառում տվյալների բազայում, email, քարտից գանձում), դու վերադառնում ես at-least-once-ին և պետք է consumer-ը դարձնես idempotent․ պահիր մշակված հաղորդագրությունների ID-ները, օգտագործիր unique constraint-ներ կամ upsert-ներ և handler-ները նախագծիր այնպես, որ երկու անգամ գործարկելը ոչինչ չփոխի։

• Producer-ի կողմ՝ acks=all և idempotence-ը միացված (ժամանակակից Kafka կլիենտներում լռելյայն է)։
• Consumer-ի կողմ՝ offset-ները commit արա հաջող մշակումից հետո, ոչ թե առաջ։
• «Թունավոր» հաղորդագրություններ՝ կրկնիր backoff-ով, հետո տեղափոխիր dead-letter topic կամ հերթ։

05Սխեմաներ, տարբերակավորում և գործիքի ընտրություն

Իրադարձությունները հանրային պայմանագիր են, որը հաճախ կարդում են թիմեր, որոնց երբեք չես հանդիպի, ուստի նրանց ձևին վերաբերվիր API-ի պես։ Սխեմաները սահմանիր Avro-ով, Protobuf-ով կամ JSON Schema-ով, պահիր schema registry-ում և պարտադրիր համատեղելիության կանոններ․ ազատ ավելացրու ոչ պարտադիր դաշտեր, երբեք մի հեռացրու և մի փոխիր այն դաշտի իմաստը, որին consumer-ները հենվում են։ Կոտրող փոփոխությունների համար հրապարակիր իրադարձության նոր տեսակ կամ topic-ի նոր տարբերակ (orders.v2) և գործարկիր երկուսն էլ, մինչև consumer-ները միգրացվեն։ Յուրաքանչյուր հաղորդագրության մեջ ներառիր իրադարձության ID, տեսակ, տարբերակ, timestamp և էնթիթիի key։ Ընտրության համար․ Kafka՝ մեծ ծավալի հոսքերի, երկար retention-ի, replay-ի և շատ consumer group-երի համար, RabbitMQ՝ ճկուն routing-ի, առաջադրանքների բաշխման և ըստ հաղորդագրության acknowledgement-ի համար, Redis հերթեր, ինչպես BullMQ-ն՝ հավելվածի ֆոնային job-երի համար՝ կրկնակի փորձերով ու պլանավորմամբ, managed ծառայություններ (SQS, SNS, Pub/Sub, managed Kafka)՝ երբ չես ուզում բրոքերներն ինքդ սպասարկել։

06Durability-ն Kafka-ի ներսում․ ռեպլիկաներ, ISR և leader-ի ընտրություն

Յուրաքանչյուր partition ունի մեկ leader ռեպլիկա, որն ընդունում է գրառումները, և follower-ներ, որոնք պատճենում են այն։ In-sync replica set-ը (ISR) leader-ն է՝ գումարած այն follower-ները, որոնք հետ չեն մնում replica.lag.time.max.ms-ից ավելի։ acks=all-ի դեպքում producer-ը հաջողություն ստանում է միայն այն ժամանակ, երբ ընթացիկ ISR-ի բոլոր անդամներն ունեն գրառումը․ min.insync.replicas-ը սահմանում է, թե ISR-ը որքան կարող է փոքրանալ, մինչև գրառումները մերժվեն NotEnoughReplicas-ով։ Տարածված durable կարգավորումն է replication factor 3, min.insync.replicas 2 և acks=all․ մեկ broker կարող է ընկնել՝ առանց տվյալների կորստի և առանց գրառումների դադարի։ unclean.leader.election.enable-ը թող իր լռելյայն false արժեքով․ դրա միացումը թույլ է տալիս չհամաժամեցված ռեպլիկային դառնալ leader և լուռ կորցնել արդեն հաստատված հաղորդագրությունները՝ availability-ի դիմաց։ Ռեպլիկաները բաշխիր rack-երի կամ availability zone-երի միջև broker.rack-ով, որպեսզի մեկ zone-ի խափանումը չտանի բոլոր պատճենները։

• RF 3 + min.insync.replicas 2 + acks=all․ անվտանգ վերապրում է մեկ broker-ի կորուստը։
• Producer-ի idempotence-ը և acks=all-ը կլիենտի լռելյայն արժեքներ են Kafka 3.0-ից ի վեր։
• Unclean election-ը հաստատված տվյալները փոխանակում է availability-ի հետ․ թող այն անջատված։

07Rebalancing, նոր consumer պրոտոկոլը և մշակման կանգերը

Երբ consumer-ները միանում են, դուրս գալիս կամ crash լինում, partition-ները վերաբաշխվում են rebalance-ի ընթացքում։ Դասական պրոտոկոլը կարող էր կանգնեցնել ամբողջ խումբը․ cooperative-sticky assignment-ը դա նվազեցրեց, իսկ նոր սերնդի պրոտոկոլը (KIP-848), որը Kafka 4.0-ից ընդհանուր հասանելի է, assignment-ը տեղափոխում է broker-ի կողմի group coordinator և rebalance է անում ինկրեմենտալ։ Կլիենտները միանում են group.protocol=consumer-ով, իսկ խմբերը փոխարկվում են rolling upgrade-ի ընթացքում։ Երկու timeout կարևոր է։ session.timeout.ms-ը heartbeat-ների միջոցով հայտնաբերում է «մեռած» consumer-ին։ max.poll.interval.ms-ը հայտնաբերում է «կախված» consumer-ին․ եթե handler-ը poll կանչերի միջև ավելի երկար է տևում, consumer-ը հեռացվում է, նրա partition-ները տեղափոխվում են, և չcommit-ված batch-ը նորից մշակվում է այլ տեղում։ Այսպիսով դանդաղ handler-ները առաջացնում են կրկնվող աշխատանք և rebalance-ի «փոթորիկներ»։ Իջեցրու max.poll.records-ը, երկար աշխատանքը տար առանձին հերթ կամ մշակման ընթացքում pause արա partition-ները։

08Compaction, retention և replay մեծ մասշտաբով

Retention-ը կարող է լինել ըստ ժամանակի կամ չափի (delete policy) կամ ըստ key-ի (compact policy)։ Compaction-ը պահում է առնվազն վերջին գրառումը յուրաքանչյուր key-ի համար և ֆոնային ռեժիմում հեռացնում հները, ինչը topic-ը դարձնում է ընթացիկ վիճակի durable աղյուսակ․ հաճախորդների պրոֆիլներ, ապրանքների գներ, կոնֆիգուրացիա։ null արժեքով գրառումը tombstone է․ այն key-ը նշում է ջնջման համար և ինքն էլ հեռացվում է delete.retention.ms-ից հետո, ուստի դրանից ավելի հետ մնացած consumer-ները կարող են բաց թողնել ջնջումները։ Երկու policy-ների համադրումը պահում է վերջին արժեքը յուրաքանչյուր key-ի համար և միևնույն ժամանակ ժամկետանց է դարձնում շատ հին key-երը։ Replay-ը «գերուժն» է․ նոր consumer group-ը, որը սկսում է ամենավաղ offset-ից, պատմությունից վերակառուցում է read model։ Պլանավորիր դա․ վերակառուցումները կարող են տերաբայթներ կարդալ, ուստի սահմանափակիր դրանց արագությունը, տուր նրանց առանձին խումբ և համոզվիր, որ retention-ը երկար է քո ամենավատ իրատեսական վերականգնման ժամանակից։

1# A compacted topic holding the latest price per product
2kafka-topics.sh --bootstrap-server localhost:9092 --create \
3  --topic prices.v1 --partitions 12 --replication-factor 3 \
4  --config cleanup.policy=compact \
5  --config min.compaction.lag.ms=3600000 \
6  --config delete.retention.ms=86400000
7 
8# Rebuild a read model: new group, start from the beginning
9kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
10  --group search-indexer-v2 --topic prices.v1 \
11  --reset-offsets --to-earliest --execute

09Partition-ների քանակ, key skew և throughput-ի tuning

Partition-ները զուգահեռության և հերթականության միավորն են, ուստի դրանց քանակը որոշիր այն consumer զուգահեռության համար, որը սպասում ես մեկ-երկու տարի հետո, ոչ թե այսօր․ partition-ներ ավելացնելը հետագայում վերաքարտեզագրում է key-երը և փոփոխության ընթացքում կոտրում per-key հերթականությունը։ Չափազանց շատ partition-ներն էլ արժեք ունեն․ ավելի շատ բաց ֆայլեր, ավելի երկար leader election-ներ և ավելի շատ մետատվյալներ։ Մյուսներից շատ ավելի շատ տրաֆիկով key-ը ստեղծում է «տաք» partition, որը մեկ consumer պետք է մենակ սպասարկի։ Skew-ը շտկիր ավելի մանր key ընտրելով (order ID՝ customer ID-ի փոխարեն), եթե հերթականությունը կարևոր է միայն պատվերի սահմաններում, կամ հայտնի տաք key-ը «աղելով» մի քանի ենթա-key-երի միջև և downstream-ում միավորելով։ Առանց key-ի գրառումները բաշխվում են sticky partitioner-ով, որը լցնում է մեկ batch, նոր միայն անցնում հաջորդին։ Producer-ի կողմում linger.ms-ը և batch.size-ը մի քանի միլիվայրկյան latency-ն փոխանակում են շատ ավելի բարձր throughput-ի հետ, իսկ compression-ը (lz4 կամ zstd) կրճատում է ցանցի և դիսկի օգտագործումը։