Geliştirme

Bağlan dayanıklılık ve sunucu yükü

İstemci uygulamaları geliştirirken, bağlantı dayanıklılığı ve sunucu yükünü yönetmek için uygun en iyi yöntemleri göz önünde bulundurmayı unutmayın.

Daha fazla anahtarı ve daha küçük değerleri göz önünde bulundurun

Redis için Azure Cache daha küçük değerlerle en iyi sonucu verir. Verileri birden çok anahtara yaymak için içindeki daha büyük veri öbeklerini daha küçük parçalara bölmeyi göz önünde bulundurun. İdeal değer boyutu hakkında daha fazla bilgi için bu makaleye bakın.

Büyük istek veya yanıt boyutu

Büyük bir istek/yanıt zaman aşımlarına neden olabilir. Örneğin, istemcinizde yapılandırılan zaman aşımı değerinizin 1 saniye olduğunu varsayalım. Uygulamanız aynı anda iki anahtar (örneğin, 'A' ve 'B') ister (aynı fiziksel ağ bağlantısını kullanarak). çoğu istemci, hem 'A' hem de 'B' isteklerinin yanıtlarını beklemeden ardışık olarak gönderildiği istek kanalı oluşturmayı destekler. Sunucu yanıtları aynı sırada geri gönderir. 'A' yanıtı büyükse, sonraki istekler için zaman aşımının çoğunu alabilir.

Aşağıdaki örnekte, 'A' ve 'B' istekleri sunucuya hızlı bir şekilde gönderilir. Sunucu hızlı bir şekilde 'A' ve 'B' yanıtlarını göndermeye başlar. Veri aktarım süreleri nedeniyle, sunucu hızlı yanıt vermesine rağmen 'B' yanıtının 'A' yanıtını beklemesi zaman aşımına uğradı.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

Bu isteği/yanıtı ölçmek zordur. Büyük istekleri ve yanıtları izlemek için istemci kodunuzu izleyebilirsiniz.

Büyük yanıt boyutları için çözünürlükler farklılık gösterse de şunlardır:

• Uygulamanızı birkaç büyük değer yerine çok sayıda küçük değer için iyileştirin.
  • Tercih edilen çözüm, verilerinizi ilgili daha küçük değerlere bölmektir.
  • Gönderiye bakın Redis için ideal değer boyutu aralığı nedir? 100 KB çok mu büyük? daha küçük değerlerin neden önerildiğinden ayrıntılı bilgi için.
• Daha yüksek bant genişliği özellikleri elde etmek için sanal makinenizin (VM) boyutunu artırın
  • İstemci veya sunucu VM'nizde daha fazla bant genişliği, daha büyük yanıtlar için veri aktarım sürelerini azaltabilir.
  • Her iki makinedeki geçerli ağ kullanımınızı geçerli VM boyutunuzun sınırlarıyla karşılaştırın. Yalnızca sunucuda veya yalnızca istemcide daha fazla bant genişliği yeterli olmayabilir.
• Uygulamanızın kullandığı bağlantı nesnelerinin sayısını artırın.
  • Farklı bağlantı nesneleri üzerinden istekte bulunmak için hepsini bir kez deneme yaklaşımı kullanın.

Anahtar dağıtımı

Redis kümelediğini kullanmayı planlıyorsanız, önce Anahtarlarla Redis Kümeleme En İyi Yöntemleri'ni okuyun.

Kanal oluşturma kullanma

Redis kanalı oluşturmayı destekleyen bir Redis istemcisi seçmeyi deneyin. Kanal oluşturma, ağı verimli bir şekilde kullanmanıza ve mümkün olan en iyi aktarım hızını elde etmelerine yardımcı olur.

Pahalı işlemlerden kaçının

KEYS komutu gibi bazı Redis işlemleri pahalıdır ve bundan kaçınılmalıdır. Uzun süre çalışan komutlarla ilgili dikkat edilmesi gereken bazı noktalar için bkz . uzun süre çalışan komutlar.

Uygun bir katman seçin

Üretim sistemleri için Standart, Premium, Kurumsal veya Kurumsal Flash katmanlarını kullanın. Üretimde Temel katmanı kullanmayın. Temel katman, veri çoğaltması olmayan ve SLA içermeyen tek düğümlü bir sistemdir. Ayrıca en az C1 önbelleği kullanın. C0 önbellekleri yalnızca basit geliştirme/test senaryolarına yöneliktir çünkü:

• BIR CPU çekirdeğini paylaşır
• az bellek kullanma
• gürültülü komşu sorunlarına eğilimli

Doğru katmanı seçmek ve bağlantı ayarlarını doğrulamak için performans testi yapmanızı öneririz. Daha fazla bilgi için bkz . Performans testi.

İstemci önbellek ile aynı bölgede

Önbellek örneğinizi ve uygulamanızı aynı bölgede bulun. Farklı bir bölgedeki önbelleğe bağlanmak gecikme süresini önemli ölçüde artırabilir ve güvenilirliği azaltabilir.

Azure dışından bağlanabilirsiniz ancak özellikle Redis'i önbellek olarak kullanırken bu önerilmez. Redis sunucusunu yalnızca bir anahtar/değer deposu olarak kullanıyorsanız, gecikme birincil sorun olmayabilir.

Genel IP adresine değil ana bilgisayar adına güven

Önbelleğinize atanan genel IP adresi, ölçeklendirme işlemi veya arka uç geliştirmesi sonucunda değişebilir. Açık bir genel IP adresi yerine konak adına güvenmenizi öneririz. Çeşitli katmanlar için önerilen formlar şunlardır:

Uygun bir Redis sürümü seçin

Önbellek oluştururken kullanılan varsayılan Redis sürümü zaman içinde değişebilir. Redis için Azure Cache, açık kaynak Redis'in yeni bir sürümü yayınlandığında yeni bir sürümü benimseyebilir. Uygulamanız için belirli bir Redis sürümüne ihtiyacınız varsa, önbelleği oluştururken Redis sürümünü açıkça seçmenizi öneririz.

Kurumsal katmanlar için özel yönergeler

Enterprise ve Enterprise Flash katmanları açık kaynak Redis yerine Redis Enterprise üzerinde oluşturulduğundan geliştirme en iyi uygulamalarında bazı farklılıklar vardır. Daha fazla bilgi için bkz . Kurumsal ve Kurumsal Flash katmanları için en iyi yöntemler.

TLS şifrelemesi kullanma

Redis için Azure Cache varsayılan olarak TLS şifreli iletişimler gerektirir. TLS sürüm 1.0, 1.1 ve 1.2 şu anda desteklenmektedir. Ancak TLS 1.0 ve 1.1, sektör genelinde kullanımdan kaldırma yolunda olduğundan mümkünse TLS 1.2'yi kullanın.

İstemci kitaplığınız veya aracınız TLS'yi desteklemiyorsa, Azure portalı veya yönetim API'leri aracılığıyla şifrelenmemiş bağlantıları etkinleştirmek mümkündür. Şifrelenmiş bağlantıların mümkün olmadığı durumlarda, önbellek ve istemci uygulamanızı bir sanal ağa yerleştirmenizi öneririz. Sanal ağ önbelleği senaryosunda hangi bağlantı noktalarının kullanıldığı hakkında daha fazla bilgi için bu tabloya bakın.

Azure TLS Sertifika Değişikliği

Microsoft, Azure hizmetlerini farklı bir Sertifika Yetkilileri (CA) kümesindeki TLS sunucu sertifikalarını kullanacak şekilde güncelleştiriyor. Bu değişiklik 13 Ağustos 2020 ile 26 Ekim 2020 (tahmini) arasında aşamalı olarak kullanıma sunulur. Geçerli CA sertifikaları CA/Browser Forum Temeli gereksinimlerinden biri olmadığından Azure bu değişikliği yapıyor. Sorun 1 Temmuz 2020'de bildirilmiştir ve dünya çapında birden çok popüler Ortak Anahtar Altyapısı (PKI) sağlayıcısı için geçerlidir. Bugün Azure hizmetleri tarafından kullanılan TLS sertifikalarının çoğu Baltimore CyberTrust Kök PKI'sından gelir. Redis için Azure Cache hizmeti Baltimore CyberTrust Köküne zincirlenmeye devam ediyor. Ancak TLS sunucu sertifikaları, 12 Ekim 2020'den itibaren yeni Ara Sertifika Yetkilileri (ICA) tarafından verilecektir.

Bu değişiklik beni etkiliyor mu?

çoğu Redis için Azure Cache müşteri değişiklikten etkilenmez. Kabul edilebilir sertifikaların listesini (sertifika sabitleme olarak bilinen bir uygulama) açıkça belirtiyorsa uygulamanız etkilenebilir. Baltimore CyberTrust Kökü yerine ara veya yaprak sertifikaya sabitlenmişse sertifika yapılandırmasını değiştirmek için hemen işlem yapmalısınız.

Redis için Azure Cache desteklemiyor OCSP zımbalama.

Aşağıdaki tabloda, alınmakta olan sertifikalar hakkında bilgi sağlanmaktadır. Uygulamanızın hangi sertifikayı kullandığına bağlı olarak, Redis için Azure Cache örneğiniz ile bağlantı kaybını önlemek için sertifikayı güncelleştirmeniz gerekebilir.

Hangi önlemleri almalıyım?

Uygulamanız işletim sistemi sertifika deposunu kullanıyorsa veya Baltimore kökünü diğerlerinin arasında sabitlerse hiçbir işlem yapmanız gerekmez.

Uygulamanız herhangi bir ara veya yaprak TLS sertifikasını sabitliyorsa aşağıdaki kökleri sabitlemenizi öneririz:

Ara sertifikaları sabitlemeye devam etmek için, gelecekteki değişiklikleri en aza indirmek için birkaç tane daha içeren sabitlenmiş ara sertifikalar listesine aşağıdakileri ekleyin:

Uygulamanız sertifikayı kodda doğrularsa, sertifikayı değiştirerek yeni sabitlenen sertifikaların --- özelliklerini tanımanız gerekir; örneğin, Verenler, Parmak İzi ---. Bu ek doğrulama, geleceğe daha dayanıklı olması için tüm sabitlenmiş sertifikaları kapsamalıdır.

İstemci kitaplığına özgü yönergeler

Daha fazla bilgi için bkz . İstemci kitaplıkları.

Sonraki adımlar

• Performansı test etme
• Redis için Azure Cache'de yük devretme ve yama uygulama