AMQP protokolünün "başlık altında" ne yaptığı konusunda iyi bir kavramsal anlayış burada yararlıdır. AMQP 0.9.1'in dağıtmayı seçtiği dokümantasyon ve API'nin bunu özellikle kafa karıştırıcı hale getirdiğini, bu yüzden sorunun kendisinin birçok insanın güreşmesi gereken bir şey olduğunu sunuyorum.
TL; DR
Bir bağlantı AMQP sunucusu ile fiziksel anlaşmalı TCP soket olduğunu. Düzgün uygulanmış istemciler, uygulama başına bunlardan birine sahip olacak, iş parçacığı açısından güvenli, iş parçacıkları arasında paylaşılabilir.
Bir kanal bağlantısı tek bir uygulama oturumu. Bir iş parçacığında bu oturumlardan biri veya daha fazlası bulunur. AMQP mimarisi 0.9.1, bunların iş parçacıkları arasında paylaşılmaması ve onu oluşturan iş parçacığı tamamlandığında kapatılması / imha edilmesi gerektiğidir. Ayrıca, çeşitli protokol ihlalleri meydana geldiğinde sunucu tarafından kapatılır.
Bir tüketici , belirli bir kanal üzerinde bir "posta kutusu" varlığını temsil eden bir sanal ve güvenilir olduğu bulunmuştur. Tüketicinin kullanımı, aracıya mesajları belirli bir kuyruktan o kanalın uç noktasına iletmesini söyler.
Bağlantı Gerçekleri
Diğerleri doğru belirttiğimiz gibi İlk olarak, bir bağlantı sunucusuna gerçek TCP bağlantısı temsil nesnesidir. Bağlantılar, AMQP'de protokol düzeyinde belirtilir ve aracıyla tüm iletişim bir veya daha fazla bağlantı üzerinden gerçekleşir.
- Gerçek bir TCP bağlantısı olduğundan bir IP Adresi ve Port # vardır.
- Protokol parametreleri, bağlantının kurulmasının bir parçası olarak ( el sıkışma olarak bilinen bir işlem) istemci başına görüşülür .
- Uzun ömürlü olacak şekilde tasarlanmıştır ; bağlantı kapanmasının protokol tasarımının bir parçası olduğu birkaç durum vardır.
- OSI açısından, muhtemelen Katman 6'nın etrafında bir yerde bulunur
- TCP, kendi başına hiçbir şey içermediğinden kalp atışları bağlantı durumunu izleyecek şekilde ayarlanabilir.
- Temel TCP soketine okuma ve yazma işlemlerini yönetmek için özel bir iş parçacığına sahip olmak en iyisidir. Hepsi olmasa da çoğu RabbitMQ istemcileri bunu yapar. Bu bağlamda, genel olarak diş açmaya karşı güvenlidirler.
- Göreceli olarak, bağlantılar (tokalaşma nedeniyle) oluşturmak için "pahalı", ancak pratik olarak, bu gerçekten önemli değil. Çoğu işlem gerçekten sadece bir bağlantı nesnesine ihtiyaç duyacaktır. Ancak, tek bir iş parçacığının / soketin sağlayabileceğinden daha fazla iş hacmine ihtiyacınız olduğunu fark ederseniz, bir havuzdaki bağlantıları koruyabilirsiniz (mevcut bilgi işlem teknolojisiyle pek olası değildir).
Kanal Gerçekleri
Bir Kanal RabbitMQ komisyoncu ile iletişim kurmak için uygulamanın her parça için açılır uygulama oturumdur. Tek bir bağlantı üzerinden çalışır ve aracı ile bir oturumu temsil eder .
- Uygulama mantığının mantıksal bir bölümünü temsil ettiğinden, her kanal genellikle kendi iş parçacığında bulunur.
- Genellikle, uygulamanız tarafından açılan tüm kanallar tek bir bağlantıyı paylaşır (bunlar bağlantının üstünde çalışan hafif oturumlardır). Bağlantılar iş parçacığı için güvenlidir, bu yüzden sorun yok.
- Çoğu AMQP işlemi kanallar üzerinden gerçekleşir.
- OSI Katmanı perspektifinden bakıldığında, kanallar muhtemelen Katman 7 civarındadır .
- Kanallar geçici olacak şekilde tasarlanmıştır ; AMQP tasarımının bir kısmı, kanalın bir hataya yanıt olarak tipik olarak kapalı olmasıdır (örneğin, mevcut kuyruğu silmeden önce farklı parametrelerle bir kuyruğun yeniden bildirilmesi).
- Geçici oldukları için kanallar uygulamanız tarafından birleştirilmemelidir.
- Sunucu, bir kanalı tanımlamak için bir tamsayı kullanır. Bağlantıyı yöneten iş parçacığı belirli bir kanal için bir paket aldığında, aracıya paketin hangi kanala / oturuma ait olduğunu söylemek için bu numarayı kullanır.
- Kanallar genellikle evre için güvenli değildir, çünkü evreleri arasında paylaşmanın bir anlamı yoktur. Aracıyı kullanması gereken başka bir iş parçacığınız varsa, yeni bir kanal gereklidir.
Tüketici Gerçekleri
Tüketici, AMQP protokolü tarafından tanımlanan bir nesnedir. Ne bir kanal ne de bir bağlantıdır, bunun yerine özel uygulamanızın mesajları bırakmak için bir tür "posta kutusu" olarak kullandığı bir şeydir.
- "Tüketici oluşturma", aracıya ( bağlantı yoluyla bir kanal kullanarak ) mesajların o kanal üzerinden size iletilmesini istediğinizi bildirir. Yanıt olarak, aracı kanalda bir tüketiciniz olduğunu kaydeder ve size mesaj göndermeye başlar.
- Bağlantı üzerinden itilir Her mesaj bir iki referans olacak kanal numarasını ve bir tüketici sayısı . Bu şekilde, bağlantı yönetme iş parçacığı (bu durumda, Java API'sı içinde) ileti ile ne yapılacağını bilir; kanal işleme iş parçacığı da mesajla ne yapılacağını bilir.
- Tüketici uygulaması tam anlamıyla uygulamaya özgü olduğu için en geniş çeşitliliğe sahiptir. Uygulamamda, tüketiciye her mesaj geldiğinde bir görevi kapatmayı seçtim; böylece, bağlantıyı yöneten bir iş parçacığı, kanalı yöneten bir iş parçacığı (ve ek olarak, tüketici) ve tüketici aracılığıyla teslim edilen her ileti için bir veya daha fazla görev iş parçacıkları vardı.
- Bir bağlantının kapatılması bağlantıdaki tüm kanalları kapatır. Bir kanalın kapatılması kanaldaki tüm tüketicileri kapatır. Bir tüketiciyi iptal etmek de mümkündür (kanalı kapatmadan). Üç şeyden herhangi birini yapmanın mantıklı olduğu çeşitli durumlar vardır.
- Tipik olarak, bir AMQP istemcisinde bir tüketicinin uygulanması, diğer iş parçacıklarının veya kodların (yayınlama dahil) faaliyetleriyle çakışmaları önlemek için tüketiciye özel bir kanal tahsis edecektir.
Tüketici iş parçacığı havuzu ile ne demek istediğim açısından, Java istemcisinin istemcimi yapması için programladığım şeye benzer bir şey yaptığını sanıyorum (benim .Net istemcisini temel alıyordu, ancak büyük ölçüde değiştirildi).
