შეტყობინებების ბროკერები

1) რატომ არის ბროკერები

• მწვერვალების ბუფერიზაცია და გაბრტყელება, ზურგჩანთა.
• კითხვის/ჩაწერის მასშტაბები დამოუკიდებლად.
• მოვლენების დაკვირვება და რეპროდუქცია.
• არქიტექტურული ნიმუშები: ღონისძიების დისკი, CQRS, ღონისძიების დახურვა, გარე/ინბოქსი.

2) ძირითადი მოდელები და ტერმინები

2. 1 კაფკა (დენის მოდელი)

წვეულების ტოპიკა (შეკვეთილი ლოგოები) - ოფსეტური კონსიუმერები.
Consumer Group: კითხვის პარალელიზმი, პარტიების დაბალანსება.
დროის/მოცულობის ჭრა; Compaction გასაღები.
სემანტიკა: მინიმალური - at-least-once, პარამეტრებით - effectively exactly-once (idempotent მწარმოებლები + გარიგებები).
ბრძანება: გარანტირებულია პარტიის შიგნით.

2. 2 NATS (თემები/სუბჯექტები, დაბალი შეფერხება)

Subject (თემა) იერარქიით და უაილდკარტებით ('foo.', 'foo. >`).
რეჟიმები: pub/sub, queue-groups (მუშაობის განაწილების გულშემატკივარი), request-reply (სწრაფი RPC).
Core NATS - ეფემერული, ულტრა დაბალი ლატენტობა; JetStream - პერსონაჟი/retence/გამეორება/გამეორება.
ბრძანება: საუკეთესო ძალისხმევა, ძლიერი გლობალური გარანტიის გარეშე; JetStream- ით - ნაკადის მოწესრიგება, მაგრამ იშვიათი ხელახალი ჩარევა შესაძლებელია უარის თქმის დროს.

3) მიწოდებისა და კოორდინაციის სემანტიკა

Idempotence და dedup არის განაცხადის/ლურჯი პასუხისმგებლობა, თუნდაც Kafka- ს „exactly-once“ - ში.

4) შეკვეთა, განაწილება და გასაღებები

Kafka

კომუნიკაციის გასაღების არჩევა განსაზღვრავს პარტიას, როგორც ძლიერ ადგილობრივ წესრიგს.
Ключи: `aggregate_id`, `tenant_id`, `order_id`. მოერიდეთ ცხელ კლავიშებს.
ბალანსი: N მხარეები - კითხვის პარალელიზმის დონე.

NATS

Core- ში ბალანსი აკეთებს queue ჯგუფს.
JetStream Stream- ში, subjects subjects; ყურადღება გამახვილებულია ფართო გულშემატკივართა/გულშემატკივართა მოკლე დაგვიანებით.

5) Retenschn, replay და Compaction

Kafka

Retention: `retention. ms/bytes`.
Compaction: ინახავს „ბოლო მნიშვნელობას გასაღებით“ (შესაფერისია snapshots/kashes/sag).
Replay: ნებისმიერ კონსერვატორს შეუძლია „ამოიღოს“ ოფსეტები.

JetStream

Streams: ფაილური/Memory Backends, შენახვის პოლიტიკა დროის/ბაიტის/col შეტყობინებების შესახებ.
Consumers: pull/push, durable/ephemeral, subject პრეფიქსი ფილტრი.
Replay: redelivery ან კითხვა დასაწყისიდან/offset-like (sequence).

6) გარიგებები, გარიგებები და კოორდინაცია

Kafka

Idempotent Producer (`enable. idempotence = ნამდვილი '): დაცვა დუბლებისგან.
Transactions: რამდენიმე ნაწილის ატომური ჩანაწერი + consumer-offsets - შაბლონების შაბლონების შაბლონების გარეშე „ხვრელების“ გარეშე.
Transactional Outbox: ბიზნეს ღონისძიების ჩაწერა და გარე ხაზები ერთ BD გარიგებაში, ქურდი ქვეყნდება კაფკაში.

NATS

არ არსებობს „ურთიერთსაწინააღმდეგო“ გარიგებები, როგორც კაფკაში; გამოიყენეთ outbox/inbox და idempotent კონსიუმერები (გასაღებები, დედაპლატი).

7) RPC და მოთხოვნა-პასუხი

კაფკა RPC- სთვის არასასიამოვნოა (მაღალი overhead, შეკვეთა/პასუხები უფრო რთულია). გამოიყენეთ ასინქრონული ბრძანებები/მოვლენები.
NATS: იდეალურია request-reply (milisecunds, კორელაცია, ტაიმაუტები).

go resp, err:= nc. Request("profile. get", []byte(`{"id":42}`), 200time. Millisecond)

8) ოპერაცია და ტოპოლოგია

8. 1 Kafka

მტევანი: ბროკერები + ZooKeeper (ძველ ვერსიებამდე) ან KRaft (ახალი მეტამონაცემი).
რეპლიკაცია: RF - 3 ზონების მიხედვით, ISR/კონტროლერები.
მულტირეგიონი: MirrorMaker 2/Cluster Linking; აქტივი/აქტივი აქტივები კონფლიქტურ პოლიტიკოსებთან.
დისკის/ქსელის შესაძლებლობები: ჩაითვალოს 'throughput × retention × replicas'.

8. 2 NATS

Cluster: მრავალი კვანძი, super-cluster (განაწილება), leafnodes პერიფერიისთვის/edge.
JetStream: ნაკადის განთავსება კვანძების ნაკრებების გასწვრივ, რეპლიკაცია (R = 1.. 5).
WAN: პროგნოზირებადი დაბალი შეფერხებები, მსუბუქი ფედერაცია.

9) უსაფრთხოება

Kafka

TLS (mTLS), SASL: SCRAM, OAuthBearer.
ACL ტოპიკა/ჯგუფები/გარიგებები.
დაშიფვრა „მარტო“ (OS/დისკი) + ქსელის პოლიტიკა.

NATS

nkey/JWT იდენტურობა, ოპერატორის ანგარიშები, ple-subject ACL.
mTLS კვანძებსა და მომხმარებლებს შორის.
მოიჯარეების იზოლაცია (აკონტები) + ლიმიტები.

10) დაკვირვება და ოპერაციული მეტრიკა

Kafka

Брокер: `BytesIn/Out`, `RequestQueue`, `UnderReplicatedPartitions`, GC/FS stats.
ტოპიკური/წვეულება: 'logEndOffset', consumer lag (კრიტიკულად).
პროდიუსერი/კონსიუმერი: retrai, 'batch. size`, `linger. ms`, `fetch. min. bytes ', შეცდომები.
ინსტრუმენტები: JMX, Cruise Control (პრო ბალანსი), Schema Registry.

NATS/JetStream

სერვერი: conn/msgs/sec, RTT, CPU/mem, slow consumer დეტექტივი.
JetStream: per stream/consumer — lag, redeliveries, acks, storage bytes.
მონიტორინგი: ჩაშენებული endpoint, nsc/adm-CLI, დაშბორდები.

11) პროდუქტიულობა და ტიუნინგი

Kafka

დიდი ბრძოლები და „ხაზოვანი“. ms 'აუმჯობესებს throughput- ს და შეკუმშავს p99.
კომპრესია (lz4/zstd) დაზოგავს ქსელს/დისკს.
num. წვეულებები მომხმარებელთა/ბირთვების რაოდენობის მიხედვით, მაგრამ არა გადალახვა (overhead).
დისკები: NVMe სასურველია, XFS/EXT4 'ნოატიმი'.

NATS

მცირე შეტყობინებები, მრავალი კავშირი ნორმაა; შეინარჩუნეთ queue groups „ფართო“.
JetStream: tune `max_ack_pending`, pull vs push, size of batches.
Backpressure: `FlowControl`, `IdleHeartbeat`, server-side limits.

12) ინტეგრაციის ნიმუშები

Outbox/Inbox (როგორც Kafka- ში, ასევე NATS- ში).
SAGA: მოვლენების ორკესტრი; დედაპაპი 'saga _ id + step'.
Change Data Capture (CDC): Debezium → Kafka; NATS- ში არის შაბლონი „გამომცემელი BD ტრიგერების/ლოგებისგან“.
Stream processing: Kafka Streams/Flink/Spark; NATS- ში - მესამე მხარის პროცესორები/ფუნქციები, JetStream consumers.
Dead Letter Queue (DLQ) და retry პოლიტიკა (ექსპონენციალური backoff + jitter).

13) კონფიგურაციის მაგალითები

13. 1 კაფკა: ტოპიკის შექმნა და პროდიუსერი

bash kafka-topics. sh --create --topic orders \
--partitions 12 --replication-factor 3 \
--config cleanup. policy=delete \
--config retention. ms=604800000 # 7d

properties producer. properties bootstrap. servers=broker:9092 acks=all enable. idempotence=true batch. size=65536 linger. ms=10 compression. type=zstd

13. 2 Kafka Streams: idempotent დამუშავება (ესკიზი)

java builder. <String, Order>stream("orders")
.groupByKey()
.aggregate(/... /)
.toStream()
.to("orders-agg");

13. 3 NATS JetStream: stream + consumer (nats CLI)

bash nats stream add ORDERS --subjects "orders. " --retention limits \
--storage file --max-bytes 100GB --replicas 3 --discard old

nats consumer add ORDERS ORDERS-WORKERS --filter "orders. created" \
--deliver pull --ack explicit --max-deliver 6 --backoff "1s,5s,30s,2m"

13. 4 NATS Request-Reply (Go)

go nc, _:= nats. Connect("tls://nats:4222", nats. Secure(tlsConf))
sub, _:= nc. QueueSubscribe("calc. sum", "workers", func(m nats. Msg) {
//... process...
m. Respond([]byte("42"))
})

14) Kafka vs NATS არჩევანი: სწრაფი სახელმძღვანელო

ჩვენ გვჭირდება ხელნაკეთობა, გრძელი რეტინული, კომპაქტური, მძიმე ნაკადის პროცესები - კაფკა.
ჩვენ გვჭირდება სწრაფი RPC, გულშემატკივარი/გულშემატკივარი მიკროლატენტობით, მარტივი ოპერაცია, edge/IoT-NATS (Core).
ჩვენ გვჭირდება პერსონიფიკაცია + გულშემატკივართა, მაგრამ მძიმე „დენის“ პლატფორმის გარეშე - NATS JetStream.
საკვანძო და გარიგების მკაცრი შეკვეთაა Kafka.

15) ტევადობის დაგეგმვა (გამარტივებული)

Kafka

1. საგუშაგო: 'inbound _ MBps × RF × retention _ days × 86400' დისკები.
2. ნაწილები: 'target _ concurrency' × რეზერვი 1. 5–2×.
3. ქსელი: p99 + რეპლიკაცია + კომპრესიის მწარმოებელი.

NATS/JetStream

1. შეტყობინებები/წმ და საშუალო ზომა throughput.
2. Retention×replicas → storage.
3. Consumers (ack-pending, redeliveries), CPU სერიალიზაციისთვის.

16) უსაფრთხო ოპერაცია: შემოწმების სია

• TLS/mTLS ჩართულია, საიდუმლოებები იბეჭდება.
• ACL/ანგარიშები/კვოტები (per-tenant).
• Idempotention Consumers, DLQ და retrai ერთად jitter.
• lag/throughput/შეცდომების მონიტორინგი; ალერტები URP (Kafka), redelivery-ქარიშხალი (NATS).
• Capacity dashboards: ნაწილები, სცენა, p99.
• ტესტები კვანძების/ზონის, თამაშის დღეების, რაფლის/ზურგჩანთა.
• დოკუმენტირებულია განაწილებისა და სქემების გასაღებები (Schema Registry/JSON Schema).
• retenshing/Compactions პოლიტიკოსები/TTL შეთანხმდნენ შესაბამისობასთან.
• ბროკერების/მომხმარებლების ვერსიები რეგულარულად განახლებულია; შემოწმებულია wire პროტოკოლის თავსებადობა.

17) ანტი შაბლონები

ცხელი გასაღები (ერთი ID- ის ყველა მოვლენა) არის ერთი „მდუღარე“ ნაკადი. Shardiruite/bulbulibulize.
Retrai idempotence - ორმაგი ეფექტები.
უზარმაზარი შეტყობინებები (MB ათეული) - GC ფრაგმენტაცია/პაუზა. შეინახეთ payload ობიექტში, გაგზავნეთ ბმულები.
RPC შერევა და ნაკადი კაფკაში - რთული ცხოვრების ციკლი/წესრიგი.
JetStream, როგორც „გრძელვადიანი DWH“, არ არის დანიშნული; დიდხანს შეინახეთ ობიექტის/სვეტების სვეტებში.
არ არსებობს DLQ - „შხამიანი“ შეტყობინებები უსასრულოდ ტრიალებს.
დავიწყებული ჭერი დისკები ივსება, კლასტერის გაჩერება.

18) FAQ

Q: შესაძლებელია თუ არა „exactly-once“ დასრულება?
A: პრაქტიკაში - ეფექტურად დიახ: Kafka (idempotent პროდიუსერი + გარიგება) და idempotent sings (გასაღები, upsert). NATS- ში - პროგრამაში იდემპოტენტურობის/დედობის გზით.

Q: რა უნდა აირჩიოთ მილიონი მცირე RPC/წმ?
A: NATS Core: მიკროსაფინანსო, request-reply, მსუბუქი კონექტორები და queue-groups.

Q: თქვენ გჭირდებათ კომპაქტური და სარტყელი სახელმწიფო?
A: Kafka с `cleanup. პოლიცია = კომპაქტური ', გასაღები = აგრეგატი/რესურსი.

Q: როგორ გავუმკლავდეთ ლაგს?
A: გაზარდეთ წვეულებების/ვორკერების რაოდენობა, შეამციროთ დამუშავების დრო, ბატები და prefetch, ოპტიმიზაცია მოახდინონ დესერალიზაციაზე, ვერტიკალურად გააძლიერონ ბროკერები/დისკები.

Q: მრავალმხრივი და DR?
A: Kafka - MirrorMaker 2/Cluster Linking, აქტივი, რომელსაც აქვს RPO წამი. NATS — supercluster/leafnodes; JetStream მარცვლეული/რეპლიკები ზონების მიხედვით.

19) შედეგები

Kafka და NATS დახურავს სხვადასხვა რეჟიმს: Kafka - ღონისძიების გამძლე ჟურნალები, მაღალი throughput, გარიგება და მიმღები; NATS არის ულტრა მსუბუქი საბურავი დაბალი შეფერხებისთვის, RPC და მარტივი გულშემატკივარი, JetStream- ით პერსონალისთვის. არჩევანი გააკეთეთ მიწოდების სემანტიკისგან, წესრიგისა და რეტინისგან, ლატენტურობისა და ოპერაციული ხარჯებისგან. შეიმუშავეთ გასაღებები/წვეულებები, რეტენინგი, DLQ და დაკვირვება - და თქვენი მოვლენის არქიტექტურა იქნება პროგნოზირებადი, მასშტაბური და საიმედო.