Geliştirme

  • Şunlara uygulanır: ✅ Azure Cache for Redis

Önemli

Redis için Azure Cache, tüm SKU'lar için kullanımdan kaldırma zaman çizelgesini duyurdu. Mevcut Redis için Azure Cache örneklerinizi en kısa sürede Azure Yönetilen Redis'e taşımanızı öneririz.

Geçiş kılavuzu:

Kullanımdan kaldırma hakkında daha fazla bilgi için:

Bağlantı dayanıklılığı 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 tüketebilir.

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 vermiş olsa da 'B' yanıtı, 'A' yanıtının zaman aşımına uğramasını beklemek zorunda kaldı.

|-------- 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. İstemci kodunuzu, büyük istekleri ve yanıtları izlemek için yapılandırabilirsiniz.

Büyük yanıt boyutları için çözümler çeşitlilik gösterir, ancak şunlardır:

  • Uygulamanızı birkaç büyük değer yerine çok sayıda küçük değer için iyileştirin.
  • 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 mevcut 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 döngüsel dağıtım yaklaşımını 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ü:

  • Onlar bir CPU çekirdeğini paylaşırlar.
  • 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 veya özel IP adresini değil ana bilgisayar adını kullanın

Önbelleğinize atanan IP adresi, bir ölçeklendirme işlemi veya arka uç geliştirmesi sonucunda değişebilir. Açık bir genel veya özel IP adresi yerine konak adına güvenmenizi öneririz. Sanal ağdaki bir önbellek için yapılandırılan statik IP adresi sabit bir garanti değildir ve değişiklikler nadir olsa da belirli işlemler sırasında değişebilir. Çeşitli SKU'lar için önerilen formlar şunlardır:

SKUs Şekil
Temel, Standart, Premium <DNS name>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net
Azure Yönetilen Redis <DNS name>.<Azure region>.redis.azure.net

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.

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 sertifikasına zincirlenmeye devam ediyor. Ancak TLS sunucu sertifikaları, 12 Ekim 2020'den itibaren yeni Ara Sertifika Yetkilileri (ICA) tarafından verilecektir.

Not

Bu değişiklik genel Azure bölgelerindeki hizmetlerle sınırlıdır. Egemen (örneğin, Çin) veya devlet bulutlarını dışlar.

Bu değişiklik beni etkiliyor mu?

Redis için Azure Önbellek müşterilerinin çoğu 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 Önbellek, OCSP stapling'i desteklemiyor.

Aşağıdaki tabloda yenilenen 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.

CA Türü Geçerli Post Rolling (12 Ekim 2020) Eylem
Kök Parmak izi: d4de20d05e66fc53fe1a50882c78db2852cae474

Süre sonu: 12 Mayıs 2025 Pazartesi, 16:59:00

Konu Adı:
CN = Baltimore CyberTrust Kök Sertifikası
OU = CyberTrust
O = Baltimore
C = IE		 Değiştirilmiyor Hiçbiri
Ara Ürünler Parmak İzleri:
CN = Microsoft IT TLS CA 1
Parmak İzi: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Parmak izi: 54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft BT TLS CA 4
Parmak izi: 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Parmak İzi: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Süre Sonu: 20 Mayıs 2024 Cuma 05:52:38

Konu Adı:
OU = Microsoft BT
O = Microsoft Corporation
L = Redmond
S = Washington
C = ABD
 Parmak İzleri:
CN = Microsoft RSA TLS CA 01
Parmak izi: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Parmak izi: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Süre sonu: 8 Ekim 2024 Salı 12:00:00;

Konu Adı:
O = Microsoft Corporation
C = ABD
 Zorunlu

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:

Sertifika Parmak İzi
Baltimore Kök CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Kök Sertifika Yetkilisi 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Küresel Kök G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

İpucu

Hem ara hem de yaprak sertifikaların sık sık değişmesi beklenir. Bunlara bağımlılık almamanızı öneririz. Bunun yerine, daha seyrek yenilendiği için uygulamanızı bir kök sertifikaya sabitleyin.

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:

CA'nın ortak adı Parmak İzi
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS Dağıtan CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS Düzenleyen CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS Yayımlayan CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS İmzalayan CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Uygulamanız kodda sertifikayı doğruluyorsa, kodu değiştirerek yeni sabitlenen sertifikaların özelliklerini tanıyacak şekilde güncellemeniz gerekir --- örneğin, Yayıcılar, 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ü rehberlik

Daha fazla bilgi için İstemci kitaplıkları bölümüne bakın.

Sonraki adımlar

  • Last updated on