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:
| Katman | Şekil |
|---|---|
| Temel, Standart, Premium | <cachename>.redis.cache.windows.net |
| Enterprise, Enterprise Flash | <DNS name>.<Azure region>.redisenterprise.cache.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.
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.
Not
Bu değişiklik genel Azure bölgelerindeki hizmetlerle sınırlıdır. Bağımsız (örneğin, Çin) veya kamu bulutlarını dışlar.
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.
| 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ü OU = CyberTrust O = Baltimore C = IE |
Değiştirilmiyor | Hiçbiri |
| Ara | Parmak İzleri: CN = Microsoft BT TLS CA 1 Parmak İzi: 417e225037fbfaa4f95761d5ae729e1aea7e3a42 CN = Microsoft BT TLS CA 2 Parmak izi: 54d9d20239080c32316ed9ff980a48988f4adf2d CN = Microsoft BT TLS CA 4 Parmak izi: 8a38755d0996823fe8fa3116a277ce446eac4e99 CN = Microsoft BT 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 Genel 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 uygulamanızı daha az sık dağıtan 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 Veren CA 01 | 2f2877c5d778c31e0f29c7e371df5471bd673173 |
| Microsoft Azure TLS Veren CA 02 | e7eea674ca718e3befd90858e09f8372ad0ae2aa |
| Microsoft Azure TLS Veren CA 05 | 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5 |
| Microsoft Azure TLS Veren CA 06 | 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0 |
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ı.