|
|
Yayınlandı 4.02.2021 13:47:27
|
|
|
|
1. Önsöz
Son zamanlarda, Redis projede birden fazla iş süreci arasında veri paylaşımını kolaylaştırmak için bir önbellek olarak kullanılmıştır. Redis verileri bellekte saklandığı için, persistence ayarlanmazsa, redis yeniden başlatıldığında tüm veriler kaybolur, bu yüzden verileri diske kaydetmek için Redis'in süreklilik fonksiyonunu etkinleştirmeniz gerekir ve redis yeniden başlatıldığında diskten veri kurtarılabilir. Redis, sürekliliğin iki yolu sunar: RDB kalıcılığı (prensip Reids'in veritabanı kayıtlarını diskteki RDB kalıcılığına bellekte aktarmaktır) ve diğeri AOF kalıcılığıdır (prensip Reids'in işlem kayıtlarını ek şeklinde bir dosyaya yazmaktır). Peki bu iki süreklilik yöntemi arasındaki fark nedir ve bunu nasıl değiştirebiliriz? İnternette okuduğum çoğu şey bu iki yöntemin nasıl yapılandırılacağını ve kullanılacağını tanıtıyor, ancak ikisi arasındaki fark ve hangi uygulama senaryolarında kullanılacağı hakkında bir giriş yok.
2. İkisi arasındaki fark
RDB kalıcılığı, veri setinin bellekteki anlık görüntüsünü belirli bir zaman aralığı içinde diske yazmayı ifade eder ve gerçek işlem süreci, bir alt süreci çatallamak, önce veri setini geçici bir dosyaya yazmak, yazım başarılı olduktan sonra önceki dosyayı değiştirmek ve ikili sıkıştırma ile depolamaktır.
AOF kalıcılığı, sunucu tarafından işlendiği her yazma ve silme işlemini bir log şeklinde kaydeder ve sorgulama işlemi kaydedilmez, metin olarak kaydedilir ve dosyayı açıp detaylı işlem kaydını görebilirsiniz.
3. İkisinin avantajları ve dezavantajları
RDB'nin avantajları nelerdir?
1). Bu kullanıldıktan sonra, tüm Redis veritabanınız sadece bir dosya içerecek ve bu dosya yedeklemeleri için mükemmeldir. Örneğin, son 24 saati her saat arşivlemek isteyebilirsiniz ve ayrıca son 30 günü de her gün arşivlemek isteyebilirsiniz. Böyle bir yedek stratejiyle, sistemin felaket bir arızası durumunda kolayca toparlanabiliriz.
2). RDB, felaket kurtarma için çok iyi bir seçimdir. Çünkü tek bir dosyayı kolayca sıkıştırıp başka bir depolama ortamına aktarabiliyoruz.
3). Performansı en üst düzeye çıkarın. Redis servis süreci için, persistence başlatıldığında yapması gereken tek şey child süreçleri çatallamaktır; ardından alt süreçler bu persistence görevlerini tamamlar, bu da servis sürecinin IO işlemlerini büyük ölçüde engellemesini engeller.
4). AOF mekanizmasına kıyasla, veri seti büyükse, RDB'nin başlangıç verimliliği daha yüksek olur.
RDB'nin dezavantajları nelerdir?
1). Eğer yüksek veri erişilebilirliğini sağlamak istiyorsanız, yani veri kaybını en büyük ölçüde önlemek istiyorsanız, RDB iyi bir tercih olmayacak. Çünkü sistem planlanan kalıcılıktan önce çökerse, daha önce diske yazılmış veriler kaybolur.
2). RDB, çatal alt süreçleri aracılığıyla veri kalıcılığına yardımcı olduğundan, veri seti büyükse, tüm sunucunun yüzlerce milisaniye veya hatta 1 saniye boyunca hizmetin durmasına neden olabilir.
AOF'nin avantajları nelerdir?
1). Bu mekanizma, veri güvenliğini artırabilir, yani veri kalıcılığı. Redis'te 3 senkronizasyon stratejisi sunulmaktadır: saniye başına senkronizasyon, modifikasyon başına senkronizasyon ve senkronizasyonun çıkarılması. Aslında, saniyede senkronizasyon da asenkron olarak yapılır ve verimliliği de çok yüksektir; fark şu ki, sistem çöktükten sonra değiştirilmiş veriler bu saniye içinde kaybolur. Ve her değişiklik senkronize edildiğinde, bunu senkronizasyon kalıcılığı olarak düşünebiliriz; yani gerçekleşen her veri değişikliği hemen diske kaydedilir. Bu yöntemin en az verimli yöntem olduğu öngörülebilir. Senkronizasyon olmamasına gelince, daha fazla söylemeye gerek yok, bence herkes doğru anlayabilir.
2). Mekanizma, log dosyalarını yazmak için eklenti modunu benimsediğinden, yazı sürecinde bir kesinti olsa bile, log dosyasında zaten var olan içerik yok edilmez. Ancak, bu sefer verinin sadece yarısını yazarsak ve sistem çökerse, endişelenmeyin, Redis'in bir sonraki başlangıcından önce veri tutarlılığı sorununu çözmek için redis-check-aof aracını kullanabiliriz.
3). Eğer log çok büyükse, Redis otomatik olarak yeniden yazma mekanizmasını etkinleştirebilir. Yani, Redis ekleme modunda mod verisini sürekli olarak eski disk dosyasına yazar ve bu süre boyunca hangi modifikasyon komutlarının yürütüldüğünü kaydetmek için yeni bir dosya oluşturur. Bu nedenle, yeniden yazmalar arasında geçiş yaparken veri güvenliği daha iyi garanti edilebilir.
4). AOF, tüm değişiklikleri kaydeden açık ve anlaşılması kolay bir günlük dosyası içerir. Aslında, bu dosya aracılığıyla verilerin yeniden yapılandırılmasını da tamamlayabiliriz.
OV'nin dezavantajları nelerdir?
1). Aynı sayıda veri seti için, OF dosyaları genellikle RDB dosyalarından daha büyüktür. RDB, büyük veri setlerini AOF'den daha hızlı kurtarır.
2). Senkronizasyon stratejisine bağlı olarak, AOF çalışma verimliliği açısından RDB'den daha yavaştır. Kısacası, senkronizasyon politikasının saniye başındaki verimliliği nispeten yüksektir ve senkron devre dışı bırakma politikasının verimliliği RDB kadar verimlidir.
İkisini seçme kriterleri, sistemin daha yüksek önbellek tutarlılığı (AOF) karşılığında performanstan feda etmeye istekli olup olmadığı veya yazım işlemleri sık olduğunda daha yüksek performans karşılığında yedeklemeleri etkinleştirmemeye istekli olup olmadığı ve ardından KaydEt'i manuel çalıştırırken yedekleme (RDB) yapması olabilir. rdb'nin daha nihai tutarlı bir anlamı vardır. Ancak üretim ortamı aslında ikisinin birleşiminden oluşuyor.
4. Yaygın konfigürasyonlar
RDB süreklilik yapılandırması
Redis, veri setinin bir anlık görüntüsünü dump.rdb dosyasına döker. Ayrıca, yapılandırma dosyası üzerinden Redis sunucu döküm anlık görüntülerinin sıklığını da değiştirebiliriz; 6379.conf dosyasını açtıktan sonra kaydetme ararız ve aşağıdaki yapılandırma bilgilerini görebiliyoruz:
AOF kalıcı yapılandırması
Redis profilinde senkronize olmanın üç yolu vardır:
Tam yapılandırma:
Test dizininde yeni bir "appendonly.aof" dosyası oluşturulur, aşağıdaki gibidir:
|
Önceki:DataTables tablo dışa aktarma Excel, CSV ve baskı uygularÖnümüzdeki:SQL Server, işlem izolasyon seviyesini belirler
|
Ev sahibi|
Yayınlandı 8.02.2021 11:45:25
|
Yayınlandı 22.09.2021 20:26:16