AMQP

AMQP — ilovalar o‘rtasida ishonchli xabar almashish uchun yaratilgan ochiq xabar protokoli. Uning to‘liq nomi Advanced Message Queuing Protocol hisoblanadi.

AMQP producer va consumerlarni bir-biridan ajratadi. Producer xabarni brokerga yuboradi, broker esa routing qoidalari asosida uni queue yoki boshqa manzilga yetkazadi.

AMQP server ilovalari, microservice, task queue, moliyaviy tizim va integratsiya platformalarida qo‘llanadi.

AMQP versiyalari

AMQP nomi ostida bir-biridan sezilarli farq qiladigan protokol modellari mavjud.

AMQP 0-9-1

RabbitMQ bilan keng tarqalgan model. Unda:

tushunchalari muhim.

AMQP 1.0

Xabarlarni node va linklar orqali uzatadigan standartlashtirilgan model. Azure Service Bus, Apache Qpid va boshqa tizimlarda uchraydi.

AMQP 0-9-1 va AMQP 1.0 to‘liq wire-compatible emas. Client va broker qaysi versiyani qo‘llashi tekshiriladi.

Producer va consumer

Producer

Xabarni brokerga yuboradi.

Xabarda:

body;
routing key;
header;
content type;
message ID;
timestamp;
correlation ID;
expiry;
delivery mode

bo‘lishi mumkin.

Consumer

Queue yoki boshqa node’dan xabar oladi va qayta ishlaydi.

Consumer xabarni muvaffaqiyatli bajargach acknowledgement yuborishi mumkin.

Broker

Broker quyidagi vazifalarni bajaradi:

client ulanishlarini qabul qilish;
autentifikatsiya;
xabar marshrutlash;
queue saqlash;
delivery;
acknowledgement;
retry;
dead-letter;
persistence;
flow control.

Broker xabarni saqlash kafolati konfiguratsiyaga bog‘liq.

Exchange

AMQP 0-9-1 modelida producer odatda xabarni to‘g‘ridan-to‘g‘ri queuega emas, exchangega yuboradi.

Exchange routing key va bindinglar asosida xabarni bir yoki bir nechta queuega joylaydi.

Direct exchange

Routing key binding keyga aniq mos bo‘lsa, xabar queuega yuboriladi.

Misol:

routing key: invoice.created

Topic exchange

Routing key nuqta bilan ajratilgan qismlarga bo‘linadi. Wildcard pattern ishlatiladi.

orders.*.created
orders.#

* bitta qismni, # bir nechta qismni qamrab oladi.

Fanout exchange

Routing keyni hisobga olmasdan barcha ulangan queuelarga nusxa yuboradi.

Broadcastga o‘xshash event tarqatishda ishlatiladi.

Headers exchange

Routing key o‘rniga xabar headerlari bo‘yicha moslashtiradi.

Queue

Queue xabarlarni consumer olguncha saqlaydi.

Queue xususiyatlari:

nomi;
durable;
exclusive;
auto-delete;
argumentlar;
message TTL;
max length;
dead-letter exchange;
priority;
quorum yoki classic turi.

Durable queue

Broker qayta ishga tushganda queue ta’rifi saqlanishi mumkin.

Durable queue ichidagi barcha xabar avtomatik saqlanadi degani emas. Xabar ham persistent delivery mode bilan yuborilishi kerak, broker esa diskka yozish siyosatini bajaradi.

Exclusive queue

Faqat bitta connectionga tegishli bo‘lib, connection yopilganda o‘chishi mumkin.

Auto-delete

Oxirgi consumer chiqib ketganda queue o‘chirilishi mumkin.

Binding

Binding exchange va queue orasidagi routing qoidasini ifodalaydi.

Direct exchange misoli:

exchange: events
queue: billing
binding key: invoice.created

Producer invoice.created routing key bilan xabar yuborsa, billing queuega tushadi.

Bir queue bir nechta exchange yoki bindingga ega bo‘lishi mumkin.

Acknowledgement

Consumer xabarni olgach brokerga natijani bildiradi.

Asosiy holatlar:

ACK — xabar muvaffaqiyatli bajarildi;
NACK — xabar rad etildi;
Reject — bitta xabar rad etildi;
Requeue — xabar queuega qaytariladi.

Auto-ack holatida broker xabarni clientga yuborgan zahoti bajarilgan deb hisoblaydi. Consumer keyin crash qilsa, xabar yo‘qolishi mumkin.

Manual ack ishonchliroq, lekin consumer ackni unutmasligi kerak.

At-least-once yetkazish

Manual ack va qayta yetkazish natijasida bir xabar bir necha marta kelishi mumkin.

Masalan:

consumer xabarni bajaradi;
databasega yozadi;
ACK yuborishdan oldin uziladi;
broker xabarni boshqa consumerga qayta beradi.

Shu sababli consumer idempotent ishlashi kerak.

Message ID yoki biznes kaliti duplicate bajarishni aniqlashga yordam beradi.

Publisher confirm

Producer xabarni socketga yozgani broker uni ishonchli qabul qilganini kafolatlamaydi.

Publisher confirm broker xabarni qabul qilganini producerga tasdiqlaydi.

Confirm:

individual;
batch;
async callback

ko‘rinishida ishlatilishi mumkin.

Transaction ham mavjud bo‘lishi mumkin, lekin confirm odatda samaraliroq.

Persistent xabar

Persistent flag xabarni diskka yozish niyatini bildiradi.

Ishonchli saqlash uchun:

durable queue;
persistent message;
publisher confirm;
to‘g‘ri disk siyosati;
broker cluster;
fsync;
replica

birgalikda ko‘riladi.

Persistent flagning o‘zi elektr uzilishida mutlaq yo‘qolmaslik kafolati emas.

Prefetch

Broker consumerga bir vaqtning o‘zida nechta tasdiqlanmagan xabar berishini prefetch bilan cheklaydi.

Prefetch juda katta bo‘lsa:

bir consumer ko‘p xabarni ushlab qoladi;
yuk notekis taqsimlanadi;
xotira sarfi oshadi;
crashda ko‘p xabar qayta queuega tushadi.

Juda kichik qiymat throughputni kamaytirishi mumkin.

Dead-letter

Xabar quyidagi sabablar bilan dead-letter qilinishi mumkin:

consumer rad etdi;
TTL tugadi;
queue uzunligi limitdan oshdi;
queue siyosati.

Dead-letter exchange xabarni alohida queuega yo‘naltiradi.

Bu queue:

xato tahlili;
manual retry;
audit;
poison message ajratish

uchun ishlatiladi.

Retry

Xabar darhol requeue qilinsa va xato doimiy bo‘lsa, u cheksiz tez aylanib, broker va consumerga yuk beradi.

Retry strategiyasi:

soniya;
daqiqa;
soat

kabi bosqichli delay bilan tashkil qilinadi.

AMQP brokerda delayed exchange, TTL queue yoki scheduler orqali amalga oshirilishi mumkin.

Retry soni headerda saqlanadi. Limitdan keyin dead-letter queuega yuboriladi.

Message ordering

Bitta queue ichida xabarlar odatda tartibda saqlanadi, lekin quyidagi holatlar tartibni o‘zgartirishi mumkin:

bir nechta consumer;
retry;
priority queue;
requeue;
parallel processing;
transaction va network delay.

Qat’iy ordering kerak bo‘lsa, partition key, bitta consumer yoki sequence number ishlatiladi.

Security

AMQP brokerda:

TLS;
username va password;
client sertifikati;
virtual host;
exchange va queue ACL;
connection limit;
frame size;
rate limit;
network policy;
audit log

qo‘llanadi.

Har service faqat kerakli exchange va queuega ruxsat oladi.

AMQP va MQTT

Jihat	AMQP	MQTT
Asosiy muhit	Server integratsiyasi va message queue	IoT va yengil telemetriya
Routing	Murakkab exchange va binding	Topic asosida
Queue nazorati	Keng	Broker implementatsiyasiga bog‘liq
Ack modeli	Batafsil	QoS darajalari
Overhead	Ko‘proq	Kichik
Resurs talabi	Server muhitiga mos	Cheklangan qurilmaga mos

Har ikkisi publish/subscribe modelidan foydalanishi mumkin, lekin protokol va maqsadlari bir xil emas.

Diagnostika

AMQP xabar yetib bormasa:

connection;
virtual host;
exchange mavjudligi;
exchange turi;
routing key;
binding;
queue;
durable va auto-delete;
ACL;
publisher confirm;
consumer ack;
prefetch;
dead-letter;
TTL;
broker loglari;
cluster holati

tekshiriladi.

Xabar brokerga keldi, lekin queuega tushmasa, exchange routing qoidasi tekshiriladi. Queuega tushib, consumer olmasa, consumer subscription va credit/prefetch ko‘riladi.

Bog‘liq tushunchalar

Message broker, Producer, Consumer, Exchange, Queue, Binding, Routing key, Acknowledgement, Publisher confirm, Dead-letter queue, RabbitMQ, MQTT