<\/span><\/h2>\n\n\n\nMessage queue, T\u00fcrk\u00e7ede mesaj kuyru\u011fu olarak adland\u0131r\u0131l\u0131r. Bir uygulaman\u0131n ger\u00e7ekle\u015ftirilmesi gereken i\u015fi mesaj bi\u00e7iminde ba\u015fka bir bile\u015fene iletmesini ve bu i\u015fin uygun zamanda i\u015flenmesini sa\u011flayan ileti\u015fim yakla\u015f\u0131m\u0131d\u0131r.<\/p>\n\n\n\n
Bu yap\u0131n\u0131n \u00f6nemini anlamak i\u00e7in iki farkl\u0131 senaryo d\u00fc\u015f\u00fcnelim.<\/p>\n\n\n\n
\u0130lk senaryoda bir kullan\u0131c\u0131 rapor olu\u015fturmak ister. Uygulama raporu haz\u0131rlamak i\u00e7in onlarca veri kayna\u011f\u0131n\u0131 sorgular, sonu\u00e7lar\u0131 birle\u015ftirir ve dosyay\u0131 olu\u015fturur. \u0130\u015flem birka\u00e7 saniye s\u00fcrerse kullan\u0131c\u0131 iste\u011fin tamamlanmas\u0131n\u0131 bekler.<\/p>\n\n\n\n
\u0130kinci senaryoda uygulama rapor haz\u0131rlama talebini RabbitMQ \u00fczerinden bir kuyru\u011fa g\u00f6nderir. \u0130stek kabul edildikten sonra kullan\u0131c\u0131ya i\u015flemin ba\u015flat\u0131ld\u0131\u011f\u0131 bildirilebilir. Arka planda \u00e7al\u0131\u015fan bir i\u015f\u00e7i (worker), kuyruktaki mesaj\u0131 al\u0131r ve raporu olu\u015fturur.<\/p>\n\n\n\n
\u0130kinci yakla\u015f\u0131mda uzun s\u00fcren i\u015flem, kullan\u0131c\u0131 iste\u011finin do\u011frudan par\u00e7as\u0131 olmaktan \u00e7\u0131kar. Uygulama ayr\u0131ca ihtiya\u00e7 duyuldu\u011funda daha fazla worker \u00e7al\u0131\u015ft\u0131rarak i\u015flem kapasitesini art\u0131rabilir.<\/p>\n\n\n\n
RabbitMQ kullanman\u0131n ba\u015fl\u0131ca nedenleri \u015funlard\u0131r:<\/p>\n\n\n\n
Uygulamalar aras\u0131ndaki ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 azaltmak:<\/strong> Mesaj\u0131 g\u00f6nderen servis, i\u015fi ger\u00e7ekle\u015ftiren servisin i\u00e7 i\u015fleyi\u015fini bilmek zorunda de\u011fildir.<\/p>\n\n\n\n\u0130\u015f y\u00fck\u00fcn\u00fc dengelemek:<\/strong> Gelen g\u00f6revler kuyrukta birikebilir ve t\u00fcketiciler bunlar\u0131 i\u015flem kapasitelerine g\u00f6re s\u0131rayla alabilir.<\/p>\n\n\n\nGe\u00e7ici sorunlar\u0131 y\u00f6netmek:<\/strong> Bir t\u00fcketici \u00e7al\u0131\u015fmad\u0131\u011f\u0131nda, uygun kuyruk ve mesaj kal\u0131c\u0131l\u0131\u011f\u0131 ayarlar\u0131yla i\u015fler daha sonra i\u015flenmek \u00fczere bekletilebilir.<\/p>\n\n\n\n\u00d6l\u00e7eklenebilirli\u011fi desteklemek:<\/strong> \u0130\u015f y\u00fck\u00fc artt\u0131\u011f\u0131nda ayn\u0131 kuyru\u011fu t\u00fcketen ek worker \u00f6rnekleri devreye al\u0131nabilir.<\/p>\n\n\n\nBununla birlikte RabbitMQ, bir uygulaman\u0131n b\u00fct\u00fcn performans sorunlar\u0131n\u0131 kendili\u011finden \u00e7\u00f6zmez. Mesajlar\u0131n nas\u0131l tasarland\u0131\u011f\u0131, t\u00fcketicilerin ne kadar h\u0131zl\u0131 \u00e7al\u0131\u015ft\u0131\u011f\u0131 ve kuyruklar\u0131n nas\u0131l yap\u0131land\u0131r\u0131ld\u0131\u011f\u0131 sonu\u00e7 \u00fczerinde belirleyicidir.<\/p>\n\n\n\n
<\/span>RabbitMQ Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/span><\/h2>\n\n\n\nRabbitMQ’nun temel \u00e7al\u0131\u015fma ak\u0131\u015f\u0131 mesaj\u0131n g\u00f6nderilmesi, y\u00f6nlendirilmesi, kuyrukta tutulmas\u0131 ve bir t\u00fcketici taraf\u0131ndan i\u015flenmesi a\u015famalar\u0131ndan olu\u015fur.<\/p>\n\n\n\n
<\/span>1. Producer: Mesaj\u0131 g\u00f6nderen uygulama<\/span><\/h3>\n\n\n\nProducer, mesaj\u0131 RabbitMQ’ya g\u00f6nderen uygulama veya servis anlam\u0131na gelir. Bir web uygulamas\u0131, \u00f6deme sistemi ya da arka plan g\u00f6revi producer olarak \u00e7al\u0131\u015fabilir.<\/p>\n\n\n\n
\u00d6rne\u011fin sipari\u015f olu\u015fturuldu\u011funda uygulama, sipari\u015f numaras\u0131n\u0131 ve ger\u00e7ekle\u015ftirilecek i\u015flemin t\u00fcr\u00fcn\u00fc i\u00e7eren bir mesaj yay\u0131nlayabilir.<\/p>\n\n\n\n
Mesajlar\u0131n gereksiz ki\u015fisel veya hassas bilgiler i\u00e7ermemesi \u00f6nemlidir. \u00c7o\u011fu durumda mesajda gerekli kay\u0131t kimli\u011fini ve i\u015flem t\u00fcr\u00fcn\u00fc bulundurmak, di\u011fer bilgileri ihtiya\u00e7 an\u0131nda g\u00fcvenilir veri kayna\u011f\u0131ndan okumak daha uygun olabilir.<\/p>\n\n\n\n
<\/span>2. Exchange: Mesajlar\u0131n y\u00f6nlendirildi\u011fi nokta<\/span><\/h3>\n\n\n\nRabbitMQ’da AMQP 0-9-1 kullan\u0131ld\u0131\u011f\u0131nda producer mesaj\u0131 do\u011frudan kuyru\u011fa g\u00f6ndermek yerine genellikle bir exchange’e yay\u0131nlar. Exchange, mesaj\u0131n hangi kuyru\u011fa veya kuyruklara y\u00f6nlendirilece\u011fini belirleyen kurallar\u0131 uygular.<\/p>\n\n\n\n
Bu ayr\u0131m, mesaj g\u00f6nderen uygulaman\u0131n belirli bir t\u00fcketici kuyru\u011funa do\u011frudan ba\u011f\u0131ml\u0131 olmas\u0131n\u0131 \u00f6nlemeye yard\u0131mc\u0131 olur.<\/p>\n\n\n\n
RabbitMQ’da yayg\u0131n olarak kullan\u0131lan d\u00f6rt exchange t\u00fcr\u00fc bulunur:<\/p>\n\n\n\n
\nDirect exchange:<\/strong> Mesaj\u0131, routing key de\u011feriyle e\u015fle\u015fen kuyruklara y\u00f6nlendirir.<\/li>\n\n\n\nFanout exchange:<\/strong> Mesaj\u0131 kendisine ba\u011fl\u0131 kuyruklara y\u00f6nlendirir; routing key e\u015fle\u015fmesine dayanmaz.<\/li>\n\n\n\nTopic exchange:<\/strong> Routing key \u00fczerindeki desenlere g\u00f6re mesajlar\u0131 se\u00e7er.<\/li>\n\n\n\nHeaders exchange:<\/strong> Mesaj ba\u015fl\u0131klar\u0131ndaki de\u011ferlere g\u00f6re y\u00f6nlendirme yapabilir.<\/li>\n<\/ul>\n\n\n\n\u00d6rne\u011fin order.created<\/code> anahtar\u0131n\u0131 kullanan bir mesaj, sipari\u015f olaylar\u0131 i\u00e7in tan\u0131mlanm\u0131\u015f uygun kuyruklara y\u00f6nlendirilebilir. B\u00f6ylece farkl\u0131 servisler yaln\u0131zca ilgilendikleri olaylar\u0131 t\u00fcketebilir.<\/p>\n\n\n\n<\/span>3. Queue: Mesajlar\u0131n bekledi\u011fi kuyruk<\/span><\/h3>\n\n\n\nKuyruk, y\u00f6nlendirilen mesajlar\u0131n t\u00fcketiciler taraf\u0131ndan al\u0131nana kadar bekleyebildi\u011fi yap\u0131d\u0131r. T\u00fcketicinin i\u015flem kapasitesi gelen mesaj say\u0131s\u0131ndan d\u00fc\u015f\u00fckse kuyrukta birikme meydana gelebilir.<\/p>\n\n\n\n
Bu birikme her zaman hata anlam\u0131na gelmez. K\u0131sa s\u00fcreli yo\u011funluklarda kuyruk, uygulaman\u0131n gelen i\u015f y\u00fck\u00fcn\u00fc daha sonra i\u015fleyebilmesine yard\u0131mc\u0131 olur. Ancak kuyruk s\u00fcrekli b\u00fcy\u00fcyorsa t\u00fcketici kapasitesi, mesaj \u00fcretim h\u0131z\u0131 veya i\u015fleme s\u00fcresi incelenmelidir.<\/p>\n\n\n\n
Kuyruklar dayan\u0131kl\u0131l\u0131k, mesajlar\u0131n saklanma s\u00fcresi ve kapasite s\u0131n\u0131rlar\u0131 gibi ihtiya\u00e7lara g\u00f6re yap\u0131land\u0131r\u0131labilir.<\/p>\n\n\n\n
<\/span>4. Consumer: Mesaj\u0131 alan ve i\u015fleyen uygulama<\/span><\/h3>\n\n\n\nConsumer, kuyruktan mesaj alan ve mesaj\u0131n temsil etti\u011fi i\u015fi ger\u00e7ekle\u015ftiren bile\u015fendir. Mesaj\u0131 ald\u0131ktan sonra bir veritaban\u0131 kayd\u0131 olu\u015fturabilir, e-posta g\u00f6nderebilir veya ba\u015fka bir servise istek yapabilir.<\/p>\n\n\n\n
\u0130\u015flem ba\u015far\u0131yla tamamland\u0131\u011f\u0131nda t\u00fcketici, uygun onay mekanizmas\u0131yla RabbitMQ’ya mesaj\u0131n i\u015flendi\u011fini bildirebilir. Hata durumunda ise mesaj\u0131n yeniden kuyru\u011fa al\u0131nmas\u0131 veya ba\u015fka bir yere y\u00f6nlendirilmesi tercih edilebilir.<\/p>\n\n\n\n
Bu s\u00fcre\u00e7, mesajlar\u0131n yaln\u0131zca iletilmesini de\u011fil, i\u015flenme durumlar\u0131n\u0131n da kontroll\u00fc bi\u00e7imde y\u00f6netilmesini sa\u011flar.<\/p>\n\n\n\n
<\/span>RabbitMQ Kullan\u0131m Alanlar\u0131 Nelerdir?<\/span><\/h2>\n\n\n\nRabbitMQ, \u00f6zellikle uzun s\u00fcren g\u00f6revlerin kullan\u0131c\u0131 isteklerinden ayr\u0131lmas\u0131 veya birden fazla servisin olaylar \u00fczerinden ileti\u015fim kurmas\u0131 gereken uygulamalarda kullan\u0131\u015fl\u0131d\u0131r.<\/p>\n\n\n\n
<\/span>Arka plan g\u00f6revleri<\/span><\/h3>\n\n\n\nDosya d\u00f6n\u00fc\u015ft\u00fcrme, rapor haz\u0131rlama, g\u00f6rsel i\u015fleme ve toplu veri aktar\u0131m\u0131 gibi i\u015flemler bir mesaj kuyru\u011funa b\u0131rak\u0131labilir.<\/p>\n\n\n\n
\u00d6rne\u011fin kullan\u0131c\u0131 b\u00fcy\u00fck bir rapor talep etti\u011finde uygulama hemen raporun haz\u0131r olmas\u0131n\u0131 beklemek yerine g\u00f6revi kuyru\u011fa ekleyebilir. Worker i\u015flemi tamamlad\u0131\u011f\u0131nda uygulama raporun durumunu g\u00fcncelleyebilir.<\/p>\n\n\n\n
<\/span>E-posta ve bildirim sistemleri<\/span><\/h3>\n\n\n\nToplu bildirim g\u00f6nderen uygulamalarda mesaj kuyru\u011fu, g\u00f6nderim i\u015flerinin kontrol alt\u0131nda tutulmas\u0131na yard\u0131mc\u0131 olur. Bildirim servisinin ge\u00e7ici olarak yava\u015flamas\u0131 durumunda g\u00f6revler uygun yap\u0131land\u0131rmayla kuyrukta bekleyebilir.<\/p>\n\n\n\n
B\u00f6ylece uygulaman\u0131n her istekte harici bir e-posta sistemini beklemesi gerekmez. Bununla birlikte tekrar deneme politikas\u0131 dikkatli tasarlanmal\u0131d\u0131r; aksi h\u00e2lde ayn\u0131 bildirimin birden fazla kez g\u00f6nderilmesi m\u00fcmk\u00fcnd\u00fcr.<\/p>\n\n\n\n
<\/span>Mikroservis mimarileri<\/span><\/h3>\n\n\n\nMikroservislerde farkl\u0131 i\u015flevler ayr\u0131 uygulamalar taraf\u0131ndan y\u00fcr\u00fct\u00fclebilir. Sipari\u015f, stok, bildirim ve raporlama servisleri birbirleriyle mesajlar \u00fczerinden ileti\u015fim kurabilir.<\/p>\n\n\n\n
\u00d6rne\u011fin sipari\u015f olu\u015fturuldu\u011funda bir olay yay\u0131nlanabilir. Stok servisi bu olay\u0131 alarak ilgili \u00fcr\u00fcn\u00fcn stok durumunu g\u00fcncelleyebilir. Bildirim servisi de ayn\u0131 olaydan haberdar olarak kullan\u0131c\u0131ya bilgi verebilir.<\/p>\n\n\n\n
Bu yakla\u015f\u0131m servisler aras\u0131ndaki do\u011frudan ba\u011flant\u0131y\u0131 azalt\u0131r. Ancak olaylar\u0131n s\u0131ras\u0131, tekrar teslimat ve ba\u015far\u0131s\u0131z i\u015flemlerin y\u00f6netimi ayr\u0131ca tasarlanmal\u0131d\u0131r.<\/p>\n\n\n\n
<\/span>Ger\u00e7ek zamanl\u0131 i\u015flem ak\u0131\u015flar\u0131<\/span><\/h3>\n\n\n\nRabbitMQ, uygulamalar aras\u0131nda d\u00fc\u015f\u00fck gecikmeli mesaj iletimi gereken baz\u0131 sistemlerde de kullan\u0131labilir. Sens\u00f6rlerden gelen olaylar, uygulama i\u00e7i bildirimler veya i\u015flem durumlar\u0131 uygun t\u00fcketicilere y\u00f6nlendirilebilir.<\/p>\n\n\n\n
Bununla birlikte \u00e7ok uzun s\u00fcreli olay ge\u00e7mi\u015finin tutulmas\u0131, \u00e7ok b\u00fcy\u00fck hacimli ak\u0131\u015flar\u0131n tekrar tekrar okunmas\u0131 veya olaylar\u0131n farkl\u0131 t\u00fcketiciler taraf\u0131ndan ba\u011f\u0131ms\u0131z bi\u00e7imde ba\u015ftan sona taranmas\u0131 gerekiyorsa RabbitMQ Streams ya da Apache Kafka gibi alternatifler de de\u011ferlendirilmelidir.<\/p>\n\n\n\n
<\/span>RabbitMQ’da Mesaj G\u00fcvenli\u011fi ve Hata Y\u00f6netimi<\/span><\/h2>\n\n\n\nMesajla\u015fma altyap\u0131s\u0131nda \u00f6nemli olan yaln\u0131zca mesaj\u0131 h\u0131zl\u0131 g\u00f6ndermek de\u011fildir. Uygulama veya a\u011f hatas\u0131 meydana geldi\u011finde mesaj\u0131n kaybolup kaybolmayaca\u011f\u0131 ve i\u015flemin tekrar denenip denenmeyece\u011fi de belirlenmelidir.<\/p>\n\n\n\n
<\/span>Acknowledgement nedir?<\/span><\/h3>\n\n\n\nAcknowledgement, t\u00fcketicinin mesaj\u0131n i\u015flendi\u011fini RabbitMQ’ya bildirmesidir. Manuel onay kullan\u0131ld\u0131\u011f\u0131nda mesaj, t\u00fcketici ba\u015far\u0131l\u0131 i\u015flemi tamamlay\u0131p onay verene kadar tamamlanm\u0131\u015f kabul edilmez.<\/p>\n\n\n\n
T\u00fcketici onay vermeden ba\u011flant\u0131s\u0131n\u0131 kaybederse RabbitMQ, ilgili mesaj\u0131 yeniden teslim edebilir. Bu davran\u0131\u015f mesaj\u0131n kaybolma riskini azalt\u0131r ancak ayn\u0131 mesaj\u0131n birden fazla kez i\u015flenmesine neden olabilir.<\/p>\n\n\n\n
Bu nedenle t\u00fcketiciler m\u00fcmk\u00fcn oldu\u011funca idempotent tasarlanmal\u0131d\u0131r. \u0130dempotent i\u015flem, ayn\u0131 mesaj birden fazla kez i\u015flense bile sistemde istenmeyen tekrar sonu\u00e7lar\u0131n\u0131n olu\u015fmas\u0131n\u0131 \u00f6nler. \u00d6rne\u011fin sipari\u015f numaras\u0131n\u0131 kontrol ederek ayn\u0131 sipari\u015f i\u00e7in ikinci kez i\u015flem yap\u0131lmas\u0131n\u0131 engellemek bu yakla\u015f\u0131m\u0131n bir \u00f6rne\u011fidir.<\/p>\n\n\n\n
<\/span>Publisher confirms nedir?<\/span><\/h3>\n\n\n\nMesaj\u0131 g\u00f6nderen uygulama, veriyi a\u011f \u00fczerinden iletmi\u015f olmas\u0131n\u0131 mesaj\u0131n RabbitMQ taraf\u0131ndan g\u00fcvenli bi\u00e7imde kabul edildi\u011finin kan\u0131t\u0131 olarak g\u00f6rmemelidir.<\/p>\n\n\n\n
Publisher confirms, broker’\u0131n mesaj\u0131 kabul etti\u011fini producer’a bildiren mekanizmad\u0131r. \u00d6zellikle \u00f6nemli mesajlar\u0131n kaybolma riskini azaltmak i\u00e7in kal\u0131c\u0131 mesajlar, dayan\u0131kl\u0131 kuyruklar ve publisher confirms birlikte de\u011ferlendirilmelidir.<\/p>\n\n\n\n
Bu mekanizmalar tek ba\u015f\u0131na uygulaman\u0131n b\u00fct\u00fcn i\u015f ak\u0131\u015f\u0131n\u0131 garanti alt\u0131na almaz. Mesaj\u0131n bir veritaban\u0131 i\u015flemiyle birlikte \u00fcretilmesi gerekiyorsa veritaban\u0131 ile mesaj broker’\u0131 aras\u0131ndaki tutarl\u0131l\u0131k da tasarlanmal\u0131d\u0131r. Transactional outbox gibi yakla\u015f\u0131mlar bu sorunun \u00e7\u00f6z\u00fcm\u00fcnde kullan\u0131labilir.<\/p>\n\n\n\n
<\/span>Dead Letter Exchange ve tekrar deneme<\/span><\/h3>\n\n\n\nBir mesaj s\u00fcrekli ba\u015far\u0131s\u0131z oluyorsa onu s\u0131n\u0131rs\u0131z bi\u00e7imde ayn\u0131 kuyru\u011fa geri g\u00f6ndermek sorun yaratabilir. Bu durum t\u00fcketicinin ayn\u0131 mesaj\u0131 tekrar tekrar i\u015flemesine ve kaynaklar\u0131n bo\u015fa harcanmas\u0131na yol a\u00e7abilir.<\/p>\n\n\n\n
Dead Letter Exchange (DLX), belirli ko\u015fullarda i\u015flenemeyen veya reddedilen mesajlar\u0131n ayr\u0131 bir hedefe y\u00f6nlendirilmesini sa\u011flayabilir. B\u00f6ylece ba\u015far\u0131s\u0131z mesajlar daha sonra incelenebilir.<\/p>\n\n\n\n
Tekrar denemeler i\u00e7in gecikme ve deneme say\u0131s\u0131 s\u0131n\u0131rlar\u0131 belirlemek, kal\u0131c\u0131 hatalarla ge\u00e7ici hatalar\u0131 ay\u0131rt etmek \u00f6nemlidir. Hatal\u0131 veri i\u00e7eren bir mesaj\u0131n tekrar tekrar denenmesi \u00e7o\u011funlukla sorunu \u00e7\u00f6zmez.<\/p>\n\n\n\n
<\/span>RabbitMQ \u00d6l\u00e7eklendirme ve Y\u00fcksek Eri\u015filebilirlik<\/span><\/h2>\n\n\n\nRabbitMQ kullanan bir sistemin y\u00fck artt\u0131\u011f\u0131nda nas\u0131l davranaca\u011f\u0131 \u00f6nceden planlanmal\u0131d\u0131r.<\/p>\n\n\n\n
<\/span>Birden fazla worker kullanmak<\/span><\/h3>\n\n\n\nAyn\u0131 kuyru\u011fu birden fazla t\u00fcketici i\u015fleyebilir. B\u00f6ylece g\u00f6revler uygun t\u00fcketicilere da\u011f\u0131t\u0131l\u0131r ve toplam i\u015fleme kapasitesi art\u0131r\u0131labilir.<\/p>\n\n\n\n
Ancak t\u00fcketici say\u0131s\u0131n\u0131 art\u0131rmak her zaman do\u011frusal performans art\u0131\u015f\u0131 sa\u011flamaz. \u0130\u015flemler ayn\u0131 veritaban\u0131na yo\u011fun bi\u00e7imde yaz\u0131yorsa darbo\u011faz mesaj broker’\u0131ndan \u00e7ok veritaban\u0131nda olu\u015fabilir. Worker say\u0131s\u0131, ger\u00e7ek i\u015f y\u00fck\u00fcyle test edilerek belirlenmelidir.<\/p>\n\n\n\n
<\/span>Durable queue ve kal\u0131c\u0131 mesajlar<\/span><\/h3>\n\n\n\nDayan\u0131kl\u0131 kuyruk (durable queue), kuyruk tan\u0131m\u0131n\u0131n broker yeniden ba\u015flat\u0131ld\u0131\u011f\u0131nda korunmas\u0131na yard\u0131mc\u0131 olur. Kal\u0131c\u0131 mesajlar (persistent messages) ise mesaj verisinin yeniden ba\u015flatma sonras\u0131nda korunmas\u0131na y\u00f6nelik davran\u0131\u015f\u0131 destekler.<\/p>\n\n\n\n
Bu iki \u00f6zellik farkl\u0131 \u015feyleri ifade eder. Dayan\u0131kl\u0131 bir kuyru\u011fa ge\u00e7ici mesajlar g\u00f6ndermek, mesajlar\u0131n ayn\u0131 kal\u0131c\u0131l\u0131k beklentisini ta\u015f\u0131d\u0131\u011f\u0131 anlam\u0131na gelmez. \u00d6nemli mesajlarda uygun kuyruk t\u00fcr\u00fc, kal\u0131c\u0131 mesaj ayarlar\u0131 ve publisher confirms birlikte ele al\u0131nmal\u0131d\u0131r.<\/p>\n\n\n\n
<\/span>Quorum queue nedir?<\/span><\/h3>\n\n\n\nQuorum queue, mesaj verisini birden fazla RabbitMQ d\u00fc\u011f\u00fcm\u00fcne \u00e7o\u011faltarak dayan\u0131kl\u0131l\u0131\u011f\u0131 art\u0131rmay\u0131 ama\u00e7layan kuyruk t\u00fcr\u00fcd\u00fcr. Bir d\u00fc\u011f\u00fcm\u00fcn ar\u0131zalanmas\u0131 durumunda uygun \u00e7o\u011funluk ve eri\u015filebilirlik ko\u015fullar\u0131 sa\u011flan\u0131yorsa kuyruk \u00e7al\u0131\u015fmaya devam edebilir.<\/p>\n\n\n\n
Bu yap\u0131 daha y\u00fcksek veri g\u00fcvenli\u011fi sa\u011flayabilir ancak kaynak kullan\u0131m\u0131 ve gecikme a\u00e7\u0131s\u0131ndan maliyeti vard\u0131r. Her ge\u00e7ici kuyruk veya d\u00fc\u015f\u00fck gecikme gerektiren senaryo i\u00e7in en uygun se\u00e7enek olmayabilir.<\/p>\n\n\n\n
Y\u00fcksek eri\u015filebilirlik planlamas\u0131nda yaln\u0131zca kuyruk t\u00fcr\u00fc de\u011fil, d\u00fc\u011f\u00fcmlerin yerle\u015fimi, a\u011f ba\u011flant\u0131lar\u0131, disk kapasitesi, izleme ve kurtarma prosed\u00fcrleri de dikkate al\u0131nmal\u0131d\u0131r.<\/p>\n\n\n\n
<\/span>RabbitMQ ile Kafka Aras\u0131ndaki Fark Nedir?<\/span><\/h2>\n\n\n\nRabbitMQ ve Apache Kafka, mesajla\u015fma ve olay tabanl\u0131 mimarilerde kullan\u0131labilen teknolojilerdir; ancak temel kullan\u0131m modelleri farkl\u0131la\u015f\u0131r.<\/p>\n\n\n\n
RabbitMQ, mesajlar\u0131n kuyruklara y\u00f6nlendirilmesi, g\u00f6revlerin t\u00fcketicilere da\u011f\u0131t\u0131lmas\u0131 ve farkl\u0131 mesajla\u015fma desenlerinin uygulanmas\u0131 konusunda g\u00fc\u00e7l\u00fc se\u00e7enekler sunar. Arka plan g\u00f6revleri, servisler aras\u0131 ileti\u015fim ve y\u00f6nlendirme kurallar\u0131n\u0131n \u00f6nemli oldu\u011fu sistemlerde tercih edilebilir.<\/p>\n\n\n\n
Kafka ise kal\u0131c\u0131 olay ak\u0131\u015flar\u0131, y\u00fcksek hacimli veri ak\u0131\u015f\u0131 ve olaylar\u0131n belirli s\u00fcre boyunca saklanarak t\u00fcketiciler taraf\u0131ndan yeniden okunabilmesi gereken mimarilerde \u00f6ne \u00e7\u0131kar.<\/p>\n\n\n\n
Temel farklar\u0131 \u015f\u00f6yle \u00f6zetleyebiliriz:<\/p>\n\n\n\n
\nRabbitMQ:<\/strong> Mesaj y\u00f6nlendirme, i\u015f kuyruklar\u0131 ve t\u00fcketicilere g\u00f6rev da\u011f\u0131t\u0131m\u0131 i\u00e7in uygundur.<\/li>\n\n\n\nKafka:<\/strong> Kal\u0131c\u0131 olay ak\u0131\u015flar\u0131, y\u00fcksek hacimli veri aktar\u0131m\u0131 ve olaylar\u0131n tekrar okunmas\u0131 gereken senaryolar i\u00e7in g\u00fc\u00e7l\u00fc bir se\u00e7enektir.<\/li>\n\n\n\nRabbitMQ:<\/strong> Mesaj\u0131n i\u015flenme durumuna g\u00f6re onay, yeniden teslim ve y\u00f6nlendirme mekanizmalar\u0131 sunar.<\/li>\n\n\n\nKafka:<\/strong> T\u00fcketicilerin olay ak\u0131\u015f\u0131ndaki konumlar\u0131n\u0131 takip etmesine ve uygun yap\u0131land\u0131rmayla ge\u00e7mi\u015f olaylar\u0131 yeniden okumas\u0131na olanak tan\u0131r.<\/li>\n<\/ul>\n\n\n\nBu kar\u015f\u0131la\u015ft\u0131rma, bir teknolojinin di\u011ferinden her durumda daha iyi oldu\u011fu anlam\u0131na gelmez. Do\u011fru se\u00e7im; mesajlar\u0131n ne kadar s\u00fcre saklanaca\u011f\u0131na, t\u00fcketicilerin mesajlar\u0131 nas\u0131l i\u015fleyece\u011fine, veri hacmine ve sistemin hata tolerans\u0131 gereksinimlerine ba\u011fl\u0131d\u0131r.<\/p>\n\n\n\n
<\/span>RabbitMQ Kullan\u0131rken Yap\u0131lan Yayg\u0131n Hatalar<\/span><\/h2>\n\n\n\nRabbitMQ’nun sa\u011fl\u0131kl\u0131 \u00e7al\u0131\u015fmas\u0131 i\u00e7in baz\u0131 tasar\u0131m hatalar\u0131ndan ka\u00e7\u0131nmak gerekir.<\/p>\n\n\n\n
Mesajlar\u0131 s\u0131n\u0131rs\u0131z bi\u00e7imde kuyrukta biriktirmek:<\/strong> T\u00fcketiciler yava\u015flad\u0131\u011f\u0131nda kuyruk uzunlu\u011fu artabilir. Kuyruk s\u0131n\u0131rlar\u0131, disk kapasitesi ve alarm e\u015fikleri belirlenmelidir.<\/p>\n\n\n\nMesaj\u0131 i\u015flem tamamlanmadan onaylamak:<\/strong> T\u00fcketici mesaj\u0131 ald\u0131ktan hemen sonra onay verir ve i\u015flem tamamlanmadan kapan\u0131rsa i\u015f kaybolabilir. Onay zaman\u0131, uygulaman\u0131n i\u015f mant\u0131\u011f\u0131na uygun se\u00e7ilmelidir.<\/p>\n\n\n\nTekrar teslimat\u0131 hesaba katmamak:<\/strong> Bir mesaj birden fazla kez teslim edilebilir. T\u00fcketici i\u015flemleri tekrar \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda \u00e7ift kay\u0131t veya yinelenen bildirim olu\u015fturmamal\u0131d\u0131r.<\/p>\n\n\n\nHata durumunda s\u00fcrekli yeniden kuyru\u011fa almak:<\/strong> Kal\u0131c\u0131 bir hatay\u0131 tekrar denemek sorunu \u00e7\u00f6zmeyebilir. S\u0131n\u0131rl\u0131 tekrar denemeleri ve DLX gibi mekanizmalar de\u011ferlendirilmelidir.<\/p>\n\n\n\n\u0130zleme yapmamak:<\/strong> Kuyruk uzunlu\u011fu, mesaj i\u015fleme s\u00fcresi, t\u00fcketici say\u0131s\u0131, bellek, disk kullan\u0131m\u0131 ve ba\u011flant\u0131 hatalar\u0131 takip edilmelidir. B\u00f6ylece kapasite sorunlar\u0131 b\u00fcy\u00fcmeden fark edilebilir.<\/p>\n\n\n\n<\/span>Sonu\u00e7: RabbitMQ Ne Zaman Tercih Edilmelidir?<\/span><\/h2>\n\n\n\nRabbitMQ, uygulamalar aras\u0131nda g\u00fcvenilir ve esnek mesajla\u015fma kurmak isteyen geli\u015ftiriciler i\u00e7in \u00f6nemli bir altyap\u0131 bile\u015fenidir. Arka plan g\u00f6revlerini y\u00f6netmek, yo\u011fun i\u015f y\u00fck\u00fcn\u00fc worker’lara da\u011f\u0131tmak, servisler aras\u0131ndaki ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 azaltmak ve ba\u015far\u0131s\u0131z mesajlar\u0131 kontroll\u00fc bi\u00e7imde ele almak i\u00e7in kullan\u0131labilir.<\/p>\n\n\n\n
Bununla birlikte ba\u015far\u0131l\u0131 bir mesajla\u015fma mimarisi yaln\u0131zca RabbitMQ kurmaktan ibaret de\u011fildir. Mesajlar\u0131n kal\u0131c\u0131l\u0131\u011f\u0131, t\u00fcketici onaylar\u0131, tekrar teslimat, idempotent i\u015flem tasar\u0131m\u0131, hata kuyru\u011fu ve kapasite takibi birlikte d\u00fc\u015f\u00fcn\u00fclmelidir.<\/p>\n\n\n\n
Bir projede RabbitMQ kullanmay\u0131 planl\u0131yorsan\u0131z \u00f6ncelikle hangi i\u015flemlerin kullan\u0131c\u0131 iste\u011finden ayr\u0131lmas\u0131 gerekti\u011fini ve hangi servislerin birbirleriyle mesajla\u015faca\u011f\u0131n\u0131 belirleyin. Ard\u0131ndan beklenen mesaj hacmini, hata senaryolar\u0131n\u0131 ve veri kayb\u0131na ili\u015fkin gereksinimleri de\u011ferlendirin. Bu yakla\u015f\u0131m, gereksiz karma\u015f\u0131kl\u0131k olu\u015fturmadan s\u00fcrd\u00fcr\u00fclebilir bir mesajla\u015fma altyap\u0131s\u0131 kurman\u0131za yard\u0131mc\u0131 olur.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Bir web uygulamas\u0131nda kullan\u0131c\u0131 sipari\u015f verdi\u011finde yaln\u0131zca sipari\u015f kayd\u0131n\u0131n olu\u015fturulmas\u0131…<\/a><\/p>\n","protected":false},"author":6,"featured_media":24090,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[],"class_list":["post-24089","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-genel"],"yoast_head":"\n