Tarihteki en eksiksiz Redis yüksek kullanılabilirlik teknolojisi çözümü
Redis'i kullanmanın birkaç ana yolu:
-
Redis tek kopya
-
Birden çok kopyayı yeniden oluştur
-
Redis Sentinel (Sentinel)
-
Redis Kümesi
-
Redis kendi geliştirdi
Redis'i kullanmanın çeşitli yollarının avantajları ve dezavantajları:
1 Redis tek kopya
Redis tek kopyası, tek bir Redis düğümü dağıtım mimarisi kullanır.Verileri gerçek zamanlı olarak senkronize etmek için bekleme düğümü yoktur ve veri kalıcılığı ve yedekleme stratejileri sağlamaz. Düşük veri güvenilirliği gereksinimleri olan saf önbellek iş senaryoları için uygundur.
avantaj:
1. Basit yapı ve kolay dağıtım
2. Yüksek maliyet performansı Önbellek kullanıldığında, bir yedekleme düğümüne gerek yoktur (tek örnek kullanılabilirliği gözetmen veya crontab tarafından garanti edilebilir) Tabii ki, işletmenin yüksek kullanılabilirliğini karşılamak için bir yedek düğüm de feda edilebilir, ancak aynı zamanda yalnızca bir örnek harici hizmetler sağlar.
3. Yüksek performans
Dezavantajları:
1. Verilerin güvenilirliği garanti edilmez
2. Önbellek kullanıldığında, işlem yeniden başlatıldıktan sonra veriler kaybolur.Yüksek kullanılabilirliği çözmek için yedek bir düğüm olsa bile, önbellek ön ısıtma sorununu yine de çözemez, bu nedenle yüksek veri güvenilirliği gereksinimleri olan hizmetler için uygun değildir.
3. Yüksek performans, tek çekirdekli bir CPU'nun işlem gücüyle sınırlıdır (Redis, tek iş parçacıklı bir mekanizmadır) ve CPU ana darboğazdır, bu nedenle basit işlem komutları, daha az sıralama ve daha az hesaplama içeren senaryolar için uygundur. Bunun yerine memcached kullanmayı da düşünebilirsiniz.
2 Redis çoklu kopyalar (master-slave)
avantaj:
1. Yüksek güvenilirlik Bir yandan, ana kitaplık arızalandığında ana ve bağımlı arasında otomatik olarak geçiş yapabilen ve sorunsuz hizmet çalışmasını sağlamak için ana kitaplığa hizmet sağlamak için yardımcı kitaplığı yükseltebilen çift makineli ana-bağımlı mimarisi benimsenmiştir. Öte yandan, veri kalıcılığı işlevini etkinleştirmek ve makul bir yedekleme stratejisini yapılandırmak, veri yanlış çalışması ve anormal veri kaybı sorunlarını etkili bir şekilde çözebilir.
2. Okuma ve yazma ayırma stratejisi, bağımlı düğüm, büyük eşzamanlı okuma işlemleriyle etkili bir şekilde başa çıkarak ana kütüphane düğümünün okuma yeteneğini genişletebilir.
Dezavantajları:
1. Arıza kurtarma karmaşıktır.RedisHA sistemi yoksa (geliştirme gereklidir), ana veritabanı düğümü başarısız olduğunda, bir bağımlı düğümün manuel olarak ana düğüme yükseltilmesi ve iş tarafının yapılandırmayı değiştirmek için bilgilendirilmesi ve diğer bağımlı veritabanı düğümlerinin çoğaltılması gerekir. Yeni ana kütüphane düğümü için, tüm süreç, zahmetli olan insan müdahalesini gerektirir.
2. Ana kütüphanenin yazma yeteneği tek bir makine ile sınırlıdır ve parçalanma düşünülebilir
3. Ana kütüphanenin depolama kapasitesi tek bir makine ile sınırlıdır, Pika'yı düşünebilirsiniz.
4. Yerel çoğaltmanın dezavantajları önceki sürümlerde daha belirgin olacaktır.Örneğin, Redis çoğaltması kesintiye uğradıktan sonra, Slave psync'i başlatacaktır. Senkronizasyon şu anda başarısız olursa, tam senkronizasyon gerçekleştirilecektir.Ana veritabanı aynı anda tam yedekleme yapabilir. Milisaniye veya saniye cinsinden kekemelik ve COW mekanizması nedeniyle, aşırı durumlarda ana kitaplık belleği taşar ve program anormal şekilde çıkar veya kilitlenir; ana kitaplık düğümü, yedek dosyaları oluşturur ve sunucu diski GÇ ve CPU (sıkıştırma) kaynak tüketimine neden olur; GB boyutlu yedekleme dosyası, sunucunun dışa aktarma bant genişliğinin fırlayıp istekleri engellemesine neden oldu. En son sürüme yükseltmeniz önerilir.
3 Redis Sentinel (Sentinel)
Redis Sentinel, topluluk sürümü tarafından başlatılan yerel bir yüksek kullanılabilirlik çözümüdür. Redis Sentinel dağıtım mimarisi temel olarak iki bölümden oluşur: Redis Sentinel kümesi ve Redis veri kümesi. Redis Sentinel kümesi, birkaç Sentinel düğümünden oluşan dağıtılmış bir kümedir. Arıza bulma, otomatik yük devretme, konfigürasyon merkezi ve istemci bildirimini gerçekleştirebilir. Redis Sentinel'in düğüm sayısı 2n + 1 (n > = 1) tek sayı.
avantaj:
1. Redis Sentinel küme dağıtımı basittir
2. Redis ana-bağımlı modunda yüksek kullanılabilirlik anahtarlama sorununu çözebilir
3. Redis veri düğümlerinin doğrusal genişlemesini gerçekleştirmek, Redis'in tek iş parçacığı darboğazını kolayca aşmak çok uygundur ve Redis'in büyük kapasiteli veya yüksek performansının iş ihtiyaçlarını büyük ölçüde karşılayabilir.
4. Bir grup Sentinel, bir Redis veri düğüm grubunu veya birden fazla veri düğüm grubunu izlemek için uygulanabilir
Dezavantajları:
1. Dağıtım, Redis ana-bağımlı modundan daha karmaşıktır ve ilke anlayışı daha zahmetlidir
2. Kaynakların boşa harcanması, Redis veri düğümündeki bağımlı düğüm, bir yedekleme düğümü olarak hizmet sağlamaz
3. Redis Sentinel, esas olarak Redis veri düğümündeki ana düğümün yüksek kullanılabilirlikli anahtarlaması içindir.Redis veri düğümünün başarısızlık kararı, öznel çevrimdışı ve nesnel çevrimdışı olarak bölünmüştür.Redis köle düğümü için, düğüme kadar öznel bir durum vardır. Çevrimiçi işlem ve yük devretme gerçekleştirilmez.
4. Okuma ve yazmanın ayrılması problemini çözemez ve uygulanması nispeten karmaşıktır
Önermek:
1. Aynı işi izliyorsanız, birden çok Redis veri düğüm grubunu izlemek için bir Sentinel kümesi seçebilir veya bir grup Redis veri düğümünü izlemek için bir Sentinel seçebilirsiniz.
2. Sentinel monitörü < usta adı > < ip > < Liman > < yeter sayı > Konfigürasyonda < yeter sayı > Sentinel düğümünün yarısı artı 1 olarak ayarlanması önerilir. Sentinel birden fazla IDC'de konuşlandırıldığında, tek bir IDC tarafından konuşlandırılan Sentinel sayısının (Sentinel sayı-çekirdek) aşılması önerilmez.
3. Yanlış kesimi önlemek ve anahtarlama hassasiyeti kontrolünü kontrol etmek için parametreleri makul şekilde ayarlayın
yeter sayı
milisaniye sonra aşağı 30000
yük devretme zaman aşımı 180000
maxclient
zaman aşımı
4. Konuşlandırılan her düğüm sunucusunun zamanı olabildiğince senkronize edilmelidir, aksi takdirde günlüğün zamanlaması karışacaktır.
5. Redis, RTT sayısını azaltmak ve istek verimliliğini artırmak için ardışık düzen ve çoklu anahtar işlemlerinin kullanılmasını önerir
6. İstemcinin örneğe bağlantı erişimini kolaylaştırmak için yapılandırma merkezini (zookeeper) kendiniz kurun
4 Redis Kümesi
Redis Cluster, topluluk sürümü tarafından başlatılan Redis dağıtılmış küme çözümüdür. Esas olarak Redis dağıtımının ihtiyaçlarını çözer. Örneğin, tek makineli bellek, eşzamanlılık ve trafik darboğazları ile karşılaşıldığında, Redis Kümesi iyi bir yük dengesi sağlayabilir amaç. Bir Redis Kümesi küme düğümü, minimum 6 veya daha fazla düğüm yapılandırmasına sahiptir (3 ana ve 3 ikincil düğüm) Ana düğüm okuma ve yazma işlemleri sağlar ve bağımlı düğüm, istek sağlamadan bir yedek düğüm görevi görür ve yalnızca yük devretme için kullanılır. Redis Kümesi, sanal yuva bölümleme kullanır.Tüm anahtarlar, karma işlevine göre 0-16383 tamsayı yuvalarına eşlenir.Her düğüm, yuvanın bir bölümünü ve yuva tarafından eşlenen anahtar değer verilerini korumaktan sorumludur.
avantaj:
1. Merkezi mimari yok
2. Veriler, yuvaya göre birden çok düğümde depolanır ve dağıtılır ve veriler düğümler arasında paylaşılır ve veri dağıtımı dinamik olarak ayarlanabilir.
3. Ölçeklenebilirlik, 1000'den fazla düğüme doğrusal genişleme, düğümler dinamik olarak eklenebilir veya silinebilir.
4. Yüksek kullanılabilirlik: Bazı düğümler kullanılamadığında, küme hala kullanılabilir. Yedek veri kopyası olarak Slave ekleyerek, otomatik yük devretme gerçekleştirilebilir Düğümler, dedikodu protokolü aracılığıyla durum bilgisi alışverişinde bulunur ve Slave'den Master'a rol yükseltmesini tamamlamak için oylama mekanizmasını kullanır.
5. İşletim ve bakım maliyetlerini azaltın, sistem ölçeklenebilirliğini ve kullanılabilirliğini iyileştirin.
Dezavantajları:
1. İstemcinin uygulanması karmaşıktır ve sürücü, geliştirme zorluğunu artıran ve müşterinin olgunlaşmamışlığı işin istikrarını etkileyen slot eşleştirme bilgilerini önbelleğe alan ve güncelleyen Smart Client uygulamasını gerektirir. Şu anda, yalnızca JedisCluster nispeten olgundur ve genel "maksimum yeniden yönlendirme istisnası" gibi istisna işleme kısmı mükemmel değildir.
2. Düğüm bazı nedenlerden dolayı engellenecek (engelleme süresi clutser-node-zaman aşımından daha büyüktür) ve çevrimdışı olarak değerlendirilecektir Bu tür bir yük devretme gerekli değildir.
3. Veriler, eşzamansız olarak çoğaltılır ve bu güçlü veri tutarlılığını garanti etmez.
4. Birden fazla işletme aynı kümeleri kullandığında, sıcak ve soğuk verileri istatistiklere dayalı olarak ayırt etmek imkansızdır ve kaynak izolasyonu zayıftır ve karşılıklı etkinin meydana gelmesi muhtemeldir.
5. Slave, kümede "soğuk bekleme" görevi görür ve okuma baskısını kaldıramaz.Elbette, Slave kaynaklarının kullanımı, SDK'nın makul tasarımı ile geliştirilebilir.
6. Anahtar toplu işlemlerle ilgili kısıtlamalar: Örneğin, mset ve mget şu anda yalnızca aynı yuva değerine sahip anahtarlar için toplu işlemleri desteklemektedir. Farklı yuva değerlerine eşlenen anahtarlar için, anahtarlar yuvalar arası sorguyu desteklemediğinden, mset, mget ve sunion gibi işlemleri gerçekleştirmek kolay değildir.
7. Anahtar işlem işlemi desteği sınırlıdır.Sadece aynı düğüm üzerindeki birden fazla anahtarın işlem işlemini destekler.Çok sayıda anahtar farklı düğümlere dağıtıldığında işlem işlevi kullanılamaz.
8. Anahtar, veri bölümünün en küçük ayrıntı düzeyidir, bu nedenle karma, liste vb. Gibi büyük bir anahtar-değer nesnesi farklı düğümlerle eşleştirilemez.
9. Çoklu veritabanı alanı desteklenmez Tek bir makinedeki Redis 16 adede kadar veritabanını destekleyebilir ve küme modunda yalnızca bir veritabanı alanı, yani db 0 kullanılabilir.
10. Çoğaltma yapısı yalnızca bir seviyeyi destekler, ikincil düğüm yalnızca ana düğümü çoğaltabilir ve iç içe geçmiş ağaç çoğaltma yapısı desteklenmez.
11. Ana kütüphane düğümünün sistemin bir kusuru olmasına neden olan kısayol tuşları oluşturmaktan kaçının.
12. Büyük anahtarlar oluşturmaktan, ağ kartı patlamalarına, yavaş sorgulara vb. Neden olmaktan kaçının.
13. Yeniden deneme süresi, küme düğümü süresinden daha büyük olmalıdır
14. Redis Cluster, maksimum yeniden yönlendirme ile oluşturulan senaryoları azaltmak için ardışık düzen ve çoklu anahtar işlemlerinin kullanılmasını önermez.
5 Redis kendi kendine araştırma önerilir
Redis'in kendi geliştirdiği yüksek kullanılabilirlik çözümleri esas olarak konfigürasyon merkezine, hata tespitine ve yük devretme işleme mekanizmalarına yansıtılır ve genellikle işletmenin işinin gerçek çevrimiçi ortamına göre özelleştirilmesi gerekir.
avantaj:
1. Yüksek güvenilirlik ve yüksek kullanılabilirlik
2. Yüksek özerklik ve kontrol edilebilirlik
3. Gerçek iş ihtiyaçlarına uygun, iyi ölçeklenebilirlik ve uyumluluk
Dezavantajları:
1. Karmaşık uygulama ve yüksek geliştirme maliyeti
2. İzleme, alan adı hizmeti, meta veri bilgilerini depolayan veritabanı vb. Gibi destekleyici çevre birimlerinin kurulması gereklidir.
3. Yüksek bakım maliyeti
Yazar: Zhang Donghong
