Örnek sorular
Redis PersistenceZorluk 1
Redis'te RDB persistence nedir?
- aHer yazma komutunun gerçekleştiği anda bir dosyaya eklendiği bir log
- bVeri setinin belirli bir andaki binary snapshot'ı✓
- cVeriyi gerçek zamanlı olarak bir replica node'a kopyalayan bir replikasyon mekanizması
- dVerinin diske hiç yazılmadığı, yalnızca bellekte tutulduğu bir mod
Açıklama:RDB (Redis Database) persistence, tüm veri setinin belirli bir andaki durumunun kompakt, binary bir snapshot'ını üretir. Append-only bir komut logu değildir (o AOF'tur, seçenek a), replikasyon değildir (seçenek c) ve gerçekten diske yazar, bu yüzden d yanlıştır.
Redis PersistenceZorluk 1
Redis'te AOF (Append Only File) persistence nedir?
- aVarsayılan olarak her saat alınan, veri setinin binary bir snapshot'ı
- bBir replica'nın verisini master ile senkron tutan bir özellik
- cAlınan yazma işlemlerinin yeniden oynatılabilir logu✓
- dDisk kullanımını azaltmak için RDB dosyalarına uygulanan bir sıkıştırma formatı
Açıklama:AOF, alınan her yazma işlemini olduğu gibi kaydeder; restart'ta Redis veri setini yeniden kurmak için bu logu tekrar oynatır. Periyodik bir snapshot değildir (o RDB'dir, seçenek a), replikasyon değildir (seçenek b) ve bir sıkıştırma şeması değildir (seçenek d).
Redis PersistenceZorluk 2
Bir ekip production'daki büyük veri setine sahip bir Redis instance'ında doğrudan SAVE çalıştırıyor ve sunucunun birkaç saniye boyunca hiçbir komuta yanıt vermediğini fark ediyor. En olası açıklama nedir?
- a
SAVE, RDB'yi Redis'in ana thread'inde senkron yazar ve bitene kadar komut işlemeyi bloklar✓ - b
SAVE büyük veri setlerinde her zaman sessizce başarısız olur ve donma tamamen ilgisiz bir network sorunundan kaynaklanır - c
SAVE, aslında sunucuyu bloklayan şey olan tam bir AOF rewrite tetikler - d
SAVE deprecated'dır ve modern Redis'te artık yoktur; bu yüzden komutun gözlemlenen gecikme dışında bir etkisi yoktur
Açıklama:SAVE ana thread'de çalışır ve snapshot yazımı bitene kadar diğer tüm komutları bloklar. BGSAVE ise snapshot'ı yazmak için bir child process fork eder, böylece parent process trafiğe hizmet vermeye devam eder. AOF rewrite (c) ayrı bir mekanizmadır ve SAVE hâlâ desteklenen gerçek bir komuttur (d).
Redis PersistenceZorluk 2
BGSAVE neden snapshot'ı ana Redis process'inden yazmak yerine bir child process fork eder?
- aÇünkü işletim sistemi herhangi bir dosya yazımı için fork yapılmasını zorunlu kılar
- bÇünkü child process, tüm platformlarda paralelliği garanti etmek için farklı bir CPU çekirdeğinde çalışır
- cÇünkü parent process hiçbir şekilde disk I/O'ya erişemez
- dBöylece parent process, child veri setinin copy-on-write bellek görünümünü kullanarak snapshot'ı yazarken client komutlarına hizmet vermeye devam edebilir✓
Açıklama:Fork etmek, child process'in bellekte tutarlı bir copy-on-write snapshot almasını sağlarken parent'ın istekleri kesintisiz işlemeye devam etmesine olanak tanır. Bu genel yazımlar için bir OS zorunluluğu değildir (a), çekirdek yerleşimi garanti edilmez (b) ve parent kesinlikle disk I/O yapabilir (c) — SAVE'in yaptığı tam olarak budur.
Redis PersistenceZorluk 1
appendonly yes
appendfsync everysec
appendfsync everysec ayarı ne anlama gelir?
- aRedis, her tek bir yazma komutundan sonra AOF dosyası üzerinde
fsync() çağırır - bRedis, AOF dosyası üzerinde en fazla saniyede bir kez
fsync() çağırır ve aradaki yazmaları biriktirir✓ - cRedis hiçbir zaman
fsync() çağırmaz ve tamamen işletim sisteminin kendi flush zamanlamasına güvenir - dRedis tüm AOF dosyasını her saniye baştan yeniden yazar
Açıklama:everysec, disk sync'lerini yaklaşık saniyede bire indirger; bu, her yazmada sync yapmaya (always, seçenek a) göre çok daha iyi throughput sağlarken, bunu tamamen OS'ye bırakmaktan (no, seçenek c) çok daha öngörülebilir tutar, karşılığında küçük bir potansiyel veri kaybı penceresi (yaklaşık ~1 saniyelik yazma) alınır. Dosyanın tamamını her saniye yeniden yazmak (d) fsync'in yaptığı şey değildir — o AOF rewrite'tır, ayrı bir işlemdir.
Redis PersistenceZorluk 2
Bir Redis instance'ı appendonly yes ve appendfsync everysec ile yapılandırılmış. Sunucu process'i bir elektrik kesintisi nedeniyle çöküyor. En kötü senaryoda Redis'in muhtemelen ne kadar veri kaybetmesi beklenir?
- aSon RDB snapshot'ından bu yana tüm veri, potansiyel olarak saatler süren yazmalar
- bHiçbir şey —
everysec her türlü hata durumunda sıfır veri kaybını garanti eder - cEn son yaklaşık bir saniyelik yazmaya kadar veri✓
- dYazma hacminden bağımsız olarak, tam olarak son tek bir yazma komutu
Açıklama:everysec ile yazmalar bufferlanır ve diske yaklaşık saniyede bir fsync edilir; bu yüzden bir çökme, son fsync'ten bu yana olan yazmaları kaybedebilir — yaklaşık ~1 saniyelik, sıfır değil (b) ve RDB snapshot aralıklarına bağlı da değil (a, bu yalnızca AOF devre dışıyken geçerli olurdu). Sabit tek bir komut da değildir (d) — bu bir komut sayısı değil, bir zaman penceresidir.