Azure Yönetilen Redis mimarisi

Azure Yönetilen Redis, Redis'in topluluk sürümüne göre önemli avantajlar sağlayan Redis Enterprise yığını üzerinde çalışır. Aşağıdaki bilgiler, Azure Yönetilen Redis'in mimarisinin nasıl tasarlandığı hakkında daha fazla ayrıntı sağlar ve bu bilgiler ileri düzey kullanıcılar için yararlı olabilir.

Redis için Azure Cache ile karşılaştırma

Redis için Azure Cache'in Temel, Standart ve Premium katmanları Redis'in topluluk sürümünde çalışır. Redis'in bu topluluk sürümünde tek iş parçacıklı olmak da dahil olmak üzere çeşitli önemli sınırlamalar vardır. Bu sınırlama, hizmet daha fazla vCPU'yu tam olarak kullanmadığından performansı önemli ölçüde azaltır ve ölçeklendirmeyi daha az verimli hale getirir. Tipik bir Redis için Azure Cache örneği aşağıdaki gibi bir mimari kullanır:

İki VM'nin kullanıldığına dikkat edin - birincil ve yedek. Bu VM'ler düğüm olarak da adlandırılır. Birincil düğüm ana Redis işlemini tutar ve tüm yazma işlemlerini kabul eder. Çoğaltma, bakım, ölçeklendirme veya beklenmeyen hata sırasında yedek kopya sağlamak için çoğaltma düğümüne zaman uyumsuz olarak yürütülür. Redis topluluğunun tek iş parçacıklı olarak tasarlanmış olması nedeniyle, her düğüm yalnızca tek bir Redis sunucu işlemi çalıştırabilir.

Azure Yönetilen Redis'in mimari geliştirmeleri

Azure Yönetilen Redis aşağıdakine benzer daha gelişmiş bir mimari kullanır:

Çeşitli farklar vardır:

• Her sanal makine (veya düğüm) birden çok Redis sunucu işlemini (parçalar olarak adlandırılır) paralel olarak çalıştırır. Birden çok parça, her sanal makinede vCPU'ların daha verimli bir şekilde kullanılmasına ve daha yüksek performansa olanak sağlar.
• Birincil Redis parçalarının tümü aynı VM/düğümde değildir. Bunun yerine, birincil ve yedek parçalar her iki düğümde de dağıtılır. Birincil parçalar çoğaltma parçalarından daha fazla CPU kaynağı kullandığından, bu yaklaşım daha fazla birincil parçanın paralel çalışmasını sağlar.
• Her düğümde, parçaları yönetmek, bağlantıları yönetmek ve kendi kendini düzeltmeyi tetiklemek için yüksek performanslı bir ara sunucu işlemi vardır.

Bu mimari hem daha yüksek performansa hem de etkin coğrafi çoğaltma gibi gelişmiş özelliklere olanak tanır.

Kümeleme

Her Azure Yönetilen Redis örneği, tüm katmanlarda ve SKU'larda kümeleme kullanacak şekilde dahili olarak yapılandırılır. Azure Yönetilen Redis, düğüm başına birden çok parça kullanabilen Redis Enterprise'ı temel alır. Bu yetenek, yalnızca tek bir şard kullanmak üzere ayarlanmış daha küçük örnekler içerir. Kümeleme, Redis örneğindeki verileri parçalama olarak da adlandırılan birden çok Redis işlemi arasında bölmenin bir yoludur. Azure Yönetilen Redis, önbellek örneğine bağlanmak için Redis istemcilerinin kullanabileceği protokolü belirleyen üç küme ilkesi sunar.

Küme ilkeleri

Azure Yönetilen Redis üç kümeleme ilkesi sunar: OSS, Kurumsal ve Kümelenmemiş. OSS küme ilkesi çoğu uygulama için iyidir çünkü daha yüksek aktarım hızını destekler, ancak her sürümün kendi avantajları ve dezavantajları vardır.

• Temel, Standart veya Premium topolojisinden geçiş yapıyorsanız, performansı artırmak için OSS kümelemeyi kullanmayı göz önünde bulundurun. Kümelenmemiş yapılandırmaları yalnızca uygulamanız OSS veya Kurumsal topolojileri destekleyemiyorsa kullanın. OSS kümeleme ilkesi, Redis açık kaynak yazılımıyla aynı API'yi uygular. Redis Kümesi API'si, Redis istemcisinin her Redis düğümündeki parçalara doğrudan bağlanmasına olanak sağlayarak gecikme süresini en aza indirir ve ağ aktarım hızını en iyi duruma getirir. Parça ve vCPU sayısı arttıkça aktarım hızı neredeyse doğrusal olarak ölçeklendirilir. OSS kümeleme ilkesi genellikle en düşük gecikme süresini ve en iyi aktarım hızı performansını sunar. Ancak OSS küme ilkesi, istemci kitaplığınızın Redis Kümesi API'sini desteklemesini gerektirir. Bugün, neredeyse tüm Redis istemcileri Redis Kümesi API'sini destekler, ancak uyumluluk eski istemci sürümleri veya özel kitaplıklar için bir sorun olabilir.

Yeniden Arama modülüyle OSS kümeleme ilkesini kullanamazsınız.

OSS kümeleme protokolü, istemcinin doğru parça bağlantılarını yapmasını gerektirir. İlk bağlantı 10000 numaralı bağlantı noktası üzerinden yapılır. Tek düğümlere bağlanmak için 85XX aralığındaki bağlantı noktaları kullanılır. 85xx bağlantı noktaları zaman içinde değişebilir ve bunları uygulamanıza sabit kodlamamanız gerekir. Kümelemesi destekleyen Redis istemcileri, birincil ve çoğaltma parçaları için kullanılan tam bağlantı noktalarını belirlemek ve parça bağlantılarını sizin için yapmak için CLUSTER NODE komutunu kullanır.

Kurumsal kümeleme ilkesi, tüm istemci bağlantıları için tek bir uç nokta kullanan daha basit bir yapılandırmadır. Kurumsal kümeleme ilkesini kullandığınızda, tüm istekleri ara sunucu işlevi gören tek bir Redis düğümüne yönlendirir. Bu düğüm, istekleri dahili olarak kümedeki doğru düğüme yönlendirir. Bu yaklaşımın avantajı, kullanıcılara Azure Yönetilen Redis'in kümelenmemiş gibi görünmesidir. Bu, Redis istemci kitaplıklarının Redis Enterprise'ın bazı performans avantajlarından yararlanmak için Redis Kümelemeye destek olması gerek olmadığı anlamına gelir. Tek bir uç nokta kullanmak geriye dönük uyumluluğu artırır ve bağlantıyı kolaylaştırır. Dezavantajı, tek düğüm proxy'sinin hesaplama kullanımında veya ağ aktarım hızında bir darboğaz oluşturabilmesidir.

RediSearch modülüyle kullanabileceğiniz tek ilke Kurumsal kümeleme ilkesidir. Kurumsal küme ilkesi bir Azure Yönetilen Redis örneğinin kullanıcılara kümelenmemiş gibi görünmesini sağlarken, multi-key komutlarıyla ilgili bazı sınırlamaları vardır.

Kümelenmemiş kümeleme ilkesi, verileri parçalama olmadan her düğümde depolar. Yalnızca 25 GB ve daha küçük boyutlu önbellekler için geçerlidir. Kümelenmemiş kümeleme ilkesini kullanma senaryoları şunlardır:

• Parçalı yapıda olmayan bir Redis ortamından geçiş yaparken. Örneğin, Redis için Azure Cache'in Temel, Standart ve Premium SKU'larının parçalanmamış topolojileri.
• Çapraz yuva komutlarını yoğun bir şekilde çalıştırırken ve verileri parçalara bölerken hatalara neden olabilir. Örneğin, MULTI komutları.
• Redis'i ileti aracı olarak kullanırken ve parçalama gerekmiyorsa.

Kümelenmemiş ilkeyi kullanma konusunda dikkat edilmesi gerekenler şunlardır:

• Bu ilke yalnızca 25 GB'tan küçük veya 25 GB'a eşit Azure Yönetilen Redis katmanları için geçerlidir.
• Cpu'lar yalnızca önbellek parçalandığında Redis Enterprise yazılımıyla çoklu iş parçacığı kullanabildiğinden, diğer kümeleme ilkeleri kadar performanslı değildir.
• Azure Yönetilen Redis önbelleğinizin ölçeğini genişletmek istiyorsanız, önce küme ilkesini değiştirmeniz gerekir.
• Temel, Standart veya Premium kümelenmemiş topolojisinden taşınıyorsanız, performansı iyileştirmek için OSS kümelerini kullanmayı göz önünde bulundurun. Kümelenmemiş yapılandırmaları yalnızca uygulamanız OSS veya Kurumsal topolojileri destekleyemiyorsa kullanın.

Ölçeği genişletme veya düğüm ekleme

Çekirdek Redis Enterprise yazılımı, daha büyük sanal makineler kullanarak kapasiteyi artırır veya daha fazla düğüm ya da sanal makine ekleyerek yatay ölçekleme yapar. Her iki ölçeklendirme seçeneği de daha fazla bellek, daha fazla vCPU ve daha fazla parça ekler. Bu yedeklilik nedeniyle Azure Yönetilen Redis, her yapılandırmada kullanılan belirli düğüm sayısını denetleme olanağı sağlamaz. Karışıklığı, karmaşıklığı ve en iyi olmayan yapılandırmaları önlemek için bu uygulama ayrıntıları özetlenmiştir. Bunun yerine her SKU, vCPU'ları ve belleği en üst düzeye çıkaran bir düğüm yapılandırmasıyla tasarlanmıştır. Azure Yönetilen Redis'in bazı SKU'ları iki düğüm, diğerleri ise daha fazlasını kullanır.

Çoklu tuş komutları

Azure Yönetilen Redis örnekleri kümelenmiş yapılandırma kullandığından, birden çok anahtar üzerinde çalışan komutlarda CROSSSLOT özel durumlar görebilirsiniz. Davranış, kullanılan kümeleme ilkesine bağlı olarak değişiklik gösterir. OSS kümeleme ilkesini kullanırsanız, çok anahtarlı komutlardaki tüm anahtarların aynı karma yuvaya eşlenmesi gerekir.

Enterprise kümelenme politikası ile CROSSSLOT hatalarını da görebilirsiniz. Kurumsal kümeleme ile yuvalar arasında yalnızca aşağıdaki çok tuşlu komutlara izin verilir: DEL, MSET, MGET, EXISTS, , UNLINKve TOUCH.

Active-Active veritabanlarında, çok anahtarlı yazma komutları (DEL, MSET, UNLINK) yalnızca aynı yuvadaki anahtarlarda çalıştırılabilir. Ancak, Active-Active veritabanlarındaki yuvalar arasında aşağıdaki çok tuşlu komutlara izin verilir: MGET, EXISTSve TOUCH. Daha fazla bilgi için bkz. Veritabanı kümeleme.

Parçalama yapılandırması

Azure Yönetilen Redis'in her SKU'su, parçalar olarak adlandırılan belirli sayıda Redis sunucu işlemini paralel olarak çalıştırır. Aktarım hızı performansı, parça sayısı ve her örnekte kullanılabilen vCPU sayısı arasındaki ilişki karmaşıktır. Parça sayısını el ile değiştiremezsiniz.

Belirli bir bellek boyutu için Bellek için İyileştirilmiş sürüm en az sayıda vCPU'ya ve parçaya sahipken İşlem için İyileştirilmiş sürüm en yüksek değere sahiptir.

Redis işlemleri paralel olarak çalışaabildiği için parça sayısının artırılması genellikle performansı artırır. Ancak, komutları yürütmek için kullanılabilir vCPU yoksa performans düşebilir.

Parçalar, performansı da etkileyen Redis sunucu işlemi, yönetim aracısı ve işletim sistemi görevleri için vCPU döngüleri rezerve edilirken her vCPU'nun kullanımını iyileştirmek için eşlenir. Oluşturduğunuz istemci uygulamaları, Azure Yönetilen Redis ile tek bir mantıksal veritabanı gibi etkileşim kurar. Hizmet, vCPU'lar ve parçalar arasında yönlendirmeyi işler.

SKU'daki parça sayısını artırmak için bu SKU'da daha büyük bir katman kullanın. SKU'ları performans gereksinimlerinize uyacak şekilde de değiştirebilirsiniz.

Aşağıdaki tabloda vCPU'ların belirli bir katman boyutunda birincil parçalara oranı gösterilmektedir. Sütunlardaki veriler, bunun vCPU veya parça sayısı olduğunu garanti etmez. Tablolar yalnızca çizim içindir.

Uyarı

Azure Yönetilen Redis, her SKU'da kullanılan parça ve vCPU sayısını değiştirerek zaman içinde performansı iyileştirir.

Bellek optimize edilmiş, Dengeli ve Hesaplama optimize edilmiş sürümler

Bu tabloda Boyut ile vCPU/birincil parça ilişkisinin genel bir örneği gösterilmektedir.

Seviyeler	Bellek Optimizasyonu Yapılmış	Dengeli	Hesaplama için İyileştirilmiş
Boyut (GB)	vCPU'lar/birincil parçalar	vCPU'lar/birincil parçalar	vCPU'lar/birincil parçalar
24 ¹	4/2	8/6	16 Aralık
60 ¹	8/6	16 Aralık	32/24

¹ Belirli bir katman boyutunda vCPU'ların birincil parçalara oranı, SKU veya katman için bir garantiyi temsil etmez.

Flash için iyileştirilmiş sürüm

Bu tabloda Boyut ile vCPU/birincil parça ilişkisinin genel bir örneği gösterilmektedir.

Seviyeler	Flash Optimizasyonlu (önizleme)
Boyut (GB)	vCPU'lar/birincil parçalar
480 ¹ ²	16 Aralık
720 ¹ ²	Tam zamanlı 24 saat hizmet

¹ Bu katmanlar genel önizleme aşamasındadır.

² vCPU'ların belirli bir katman boyutundaki birincil parçalara oranı, SKU veya katman için bir garanti temsil etmez.

Önemli

Bellek için İyileştirilmiş M350 ve üzeri dahil olmak üzere 235 GB'ın üzerinde depolama alanı kullanan tüm bellek içi katmanlar Genel Önizleme aşamasındadır; Dengeli B350 ve üzeri; ve İşlem için İyileştirilmiş X350 ve üzeri. Tüm bu katmanlar ve üzeri Genel Önizleme aşamasındadır.

Flash için İyileştirilmiş tüm katmanlar herkese açık önizleme aşamasındadır.

Yüksek kullanılabilirlik modu etkin olmadan çalıştırma

Yüksek kullanılabilirlik (HA) modu etkinleştirilmeden çalıştırabilirsiniz. Bu yapılandırma, Redis örneğinizde çoğaltmanın etkinleştirilmediği ve kullanılabilirlik SLA'sına erişimi olmadığı anlamına gelir. Geliştirme ve test senaryoları dışında HA olmayan modda çalıştırmayın. Önceden oluşturduğunuz bir örnekte yüksek kullanılabilirliği devre dışı bırakamazsınız. Yüksek kullanılabilirliğe sahip olmayan bir örnekte yüksek kullanılabilirliği etkinleştirebilirsiniz. Yüksek kullanılabilirlik olmadan çalışan bir örnek daha az VM ve düğüm kullandığından vCPU'lar verimli bir şekilde kullanılmaz, bu nedenle performans düşük olabilir.

Ayrılmış bellek

Her Azure Yönetilen Redis Örneğinde, yük devretme sırasında çoğaltma ve etkin coğrafi çoğaltma arabelleği gibi önbellek dışı işlemler için kullanılabilir belleğin yaklaşık %20'si arabellek olarak ayrılır. Bu arabellek, önbellek performansını iyileştirmeye ve bellek yetersizliğini önlemeye yardımcı olur.

Ölçek küçültme

Ölçek küçültme şu anda Azure Yönetilen Redis'te desteklenmiyor. Daha fazla bilgi için bkz. Azure Yönetilen Redis'i ölçeklendirme sınırlamaları.

Flash için İyileştirilmiş katman

Flash için İyileştirilmiş katman hem NVMe Flash depolamayı hem de RAM'i kullanır. Flash depolama daha düşük maliyetli olduğundan, Flash İyileştirilmiş katmanını kullanmak, fiyat verimliliği için bazı performanstan ödün vermenizi sağlar.

Flash için İyileştirilmiş örneklerde önbellek alanının %20'sini RAM kullanırken, diğer %80'i Flash depolamayı kullanır. Tüm anahtarlar RAM'de depolanırken, değerler Flash depolama alanında veya RAM'de depolanabilir. Redis yazılımı, değerlerin konumunu akıllı bir şekilde belirler. Sık erişilen değerler RAM'de depolanırken daha az kullanılan Soğuk değerler Flash'ta tutulur. Veriler okunmadan veya yazılmadan önce RAM'e taşınarak Sık Erişimli veri haline gelmesi gerekir.

Redis en iyi performans için iyileştirdiğinden, örnek Flash depolamaya öğe eklemeden önce kullanılabilir RAM'i doldurur. ÖNCE RAM'i doldurmanın performans açısından birkaç etkisi vardır:

• Düşük bellek kullanımıyla test yaparken daha iyi performans ve daha düşük gecikme süresi oluşabilir. Tam önbellek örneğiyle test etme, düşük bellek kullanımı test aşamasında yalnızca RAM kullanıldığından daha düşük performans sağlayabilir.
• Önbelleğe daha fazla veri yazarken, RAM'deki verilerin Flash depolamaya kıyasla oranı azalır ve genellikle gecikme süresi ve aktarım hızı performansının da düşmesine neden olur.

Flash'a Optimize Edilmiş Katman İçin Uygun İş Yükleri

Flash İyileştirilmiş katmanında iyi çalışan iş yükleri genellikle aşağıdaki özelliklere sahiptir:

• Okuma komutlarının yazma komutlarına oranı yüksek olan yoğun okuma.
• Access, veri kümesinin geri kalanından çok daha sık kullandığınız bir anahtar alt kümesine odaklanmıştır.
• Anahtar adlarıyla karşılaştırıldığında görece büyük değerler. (Anahtar adları her zaman RAM'de depolandığından, büyük değerler bellek büyümesi için bir tıkanıklığa neden olabilir.)

Flash İyileştirilmiş katmanı için uygun olmayan iş yükleri

Bazı iş yükleri, Flash için İyileştirilmiş katmanın tasarımı için daha az iyileştirilmiş erişim özelliklerine sahiptir:

• Yoğun iş yükleri oluşturma.
• Veri kümesinin çoğunda rastgele veya tekdüzen veri erişim desenleri.
• Nispeten küçük değer boyutlarına sahip uzun anahtar adları.

İlgili içerik

• Azure Yönetilen Redis örneğini ölçeklendirme