Uygulamaları Service Bus kesintilerine ve olağanüstü durumlarına karşı yalıtmak için birden çok ad alanı kullanın

Görev açısından kritik uygulamalar, planlanmamış kesintiler veya olağanüstü durumların varlığında bile sürekli çalışmalıdır. Veri işleme kaynaklarının felaketlere karşı dayanıklılık, birçok kuruluş için ve hatta bazı durumlarda sektör düzenlemeleri için gerekli olan bir gereksinimdir.

Not

Service Bus Coğrafi Olağanüstü Durum Kurtarma ve Coğrafi Çoğaltma, büyük ölçekli olağanüstü durumlardan kurtarmanıza veya uygulama yapılandırmanızda değişiklik yapmaya gerek kalmadan başarısız bir Azure bölgesini kalıcı olarak bırakmanıza yardımcı olur. Bu özellikler ve Azure Service Bus'ta güvenilirlik ve dayanıklılığı etkinleştirme hakkında daha fazla bilgi için bkz. Azure Service Bus'ta güvenilirlik.

gereksinimlerinizi karşılamak için Geo-Disaster Recovery veya Geo-Replication kullanamıyorsanız, birden çok Service Bus ad alanı dağıtabilirsiniz. Bu makalede, birden çok ad alanı kullanarak uygulamaları olası bir hizmet kesintisine veya olağanüstü durumlara karşı korumak için kullanabileceğiniz teknikler açıklanmaktadır.

Çoğaltma türleri

Service Bus Standart katmanıyla olağanüstü durumlara karşı dayanıklılık elde etmek için etkin veya pasif çoğaltma kullanabilirsiniz. Veri merkezi kesintisi sırasında bir kuyruğun veya konunun kullanılabilir durumda kalması gerekiyorsa, her iki ad alanında da aynı varlığı oluşturun. Varlıklar ayrı ad alanları içinde bulunduğundan aynı adı paylaşabilir. Örneğin, contosoPrimary.servicebus.windows.net/myQueue altında birincil kuyruğa ulaşırken, contosoSecondary.servicebus.windows.net/myQueue altında ikincil kuyruğuna ulaşabilirsiniz.

Not

Etkin çoğaltma ve pasif çoğaltma kurulumu, Service Bus'ın belirli özellikleri değil genel amaçlı kavramlardır. Çoğaltma mantığı (2 farklı ad alanına gönderiliyor) gönderen uygulamalardadır ve alıcının yinelenen algılama için özel mantığı olması gerekir.

Uygulama kalıcı gönderenden alıcıya iletişim gerektirmiyorsa, ileti kaybını önlemek ve göndereni geçici Service Bus hatalarından korumak için dayanıklı bir istemci tarafı kuyruğu uygulayabilir.

Etkin çoğaltma

Etkin çoğaltma, her işlem için her iki ad alanında da varlıklar kullanır. İleti gönderen tüm istemciler aynı iletinin iki kopyasını gönderir. İlk kopya birincil varlığa (örneğin, contosoPrimary.servicebus.windows.net/sales) gönderilir ve iletinin ikinci kopyası ikincil varlığa gönderilir (örneğin, contosoSecondary.servicebus.windows.net/sales).

İstemci her iki kuyruktan da ileti alır. Alıcı iletinin ilk kopyasını işler ve ikinci kopya gizlenir. Yinelenen iletileri engellemek için, gönderenin her iletiyi benzersiz bir tanımlayıcıyla etiketlemesi gerekir. İletinin her iki kopyası da aynı tanımlayıcıyla etiketlenmelidir. İletiyi etiketlemek için ServiceBusMessage.MessageId veya ServiceBusMessage.Subject özelliklerini ya da özel bir özelliği kullanabilirsiniz. Alıcı, zaten aldığı iletilerin listesini tutmalıdır.

Not

Etkin çoğaltma yaklaşımı işlem sayısını ikiye katlar, bu nedenle bu yaklaşım daha yüksek maliyete yol açabilir.

Pasif çoğaltma

Hatasız durumda pasif çoğaltma, iki mesajlaşma varlığından yalnızca birini kullanır. İstemci, iletiyi etkin varlığa gönderir. Etkin varlık üzerindeki işlem, etkin varlığı barındıran veri merkezinin kullanılamayabileceğini belirten bir hata koduyla başarısız olursa, istemci yedekleme varlığına iletinin bir kopyasını gönderir. Bu noktada etkin ve yedekleme varlıkları rolleri değiştirir. Gönderen istemci, eski etkin varlığı yeni yedekleme varlığı olarak kabul eder ve eski yedekleme varlığı yeni etkin varlıktır. Her iki gönderme işlemi de başarısız olursa, iki varlığın rolleri değişmeden kalır ve bir hata döndürülür.

İstemci her iki kuyruktan da ileti alır. Alıcının aynı iletinin iki kopyasını alma olasılığı olduğundan, alıcının yinelenen iletileri gizlemesi gerekir. Yinelenenleri etkin çoğaltma için açıklandığı şekilde gizleyebilirsiniz.

Genel olarak pasif çoğaltma, etkin çoğaltmadan daha ekonomiktir çünkü çoğu durumda yalnızca bir işlem gerçekleştirilir. Gecikme süresi, aktarım hızı ve parasal maliyet, çoğaltılmayan senaryoyla aynıdır.

Pasif çoğaltma kullandığınızda, aşağıdaki senaryolarda iletiler iki kez kaybolabilir veya alınabilir:

  • İleti gecikmesi veya kaybı: Gönderenin birincil kuyruğa başarıyla m1 iletisi gönderdiğini ve alıcı m1 almadan önce kuyruğun kullanılamaz duruma geldiğini varsayalım. Gönderen, ikincil kuyruğa sonraki bir m2 iletisi gönderir. Birincil kuyruk geçici olarak kullanılamıyorsa, kuyruk yeniden kullanılabilir duruma geldikten sonra alıcı m1 alır. Bir olağanüstü durum oluştuğunda alıcı hiçbir zaman m1 almayabilir.
  • Yinelenen alma: Gönderenin birincil kuyruğa m iletisi gönderdiğini varsayalım. Service Bus, m'yi başarıyla işler ancak yanıt gönderemiyor. Gönderme işlemi zaman aşımına uğradıktan sonra, gönderen ikincil kuyruğa aynı m kopyasını gönderir. Alıcı birincil kuyruk kullanılamaz duruma gelmeden önce m'nin ilk kopyasını alabilirse, alıcı m'nin her iki kopyasını da yaklaşık olarak aynı anda alır. Alıcı, birincil kuyruk kullanılamaz duruma gelmeden önce m'nin ilk kopyasını alamıyorsa, alıcı başlangıçta yalnızca ikinci m kopyasını alır, ancak birincil kuyruk kullanılabilir duruma geldiğinde ikinci bir m kopyasını alır.

.NET Core ile Azure Mesajlaşma Çoğaltma Görevleri örneği, iletilerin ad alanları arasında çoğaltmasını gösterir.

Sonraki adımlar

Olağanüstü durum kurtarma hakkında daha fazla bilgi edinmek için şu makalelere bakın:

  • Last updated on