Routing key — producer message brokerga xabar publish qilganda uning yo‘naltirilishiga yordam beruvchi satrdir. RabbitMQning AMQP 0-9-1 modelida exchange turi routing keyni bindinglar bilan solishtiradi. U queue nomi bo‘lishi shart emas va xabar payloadidan alohida metadata hisoblanadi.
Exchange turiga bog‘liqlik
Direct exchange routing keyni binding key bilan aynan tenglik bo‘yicha tekshiradi. Topic exchange nuqta bilan ajratilgan so‘zlardan iborat keyni wildcard patternlarga moslaydi. Fanout exchange keyni e’tiborsiz qoldiradi. Headers exchange asosan message headerlarini ishlatadi, routing key unda hal qiluvchi emas.
Default exchangega publish qilinganda routing key queue nomiga teng bo‘lsa xabar o‘sha queuega boradi. Bu maxsus holat routing key har doim queue nomi degan noto‘g‘ri tasavvur yaratishi mumkin.
Nomlash modeli
Routing key odatda entity.action yoki domain.entity.event kabi barqaror conventionga ega bo‘ladi: orders.payment.failed. Segmentlar yuqoridan pastga bir xil semantik tartibda yozilsa topic binding tushunarli bo‘ladi. Bir producer region.service.action, boshqasi action.service.region ishlatsa wildcardlar murakkablashadi.
Keyga user ID, request ID yoki timestamp qo‘shish juda ko‘p routing variant yaratadi. Broker match qilishga qodir bo‘lsa ham topology va authorizationni boshqarish qiyinlashadi. High-cardinality identifikator payload yoki headerda saqlanishi mumkin.
Topic patternlari
Topic exchangeda * aynan bitta segmentga, # nol yoki undan ko‘p segmentga mos keladi. orders.*.created uch segmentli keylarni, orders.# esa orders ostidagi barcha chuqurlikni qamraydi. Bo‘sh segment, ketma-ket nuqta va casing conventionda taqiqlanishi mumkin.
Wildcard binding consumerga event oilasini olish imkonini beradi. Lekin schema bir pattern ichida turlicha bo‘lsa consumer payload turini aniqlashda qiynaladi. Event type va schema version aniq kontrakt bilan birga yuradi.
Yetkazish va xatolar
Exchange hech bir bindingga mos kelmasa xabar unroutable bo‘ladi. Mandatory flag producerga return yuborishi, alternate exchange esa xabarni monitoring yoki fallback routega olib borishi mumkin. Publisher confirm broker publishni qabul qilganini ko‘rsatadi, lekin routing semantik xatosini faqat confirmning o‘zi har doim bildirmaydi.
Routing keyni o‘zgartirish producer va binding konfiguratsiyasining muvofiqlashtirilgan migratsiyasidir. Avval yangi binding qo‘shilib, producer yangi keyga o‘tadi, keyin eski binding trafik tugagach olinadi. Aks holda deploy oralig‘ida xabar yo‘qolishi mumkin.
Xavfsizlik va kuzatuv
Broker authorization exchangega write va queuega readni boshqaradi. Ayrim tizimlarda topic pattern bo‘yicha permission ham beriladi. Foydalanuvchidan olingan satrni nazoratsiz routing key qilish boshqa tenant topiciga publish qilish xavfini tug‘diradi.
Routing key log va tracega yozilishi diagnostikani yengillashtiradi, lekin unda shaxsiy ma’lumot bo‘lmasligi kerak. Unroutable rate, keylar taqsimoti va noma’lum prefixlar naming kontrakti buzilishini ko‘rsatadi.
Versionlash
Schema versionni routing keyga qo‘shish orders.v2.created kabi alohida binding yaratadi. Bu consumer migratsiyasini osonlashtirishi mumkin, lekin har schema o‘zgarishida topology ko‘payadi. Version payload metadata yoki content type orqali ham berilishi mumkin. Tanlov consumer bir vaqtda nechta versionni o‘qishi va event oilasini qanday ajratishiga bog‘liq.
Routing key immutable eventning mazmunini bildiradi; processing natijasiga qarab keyni qayta yozish yangi publish hisoblanadi. Retry va dead-letter oqimida original key metadata sifatida saqlanmasa xabar qayerdan kelgani yo‘qoladi.
Bog‘liq tushunchalar
Exchange, Binding, Binding key, Topic exchange, Direct exchange, Unroutable message, AMQP