Zaman uyumsuz mesajlaşma seçenekleri

Bu makalede, farklı ileti türleri ve mesajlaşma altyapısına katılan varlıklar açıklanmaktadır. İleti türü gereksinimlerine bağlı olarak Azure, Azure Service Bus mesajlaşması, Azure Event Grid ve Azure Event Hubs içeren mesajlaşma hizmetleri sağlar. Daha fazla bilgi için bkz. Mesajlaşma hizmetlerini karşılaştırma.

Mimari düzeyde, üretici varlık bilgileri dağıtmak için bir mesaj datagramı oluşturur. Tüketici varlıkları bilgilerin farkında olur ve buna göre hareket eder. Üretici ve tüketiciler doğrudan veya bir aracı ileti aracısı varlığı üzerinden iletişim kurabilir. Bu makale, ileti aracısı kullanan zaman uyumsuz mesajlaşmaya odaklanır.

Diyagramda bir üreticiyle başlayan, ileti aracısına giden ve tüketiciyle biten bir akış gösterilir.

İletilerin iki ana kategorisi vardır:

• Komut, tüketiciden belirli bir eylem isteyen bir iletidir.
• Olay, tüketiciye bir eylemin gerçekleştiğini bildiren bir iletidir.

Commands

Üretici, tüketiciden bir iş işlemi içinde işlem gerçekleştirmesini isteyen bir komut gönderir.

Komut, katı teslim gereksinimleri olan yüksek değerli bir iletidir. Bir komut en az bir kez teslim edilmelidir. Bir komut hedefine ulaşmazsa, iş işleminin tamamı başarısız olabilir. Çoğu durumda tüketicilerin komutu birden fazla kez işlememesi gerekir. Tekrarlı işlem, yinelenen siparişler veya çift faturalama gibi hatalı işlemlere neden olabilir.

Komutlar genellikle çok adımlı bir iş işleminin iş akışını yönetir. üretici, iş mantığına bağlı olarak tüketicinin iletiyi kabul etmesini ve işlemin sonuçlarını raporlamasını bekleyebilir. Bu sonuca bağlı olarak, üretici nasıl ilerleyeceğini seçebilir.

Events

Olay, bir üreticinin bir şeyin olduğunu duyurmak için oluşturduğu bir iletidir. Yapımcının (bu bağlamda yayımcı olarak bilinir) olayın belirli bir eylemle sonuçlanacağından hiçbir beklentisi yoktur.

İlgili tüketiciler abone olabilir, olayları dinleyebilir ve tüketim senaryolarına bağlı olarak eylemler gerçekleştirebilir. Olayların birden çok abonesi olabilir veya hiç abonesi olmayabilir. Farklı aboneler, birbirinden bağımsız olarak farklı eylemlerle aynı olaya tepki verebilir.

Üretici ve tüketici gevşek bir şekilde bağlanmış ve bağımsız olarak yönetilmektedir. Üretici, tüketicinin olayı üreticiye geri kabul etmesini beklemez. Olaylarla artık ilgilenmeyen bir tüketici aboneliği kaldırabilir ve bu da üreticiyi veya sistemin genel işlevselliğini etkilemeden tüketiciyi işlem hattından kaldırır.

Olayların iki kategorisi vardır:

• Ayrık olaylar: Yapımcı, tek tek olguları duyurmak için olayları tetikler. Yaygın kullanım örneği olay bildirimidir. Örneğin, Azure Resource Manager kaynakları oluşturduğunda, değiştirdiğinde veya sildiğinde olayları tetikler. Mantıksal uygulama bu olaylara abone olabilir ve uyarı e-postaları gönderebilir.

• Olay akışları: Yapımcı, zaman içinde ilgili olayların bir dizisini oluşturur. Tüketiciler genellikle zamansal bir pencere içinde veya olaylar geldikçe akışları istatistiksel amaçlarla değerlendirir. Telemetri, sistemin sistem durumunu ve yükünü izleme gibi yaygın bir kullanım örneğidir. Başka bir kullanım örneği nesnelerin İnterneti (IoT) cihazlarından olay akışı içerir.

Publisher-Subscriber desenini kullanarak olay mesajlaşması uygulayabilirsiniz.

Yayımcı, merkezi bir ileti bileşenine iletiler gönderir ve ardından bu iletileri A abonesi ve B abonesi etiketli iki aboneye teslim eder.

İleti aracısı rolü ve avantajları

Ara ileti aracısı, iletileri depolar ve üreticiden tüketiciye taşır. Ayrıca başka avantajlar da sağlayabilir.

Ayrıştırma

İleti aracısı, üreticinin ileti oluşturma mantığını tüketicinin ileti işleme mantığından ayırır. Karmaşık bir iş akışında bu ayrım, iş operasyonlarını ayırmanıza ve iş akışını koordine olmanıza yardımcı olur.

Sıralı olarak ayrı işlemler gerektiren bir iş işlemi düşünün:

1. Üretici, tüketiciye işlem başlatması için sinyal veren bir komut gönderir.

2. Tüketici, üreticinin yanıtlarını sıralamak için ayrılmış ayrı bir yanıt kuyruğunda iletiyi kabul eder.

3. Üretici yanıtı aldıktan sonra, sonraki işlemi başlatmak için yeni bir ileti gönderir.

4. Farklı bir tüketici bu iletiyi işler ve yanıt kuyruğuna bir tamamlama iletisi gönderir.

Hizmetler, mesajlaşmayı kullanarak işlem iş akışını kendi aralarında koordine eder.

Sol tarafta bir üreticiyi gösteren diyagram. Üretici, iki ileti kuyruğuna iki ayrı ileti akışı gönderir. Her kuyruk, A tüketicisi ve B tüketicisi etiketli ilgili bir tüketiciye ileti gönderir. Her iki tüketici de yanıtlarını paylaşılan yanıt kuyruğuna ve ardından üreticiye gönderir.

İleti aracısı zamansal ayrıştırma sağlar. Üretici ve tüketicinin eşzamanlı olarak çalışması gerekmez. Üretici, tüketici kullanılabilirliğine bakılmaksızın ileti aracısına ileti gönderebilir. Üreticinin kullanılabilirliği de tüketiciyi kısıtlamaz.

Örneğin, bir web uygulamasının kullanıcı arabirimi (UI) iletiler oluşturur ve ileti aracısı olarak bir kuyruk kullanır. Tüketici hazır olduğunda, kuyruktan iletileri alabilir ve işi gerçekleştirebilir. Zamansal ayrıştırma, iletiler asenkron biçimde işlenirken kullanıcı arayüzünün yanıt vermeye devam etmesine ve kesintisiz çalışmasına yardımcı olur.

Bazı işlemler uzun sürebilir. Üretici bir komut verdikten sonra, tüketici işlemi tamamlayana kadar beklemesi gerekmez. İleti aracısı iletileri zaman uyumsuz olarak işlemeye yardımcı olur.

Yük dengeleme

Üreticiler birden çok tüketicinin işlemesi için çok sayıda ileti gönderebilir. İşlemeyi sunucular arasında dağıtmak ve aktarım hızını geliştirmek için bir ileti aracısı kullanın. Tüketiciler, iş yükünü yaymak için farklı sunucularda çalışabilir. Sistemi gerektiği gibi ölçeklendirmek için dinamik olarak tüketici ekleyebilir veya kaldırabilirsiniz.

Sol tarafta bir uygulama örneğini gösteren diyagram. İletileri ortadaki tek bir ileti kuyruğuna gönderir. Bu kuyruktan, sağdaki üç ayrı tüketici örneğine işaret eden üç ok, iletileri paralel olarak işleyen tüketici havuzunu temsil eder.

Rakip Tüketiciler düzeni, aktarım hızını iyileştirmek, ölçeklenebilirliği ve kullanılabilirliği geliştirmek ve iş yükünü dengelemek için birden çok iletiyi eşzamanlı olarak işler.

Yük dengeleme

Üreticiler, ani artışlar gösterebilen çeşitli mesaj hacimleri üretir. Ek yükü işlemek için tüketici eklemek yerine mesaj aracısı iletileri arabelleğe alır. Tüketiciler daha sonra sistemi aşırı yüklemeden iletileri yönetilebilir bir hızda işler.

Sol taraftaki üç üretici merkezi bir ileti kuyruğunu işaret ediyor. Tek bir ok kuyruktan sağdaki bir tüketiciye çıkıyor. Diyagramın altında, "değişken hızda alınan istekler" etiketli çubuk grafiğinde eşit olmayan çubuklar bulunur. Daha sabit bir hızda işlenen iletiler etiketi olan başka bir çubuk grafikte daha tekdüzen çubuklar vardır.

Daha fazla bilgi için Kuyruk Tabanlı Yük Dengeleme kalıbı bölümüne bakın.

Güvenilir mesajlaşma

Mesaj aracısı, üretici ile tüketici arasındaki iletişim hataları sırasında bile mesajların kalıcı olmasını sağlar. Üretici aracıya ileti gönderip, iletişim devam ettikten sonra tüketici bunları alır. Mesaj aracısına olan bağlantısını kaybetmediği sürece üretici engellenmez.

Dayanıklı mesajlaşma

İleti aracısı sisteminizdeki tüketicilere dayanıklılık ekler. Bir tüketici bir iletiyi işlerken başarısız olursa, başka bir tüketici örneği bu iletiyi işleyebilir. Komisyoncu, bu yeniden işlemeyi destekleyen iletiyi saklar.

Büyük iletiler

Yükünüz ileti aracısı boyut sınırını aştığında veya tüketicilerin yalnızca ara sıra büyük yüklere erişmesi gerektiğinde Claim-Check desenini kullanın. Büyük yükü Azure Blob Depolama gibi bir dış depoda depolayın. Komisyoncuya saklanan veri yüküne yönelik bir işaretçi içeren bir mesaj gönderin. Tüketici, gerektiğinde yükü almak için işaretçiyi kullanır. Bu yaklaşım, büyük veri birimlerinin aracıyı ve tüketicileri bunaltmasını önler.

İleti aracısı için teknoloji seçenekleri

Azure, her birinin farklı özellikleri olan çeşitli ileti aracısı hizmetleri sağlar. Bir hizmet seçmeden önce iletinin amacını ve gereksinimlerini belirleyin.

Service Bus mesajlaşması

Üreticilerden tüketicilere komut aktarmak için Service Bus mesajlaşma kuyruklarını kullanın.

Çekme modeli

Service Bus kuyruğunun tüketicisi, yeni iletileri denetlemek için Service Bus'ı sürekli tarar. Service Bus için istemci SDK'ları ve Azure işlevleri tetikleyicisi bu yoklamayı otomatik olarak işler. Bir ileti kullanılabilir olduğunda SDK, tüketicinin geri çağırmasını çağırır ve iletiyi tüketiciye teslim eder.

Garantili teslimat

Service Bus bir "peek-lock" mekanizması kullanır. Tüketici bir iletiyi aldığında Service Bus iletiyi geçici olarak kilitler. Bu kilit, diğer tüketicilerin aynı iletiyi işlemesini engeller.

Tüketici, iletinin işleme durumunu raporlamalıdır. Tüketici iletiyi tüketildi olarak işaretlediğinde, Service Bus iletiyi kuyruktan kaldırır. Bir hata, zaman aşımı veya kilitlenme oluşursa, Service Bus iletinin kilidini açar, böylece diğer tüketiciler bu iletiyi alabilir. Bu yaklaşım aktarım sırasında ileti kaybını önler.

Yapımcı aynı iletiyi yanlışlıkla iki kez gönderebilir. Örneğin, bir üretici örneği bir ileti gönderdikten sonra başarısız olur. Başka bir üretici özgün örneğin yerini alır ve iletiyi yeniden gönderir. Service Bus kuyrukları, yinelenen iletileri algılayan ve kaldıran yerleşik bir tekrarlama önleme özelliği sağlar. Service Bus yine de bir iletiyi iki kez teslim edebilir. Örneğin, bir tüketici işleme sırasında başarısız olursa Service Bus iletiyi kuyruğa döndürür ve aynı tüketici veya başka bir tüketici yeniden alır. Tüketicinin mesaj işleme mantığı, yinelenen işlemenin sistem durumunu değiştirmemesi için idempotent olmalıdır.

İleti sıralama

İletilerin gönderildikleri sırayla teslim edilmesini sağlamak için Service Bus kuyrukları, sıralı teslimatı sağlamak amacıyla oturumları kullanır. Oturumda bir veya daha fazla ileti olabilir. Service Bus, özelliğini kullanarak iletileri ilişkilendirer SessionId . Bir oturuma ait iletilerin süresi hiçbir zaman dolmaz. Farklı bir kullanıcının iletileri işlemesini önlemek için bir oturumu bir kullanıcıya kilitleyebilirsiniz.

Daha fazla bilgi için bkz . İleti oturumları.

İleti kalıcılığı

Service Bus kuyrukları dayanıklı zamansal ayırmayı destekler. Bir tüketici kullanılamasa veya iletiyi işleyemese bile mesaj kuyrukta kalır.

Uzun süre çalışan işlemlerin denetim noktası

İşlemler uzun süre sürebilir. İşlemin her adımının birden çok iletisi olabilir. bir işlem başarısız olursa iş akışını koordine etmek ve dayanıklılık sağlamak için denetim noktası oluşturmayı kullanın.

Service Bus kuyrukları , oturum durumu özelliği aracılığıyla denetim noktası oluşturmayı destekler. Tüketiciler, bir oturuma ait iletiler için kuyruktaki durum bilgilerini kademeli olarak kaydetmek için SetSessionStateAsync kullanırlar. Örneğin, bir tüketici durumu denetlemek için düzenli aralıklarla arayarak GetSessionStateAsync ilerleme durumunu izleyebilir. Bir tüketici başarısız olursa, başka bir tüketici bilinen son denetim noktasını belirlemek ve oturumu sürdürmek için durum bilgilerini kullanabilir.

Teslim edilemeyen mesaj kuyruğu

Service Bus kuyruğunun, Service Bus'ın teslim edilemeyen veya tüketicilerin işleyebildiği iletileri tutmak için teslim edilemeyen ileti kuyruğu (DLQ) olarak adlandırılan varsayılan bir alt sırası vardır. Service Bus veya tüketicideki ileti işleme mantığı DLQ'ya ileti ekleyebilir. DLQ, tüketici onları kuyruktan alana kadar iletileri saklar.

Service Bus, aşağıdaki senaryolarda iletileri DLQ'ya taşır:

• Zehirli ileti, tüketicinin hatalı biçimlendirilmiş veya beklenmeyen bilgiler içerdiğinden işleyemediği bir iletidir. Service Bus kuyruklarındaki zehirli iletileri algılamak için kuyruğun MaxDeliveryCount özelliğini ayarlayın. Tüketici bu özellik değerinin izin verdiğinden daha fazla kez aynı iletiyi alırsa, Service Bus iletiyi DLQ'ya taşır.

• Belirli bir süre içinde bir tüketici mesajı işlemezse, mesaj artık geçerli olmayabilir. Service Bus kuyrukları, üreticilerin TTL (time-to-live) özniteliğine sahip mesajlar göndermesine olanak tanır. Tüketici iletiyi almadan önce bu süre dolarsa Service Bus iletiyi DLQ'ya yerleştirir.

Hata nedenini belirlemek için DLQ'daki iletileri denetleyin. Bu iletileri yeniden işleyemeyebilirsiniz ve özel bir telafi eylemi gerekebilir.

Karma çözüm

Service Bus, şirket içi sistemlere ve bulut çözümlerine köprü oluşturur. Güvenlik duvarı kısıtlamaları nedeniyle şirket içi sistemlere ulaşmak genellikle zordur. Şirket içinde veya bulutta hem üretici hem de tüketici, ileti alışverişi için konum olarak bulutta Service Bus kuyruk uç noktasını kullanabilir.

Azure Relay Karma Bağlantıları , ileti tabanlı şirket içi iletişim için anahtar teslimi bir uygulama sağlar. Azure Relay, Service Bus üzerinde oluşturulmuş olup çift yönlü, istek-yanıt desenleri ve veri birimi akışları sağlar.

Bu senaryoları işlemek için Mesajlaşma Köprüsü desenini de kullanabilirsiniz.

Konular ve abonelikler

Service Bus, konular ve abonelikler aracılığıyla Publisher-Subscriber düzenini destekler.

Konular ve abonelikler, üreticinin iletileri birden çok tüketiciye yayınlamasına olanak sağlar. Bir konu bir ileti aldığında, iletiyi abone olan tüm tüketicilere iletir. İsteğe bağlı olarak, tüketicilerin yalnızca bir ileti alt kümesi alması için aboneliğe filtre ölçütleri ekleyebilirsiniz. Her tüketici, bir kuyruğa benzer bir abonelikten mesajlar alır.

Yönlendirme mantığını basit tutun. Abonelik filtrelerinize karmaşık iş kuralları eklemekten kaçının. Akıllı uç noktalar ve aptal kanallar yaklaşımını tercih edin. Güvenilir taşıma ve geniş yönlendirme için aracıyı kullanın, ancak tüketici hizmet içinde karmaşık karar verme mantığını işleyin.

Daha fazla bilgi için bkz. Service Bus konuları.

Service Bus'taki protokoller

Service Bus, endüstri genelinde birlikte çalışabilirlik için Gelişmiş İleti Kuyruğa Alma Protokolü'ne (AMQP) sahiptir. Hizmet, Java İleti Hizmeti (JMS) API standardını da destekler.

İleti biçimi şeması hakkında daha fazla bilgi için bkz. İletiler, yükler ve serileştirme.

Event Grid

Ayrık olaylar için Event Grid kullanın. Event Grid Publisher-Subscriber desenini izler. Olay kaynakları olayları tetiklediğinde, bunları Event Grid konularına yayımlar. Bu olayların tüketicileri, olayları işlemek için olay türlerini ve olay işleyicisini belirterek Event Grid abonelikleri oluşturur. Her etkinliğin birden çok aboneliği olabilir.

Event Grid'de gönderme modeli

Event Grid, iletileri dayanıklı bir gönderim modelinde abonelere yayabilir. Webhook bulunan bir Event Grid aboneliğiniz olduğunu varsayalım. Yeni bir olay geldiğinde Event Grid olayı web kancası uç noktasına postalar. Gönderme modelinde abone yoksa veya aboneler sürekli yanıt veremediğinde Event Grid olayları atar.

Uç nokta web kancası belirtimine uyarsa olayları almak için özel bir uç nokta oluşturabilirsiniz. İsterseniz Azure İşlevleri için Event Grid bağlamaları gibi yerleşik özellikleri de kullanabilirsiniz.

Azure ile tümleştirme

Azure kaynakları hakkında bildirim almak istiyorsanız Event Grid'i seçin. Birçok Azure hizmeti, yerleşik Event Grid konularına sahip olay kaynakları görevi görür. Event Grid, olay işleyicisi olarak ayarlayabileceğiniz çeşitli Azure hizmetlerini de destekler. Olayları istediğiniz olay işleyicilerine yönlendirmek için bu konulara abone olabilirsiniz. Örneğin, bir depolama blobu oluşturduğunuzda veya sildiğinizde Bir Azure işlevini çağırmak için Event Grid'i kullanabilirsiniz.

Özel konular

Uygulamanızdan veya Event Grid'in tümleştirmediği bir Azure hizmetinden olay göndermek istiyorsanız özel Event Grid konuları oluşturun.

Örneğin, bir iş işleminin tamamının ilerleme durumunu izlemek istediğinizi varsayalım. Katılan hizmetler, bireysel iş operasyonlarını işlerken olayları tetikler. Bir web uygulaması bu olayları görüntüler. Bu izlemeyi uygulamak için özel bir konu oluşturun ve web uygulamanızı HTTP web kancası olarak kaydeden bir abonelik ekleyin. İş hizmetleri olayları özel konuya gönderdiğinde, Event Grid olayları web uygulamanıza gönderir.

Filtrelenen olaylar

Event Grid'e olayların yalnızca bir alt kümesini belirli bir olay işleyicisine yönlendirmesini bildirmek için abonelikte filtreler belirtebilirsiniz. Abonelik şemasındaki filtreleri belirtin. Üreticiler konuya olay gönderdiğinde, Event Grid yalnızca filtreyle eşleşen değerlere sahip olayları otomatik olarak bu aboneliğe iletir.

Örneğin, uygulamalar Blob Depolama'ya çeşitli biçimlerde içerik yükler. Blob Depolama, bir dosya her geldiğinde Event Grid'e bir olay oluşturur ve yayımlar. Bir olay işleyicisinin küçük resimler oluşturabilmesi için aboneliğe olayları yalnızca görüntülerle sınırlayan bir filtre ekleyebilirsiniz.

Daha fazla bilgi için bkz. Event Grid için olayları filtreleme.

Yüksek aktarım hızı

Event Grid'in yüksek aktarım hızı ve yüksek hacimli kullanım örneklerini desteklemek için birden çok katmanı vardır. Özellik kullanılabilirliği ve aktarım hızı katmana göre farklılık gösterir.

Dayanıklı teslimat

Olaylar için başarılı teslim, komutlar için olduğundan daha az önemlidir, ancak olay türüne bağlı olarak teslim garantileri isteyebilirsiniz. Event Grid her abonelik için her iletiyi en az bir kez teslim etmeye çalışır. Yeniden deneme ilkeleri, son kullanma süresi ve geçersiz harf oluşturma gibi özellikleri açabilir ve özelleştirebilirsiniz. Daha fazla bilgi için bkz . Event Grid ileti teslimi ve yeniden deneme.

Event Grid yeniden deneme işlemi dayanıklılığı artırır, ancak teslimi garanti etmez. Event Grid iletiyi birden çok kez teslim edebilir, uç nokta uzun bir süre yanıt vermemeye devam ettiğinde bazı yeniden denemeleri atlayabilir veya geciktirebilir. Daha fazla bilgi için bkz. Zamanlamayı yeniden deneme.

Teslim edilemedi mektubunu açtığınızda, Event Grid teslim edilmemiş olayları bir Blob Depolama hesabında kalıcı olarak sürdürebilir. Blob Depolama uç noktası yanıt vermez hale gelirse, Event Grid teslimi geciktirir ve sonunda olayı atar. Daha fazla bilgi için bkz. Ölü harf konumunu ayarlama ve yeniden deneme politikası.

Event Grid, olay teslimi için sipariş garantisi vermez.

Event Grid'de çekme modeli

Event Grid, gönderme modeline ek olarak kuyruk benzeri semantiği kullanan HTTP tabanlı çekme teslimini destekler. Olay tüketicileriniz aşağıdaki özelliklere sahip olduğunda bu modeli kullanın:

• Olayları sürekli olarak değil bir zamanlamaya göre işleme
• Güvenilir gerçek zamanlı anlık iletimi engelleyen kesintili bir kullanılabilirliğe sahip olmak
• Özel bağlantı gerektiren ağ kısıtlamalarına sahip olun
• Anında iletme bildirimi uç noktası sağlanamaz

Event Grid, çekme teslimi ile bile ayrık olayların yüksek aktarım hızı dağıtımı için en iyi duruma getirilmiştir. İş yükünüz kesinlikle sıralı işleme (oturumlar), işlemler veya yinelenen algılama gibi kurumsal mesajlaşma özellikleri gerektiriyorsa bunun yerine Service Bus kullanın.

Event Grid'deki protokoller

Event Grid iki olay şemasını destekler:

• CloudEvents şeması: Olaylar için bu biçim şemasını tercih edin. Olay verilerini açıklamaya yönelik açık bir spesifikasyon temel alır ve satıcı sistemleri arasında iyi bir birlikte çalışabilirlik sağlar.

• Event Grid şeması: Bu özel, genişletilebilir olmayan biçim şemasını yalnızca CloudEvents şemasını kullanamıyorsanız kullanın. Bu şema Event Grid'e özgüdür.

Event Grid, ileti aracısı etkileşimi için iki protokolü destekler:

• Dağıtım için olayları sisteme almak amacıyla bir özel HTTP yayımlama API'si.

• MQTT müşterilerinin iletileri yayımlamasına ve iletilere abone olmasına olanak tanıyan bir Telemetri Aktarımı için Mesaj Kuyruğu (MQTT) arabulucu özelliği. Örneğin, bu özellik IoT senaryoları için çift yönlü iletişim sağlayabilir.

Event Hubs

Olay akışlarıyla çalışırken, ileti aracısı olarak Event Hubs'ı kullanın. Event Hubs, düşük gecikme süresiyle büyük hacimli verileri depolayıp tamponlar. Birden çok tüketici verileri arabellekten eşzamanlı olarak okuyabilir. Alınan verileri herhangi bir gerçek zamanlı analiz sağlayıcısını kullanarak dönüştürebilirsiniz. Event Hubs ayrıca olayları bir depolama hesabında depolar.

Yüksek hacimli alım

Event Hubs saniyede milyonlarca olay alabilir. Event Hubs, akışa olayları ekler ve bunları zamana göre sıralar.

Event Hubs'da çekme modeli

Event Hubs yayımcı-abone özellikleri sağlar. Diğer kuyruklar ile Event Hubs arasındaki önemli bir fark, Event Hubs'ın olay verilerini abonelerin kullanımına nasıl sağladığıdır. Event Hubs, olayları geleneksel kuyruğa yerleştirmek yerine akışa eklediği çekme tabanlı bir model kullanır. Abone imlecini yönetir ve akışta ileri ve geri gidebilir, bir zaman uzaklığı seçebilir ve bir diziyi kendi hızıyla yeniden oynatabilir.

Akış işlemcileri , dönüştürme ve istatistiksel analiz için Event Hubs'dan veri çeken abonelerdir. Zaman içinde toplama veya anomali algılama gibi karmaşık işlemler için Azure Stream Analytics veya Apache Spark kullanın. Event Hubs'ı Microsoft Fabric ile tümleştirmek için olay sunucunuza veri yükleyebilir veya bir olay akışı oluşturabilirsiniz.

Her bölümdeki olayları tek tek işlemek için EventProcessorHost, Azure Logic Apps gibi yerleşik bağlayıcılar veya Azure İşlevleri için Event Hubs tetikleyicisi ve bağlamaları kullanabilirsiniz.

Partitioning

Bölümlendirme, olay akışının bir parçasıdır. Event Hubs, bölüm anahtarı kullanarak olayları böler. Örneğin, birkaç IoT cihazı cihaz verilerini bir olay hub'ına gönderir. Bölüm anahtarı, cihaz tanımlayıcısıdır. Event Hubs olayları alırken bunları ayrı bölümlere taşır. Her bölümde Event Hubs tüm olayları zamana göre sıralar.

Tüketici, olay verilerini işleyen bir kod örneğidir. Event Hubs bölümlenmiş bir tüketici deseni izler. Her tüketici yalnızca belirli bir bölümü okur. Birden çok tüketici akışı eşzamanlı olarak okuyabildiğinden birden çok bölüm daha hızlı işlemeye neden olur.

Aynı tüketicinin örnekleri tek bir tüketici grubunu oluşturur. Birden çok tüketici grubu aynı akışı farklı niyetlerle okuyabilir. Bir olay akışının sıcaklık algılayıcısından veriler olduğunu varsayalım. Bir tüketici grubu, sıcaklık artışı gibi anomalileri algılamak için akışı okuyabilir. Başka bir tüketici, zamansal bir pencerede sıralı ortalama sıcaklığı hesaplamak için aynı akışı okuyabilir.

Event Hubs, her grubun ayrı bir abone olarak görev yaptığı birden çok tüketici grubu aracılığıyla Publisher-Subscriber desenini uygular.

Event Hubs bölümleme hakkında daha fazla bilgi için bkz. Bölümler.

Event Hubs veri yakalama

Olay akışını Blob Depolama veya Azure Data Lake Storage'da depolamak için yakalama özelliğini kullanabilirsiniz. Capture, depolama hesabı kullanılamıyorsa verilerinizi bir süre boyunca tuttuğundan güvenilir bir depolama sağlar ve hesabınız kullanılabilir duruma geldikten sonra verileri depolama alanına yazar.

Depolama hizmetleri ayrıca olayları analiz etmek için ek özellikler sağlar. Örneğin, blob depolama hesabının erişim katmanlarını kullanarak olayları sık erişim gerektiren veriler için sık erişim katmanında depolayın. Bu verileri görselleştirme için kullanabilirsiniz. Alternatif olarak, verileri arşiv katmanında depolayabilir ve denetim amacıyla zaman zaman alabilirsiniz.

Capture, Event Hubs tarafından alınan ve toplu işleme özellikleri sağlayan tüm olayları depolar. MapReduce işlevini kullanarak veriler üzerinde raporlar oluşturabilirsiniz. Yakalanan veriler, gerçeğin kaynağı olarak da görev yapabilir. Toplanan verileriniz belirli ayrıntıları kaçırırsa, bunları yakalanan verilerden alabilirsiniz.

Bu özellik hakkında daha fazla bilgi için bkz. Blob Depolama veya Data Lake Storage'da Event Hubs aracılığıyla olayları yakalama.

Apache Kafka istemcileri için destek

Event Hubs , Apache Kafka istemcileri için bir uç nokta sağlar. Mevcut istemciler, yapılandırmalarını uç noktaya işaret edip Event Hubs'a olay göndermeye başlayacak şekilde güncelleştirebilir. Kod değişikliği yapmanız gerekmez.

Daha fazla bilgi için Apache Kafka için Event Hubs bölümüne bakın.

Çapraz geçiş senaryoları

Avantaj elde etmek için iki mesajlaşma hizmetini birleştirebilirsiniz. Bu yaklaşım mesajlaşma sistemi verimliliğini artırır. Örneğin, iş işleminizdeki iletileri işlemek için Service Bus kuyruklarını kullandığınızı varsayalım. Tüketici yeni iletiler için kuyruğu sürekli yokladığı için zaman zaman ileti alan boş olan kuyruklar verimsizlik yaratır. Event Grid aboneliği ayarlayabilir ve olay işleyicisi olarak bir Azure işlevi kullanabilirsiniz. Kuyruk her ileti aldığında ve tüketici dinlemediğinde, Event Grid kuyruğu boşaltmak için Azure işlevini çağıran bir bildirim gönderir.

Service Bus kuyruğu, sol tarafta iletileri yayımlar. Ortada, Event Grid aboneliği bildirimler gönderir. Event Grid aboneliği, kuyruğu boşaltan bir mantıksal uygulamaya işaret eder.

Daha fazla bilgi için bkz. Service Bus to Event Grid tümleştirmesine genel bakış.

İleti kuyruklarını ve olaylarını kullanan kurumsal tümleştirme mimarisi Service Bus to Event Grid tümleştirmesini içerir.

Başka bir örnek olarak, Event Grid bir dizi olay alır. Bazı olaylar bir iş akışı gerektirir ve diğer olaylar bildirim tetikler. İleti meta verileri olayın türünü gösterir. Meta verileri denetlemek için olay aboneliğindeki filtreleme özelliğini kullanın. Bir olay iş akışı gerektiriyorsa, Event Grid bunu bir Service Bus kuyruğuna gönderir. Bu kuyruğun alıcıları gerekli adımları gerçekleştirebilir. Event Grid uyarı e-postaları göndermek için bildirim olaylarını Logic Apps'e gönderir.

Sol tarafta, kaynak grubu olayları meta verileri temel alarak olayları filtreleyen bir aboneliğe işaret eder. Abonelikten bir ok, komutları depolayan bir Service Bus kuyruğuna işaret eder. Başka bir ok, uyarı e-postaları gönderen bir mantıksal uygulamayı işaret eder.

İlgili desenler

Zaman uyumsuz mesajlaşma uygularken aşağıdaki desenleri göz önünde bulundurun:

• Rakip Tüketiciler düzeni: Bir kuyruktan gelen iletileri okumak için birden çok tüketicinin rekabete sahip olması gerekebilir. Bu düzende aktarım hızını iyileştirmek, ölçeklenebilirliği ve kullanılabilirliği geliştirmek ve iş yükünü dengelemek için birden çok iletinin eşzamanlı olarak nasıl işlendiği açıklanır.

• Öncelik Sırası düzeni: İş mantığı öncelikli ileti işleme gerektirdiğinde, bu düzen tüketicilerin düşük öncelikli iletilerden önce daha yüksek öncelikli iletileri nasıl işlediğini açıklar.

• Queue-Based Yük Dengeleme düzeni: Bu düzen, bir üretici ile bir tüketici arasında arabellek işlevi görmek amacıyla bir mesaj aracısı kullanır. Bu desen, aralıklı ağır yüklerin hem üreticinin hem de tüketicinin kullanılabilirliği ve yanıt hızı üzerindeki etkisini en aza indirmeye yardımcı olur.

• Yeniden deneme düzeni: Üreticiler veya tüketiciler geçici hatalar nedeniyle bir kuyruğa bağlantıyı geçici olarak kaybedebilir. Bu düzende, uygulama dayanıklılığını korumak için geçici hatalar sırasında işlemlerin nasıl yeniden denendiği açıklanır.

• Zamanlayıcı Aracısı Gözetmeni düzeni: İş akışları genellikle dağıtılmış hizmetleri koordine etmek için mesajlaşma gerektirir. Bu düzen, mesajlaşmanın dağıtılmış eylemleri nasıl koordine ettiği ve sistemlerin başarısız işlemleri yeniden deneyerek hatalardan kurtulmalarına nasıl yardımcı olduğunu gösterir.

• Koreografi düzeni: Bu desen, hizmetlerin bir iş işleminin iş akışını denetlemek için mesajlaşmayı nasıl kullanabileceğini gösterir.

• Claim-Check deseni: Bu desen, büyük bir iletinin talep denetimine ve yüke nasıl bölüneceğini gösterir.

Topluluk kaynakları

• Blog gönderisi: Idempotency
• Blog gönderisi: Olay odaklı derken ne demek istiyorsunuz?