Redis'i uygulamalarınızda pratik şekilde kullanmayı öğrenin: önbellekleme, oturumlar, kuyruklar, pub/sub ve oran sınırlama—ayrıca ölçekleme, kalıcılık, izleme ve sık düşülen hatalar.
Redis, uygulamalar için sıkça kullanılan, bellek içi bir veri deposudur ve genellikle uygulamalar arasında paylaşılan “hızlı katman” olarak görev yapar. Takımların tercih etmesinin nedeni hızlı uygulanabilmesi, yaygın işlemler için son derece hızlı olması ve önbellek, oturumlar, sayaçlar, kuyruklar, pub/sub gibi birden çok işi ayrı bir sistem eklemeden halledebilecek esneklikte olmasıdır.
Pratikte Redis'i en iyi şekilde kullanmak, onu hız + koordinasyon olarak görmek; birincil veritabanınızı ise gerçeğin kaynağı olarak tutmaktır.
Yaygın bir kurulum şöyle görünür:
Bu ayrım veritabanınızı doğruluk ve dayanıklılığa odaklı tutar, Redis ise yüksek frekanslı okuma/yazma isteklerini üstlenerek gecikmeyi ve yükü azaltır.
Doğru kullanıldığında Redis birkaç somut fayda sağlar:
Redis birincil veritabanının yerine geçmez. Karmaşık sorgular, uzun süreli depolama garantileri veya analitik tarzı raporlama gerekiyorsa, veritabanınız doğru yerdir.
Ayrıca Redis’in “varsayılan olarak dayanıklı” olduğunu varsaymayın. Birkaç saniyelik veri kaybı kabul edilemezse, iş gereksinimlerinize göre dikkatli bir kalıcılık ayarı yapmanız veya farklı bir sistem seçmeniz gerekir.
Redis genellikle “anahtar-değer deposu” olarak tanımlanır, ama onu isimle saklanan küçük veri parçalarını tutup işleyebilen çok hızlı bir sunucu olarak düşünmek daha faydalıdır. Bu model, öngörülebilir erişim desenlerini teşvik eder: genellikle tam olarak ne istediğinizi bilirsiniz (bir oturum, önbelleğe alınmış sayfa, sayaç) ve Redis bunu tek bir turda getirip güncelleyebilir.
Redis veriyi RAM'de tutar; bu yüzden mikro saniye ila milisaniye düzeyinde cevap verebilir. Bunun bedeli, RAM'in diskten daha sınırlı ve pahalı olmasıdır.
Erken karar verin: Redis sadece bir performans katmanı mi (saf önbellek), yoksa yeniden başlatma davranışı ve kalıcılık ayarlarının önemli olduğu durum yolunun bir parçası mı (oturumlar, kuyruklar).
Redis veriyi disk üzerinde RDB snapshot'ları ve/veya AOF append-only logları ile kalıcılaştırabilir, ama kalıcılık yazma yükü ekler ve dayanıklılık tercihlerini gerektirir (ör. “hızlı ama bir saniye kaybedebilir” vs “daha yavaş ama daha güvenli”). Kalıcılığı, iş etkisine göre ayarlanacak bir düğme gibi düşünün; otomatik işaretlenecek bir seçenek olarak değil.
Redis komutları çoğunlukla tek bir iş parçacığında çalıştırır; bu sınırlayıcı görünse de iki şeyi unutmamak gerekir: işlemler genellikle küçüktür ve çoklu iş parçacıkları arasında kilitlenme yükü yoktur. Pahalı komutlardan ve aşırı büyük yüklerden kaçındığınız sürece bu model yüksek eşzamanlılık altında çok verimli olabilir.
Uygulamanız Redis ile TCP üzerinden istemci kütüphaneleri aracılığıyla konuşur. Bağlantı havuzlaması kullanın, istekleri küçük tutun ve birden çok işlem gerektiğinde toplama/pipelining tercih edin.
Zaman aşımı ve yeniden denemeler planlayın: Redis hızlıdır ama ağlar hızlı değildir; uygulamanız Redis meşgul veya geçici olarak kullanılamaz hale geldiğinde kademeli olarak bozunmalı.
Yeni bir servis geliştiriyorsanız ve bu temelleri hızla standart hale getirmek istiyorsanız, Koder.ai gibi bir platform React + Go + PostgreSQL uygulama iskeleti oluşturup Redis destekli özellikler (önbellekleme, oturumlar, oran sınırlama) eklemekte yardımcı olabilir—aynı zamanda kaynak kodunu dışa aktarmanıza ve istediğiniz yerde çalıştırmanıza izin verir.
Önbellekleme ancak açık bir sahiplik olduğunda işe yarar: kim doldurur, kim geçersiz kılar ve "yeterince taze" ne demektir.
Cache-aside, okumalar ve yazmaların kontrolünün Redis değil uygulamada olmasını sağlar.
Tipik akış:
Redis hızlı bir anahtar-değer deposudur; uygulamanız nasıl serileştirileceğine, versiyonlanacağına ve sonlandırılacağına karar verir.
TTL bir ürün kararıdır kadar teknik bir karardır. Kısa TTL’ler bayatlığı azaltır ama veritabanı yükünü artırır; uzun TTL’ler işi kurtarır ama eski sonuç riski taşır.
Pratik ipuçları:
user:v3:123) böylece eski önbellek yapıları yeni kodu bozmaz.Sıcak bir anahtarın süresi dolduğunda birçok istek aynı anda miss alabilir.
Yaygın savunmalar:
İyi adaylar: API yanıtları, pahalı sorgu sonuçları ve hesaplanmış nesneler (tavsiye listeleri, agregasyonlar). Tam HTML sayfalarını önbelleğe almak işe yarayabilir, ancak kişiselleştirme ve izinlerle dikkatli olun—kullanıcıya özgü mantık varsa parça önbellekleme tercih edin.
Redis, kısa ömürlü oturum durumu (oturum ID’leri, refresh-token meta verisi, "bu cihazı hatırla" bayrakları) için pratiktir. Amaç, kimlik doğrulamayı hızlı yapmak ve oturum ömrü ile iptalini sıkı kontrol altında tutmaktır.
Yaygın desen: uygulamanız rastgele bir oturum ID'si üretir, Redis'te kompakt bir kayıt saklar ve ID'yi HTTP-only cookie olarak tarayıcıya döner. Her istekte oturum anahtarını arar ve kullanıcı kimliğini ile izinleri istek bağlamına iliştirirsiniz.
Redis burada iyi çalışır çünkü oturum okumaları sık olur ve oturum süresi sonu yerleşiktir.
Anahtarları taraması ve iptal etmesi kolay olacak şekilde tasarlayın:
sess:{sessionId} → oturum yükü (userId, issuedAt, deviceId)user:sessions:{userId} → aktif oturum ID'lerinin Set'i (opsiyonel, “her yerde çıkış yap” için)sess:{sessionId} için oturum ömrüne uygun bir TTL kullanın. Oturumları döndürüyorsanız (önerilir), yeni bir oturum ID'si oluşturup eskiyi hemen silin.
Her istekte TTL uzatma (sliding expiration) ağır kullanıcılar için oturumları süresiz tutabilir. Daha güvenli bir yaklaşım, sadece oturum bitmeye yakınsa TTL’i uzatmaktır.
Tek bir cihazdan çıkış için sess:{sessionId} silin.
Cihazlar arası çıkış için ya:
user:sessions:{userId} içindeki tüm session ID’lerini silin, ya dauser:revoked_after:{userId} zaman damgası tutup, bu zamandan önce verilen oturumları geçersiz sayınZaman damgası yöntemi büyük fan-out silme işlemlerinden kaçınır.
Redis'te minimum gerekeni saklayın—kişisel veriler yerine ID’leri tercih edin. Ham parolaları veya uzun süreli sırları asla saklamayın. Token ile ilgili veriyi saklamanız gerekiyorsa hash şeklinde saklayın ve sıkı TTL’ler kullanın.
Redis’e kimlerin bağlanabileceğini sınırlayın, kimlik doğrulamayı zorunlu kılın ve oturum ID’lerini tahmin edilmesi zor olacak şekilde yüksek entropili yapın.
Oran sınırlama Redis’in güçlü olduğu alanlardan biridir: hızlıdır, uygulama örnekleriniz arasında paylaşılabilir ve yoğun trafik altında tutarlı sayaçlar için atomik işlemler sunar. Giriş noktalarını, pahalı aramaları, parola sıfırlama akışlarını ve taranan/brute-force yapılan API’leri korumak için idealdir.
Sabit pencere en basitidir: "dakikada 100 istek." Mevcut dakika kovasına sayarsınız. Kolaydır ama sınırda patlamaya izin verir (ör. 12:00:59'da 100 ve 12:01:00'da 100).
Kaydırmalı pencere sınırları düzleştirir; son N saniye/dakikaya bakar. Daha adildir ama genellikle daha maliyetlidir (sıralı setler veya daha fazla bookkeeping gerekebilir).
Token bucket patlamaları iyi yönetir. Kullanıcılar belirli aralıklarla token kazanır, bir istek bir token harcar. Kısa patlamalara izin verirken ortalama hızı korur.
Yaygın sabit pencere deseni:
INCR key ile sayacı arttırınEXPIRE key window_seconds ile TTL atayınBunu güvenli yapmak önemlidir. INCR ile EXPIRE ayrı çağrılarsa, arada bir çökme olursa süresiz anahtarlar oluşabilir.
Daha güvenli yaklaşımlar:
INCR ve expire atmayı yalnızca anahtar ilk oluşturulduğunda yapan bir Lua script kullanın.SET key 1 EX <ttl> NX kullanıp sonra INCR yapmak (yarışları önlemek için genellikle script ile birlikte).Atomik işlemler trafik patladığında en çok önem kazanır; bunlar yoksa iki istek aynı kalan kotayı "görebilir" ve ikisi de geçebilir.
Çoğu uygulama birkaç katmana ihtiyaç duyar:
rl:user:{userId}:{route}Patlamaya müsait uçlar için token bucket veya cömert bir sabit pencere + kısa "patlama" penceresi cezalandırıcı olmayan bir deneyim sağlar.
Önceden neyin “güvenli” olduğunu tanımlayın:
Orta yol genelde düşük riskli uçlar için fail-open, hassas uçlar (giriş, parola sıfırlama, OTP) için fail-closed kullanmak ve oran sınırlama durduğunda fark edebilmek için izleme kurmaktır.
Redis, e-posta gönderme, görsel yeniden boyutlandırma, veri senkronizasyonu veya periyodik işler gibi hafif iş yükleri için kuyruk sağlamak üzere kullanılabilir. Anahtar, doğru veri yapısını seçmek ve yeniden denemeler ile hata işleme için net kurallar koymaktır.
Listeler en basit kuyruğu sunar: üreticiler LPUSH, işçiler BRPOP. Kolaydır ama "iş uçta" takibi, yeniden denemeler ve görünürlük zaman aşımı için ekstra mantık gerekir.
Sorted set zamanlama önemliyse öne çıkar. Score olarak zaman damgası (veya öncelik) kullanın; işçiler bir sonraki vadesi gelen işi alır. Bu ertelenmiş işler ve öncelik kuyrukları için uygundur.
Streams genellikle sağlam iş dağıtımı için en iyi varsayılan seçimdir. Tüketici grupları, geçmiş tutma ve birden çok işçinin koordinasyonu gibi yerleşik destek sunar; kendi "işleme listesi" mantığınızı yeniden icat etmenize gerek kalmaz.
Streams tüketici grupları ile bir işçi mesaj okur ve daha sonra ACK eder. Eğer işçi çökse, mesaj beklemede kalır ve başka bir işçi tarafından alınabilir.
Yeniden denemeler için deneme sayısını (mesaj yükünde veya yan anahtar olarak) takip edin ve üstel geri çekilme uygulayın (genellikle bir sorted set ile "yeniden deneme takvimi"). Maksimum deneme sayısını aştıktan sonra işi manuel inceleme için dead-letter queue'ya (başka bir stream veya liste) taşıyın.
İşlerin iki kez çalıştırılabileceğini varsayın. İşleyicileri idempotent yapmak için:
job:{id}:done) ve yan etki yapmadan önce SET ... NX ile kontrol edinYükleri küçük tutun (büyük verileri başka yerde saklayıp referans geçin). Kuyruk uzunluğunu sınırlayarak, gecikme büyüdüğünde üreticileri yavaşlatarak ve bekleyen derinlik ile işleme süresine göre işçi sayısını ölçeklendirerek backpressure uygulayın.
Redis Pub/Sub, olayları yayınlamak için en basit yoldur: yayıncı bir kanala mesaj gönderir ve bağlı tüm aboneler mesajı hemen alır. Polling yoktur—hafif bir "push" mekanizmasıdır ve gerçek zamanlı güncellemeler için iyi çalışır.
Pub/Sub şu durumlarda iyidir:
Zihinsel model: Pub/Sub bir radyo istasyonu gibidir. Telsiz açık olan herkes yayını duyar, ama kimseye otomatik olarak bir kayıt vermez.
Pub/Sub'un önemli dezavantajları:
Bu nedenlerle Pub/Sub, her olayın işlenmek zorunda olduğu iş akışları için kötü bir seçimdir.
Eğer kalıcılık, yeniden deneme, tüketici grupları veya backpressure gerekiyorsa Redis Streams genellikle daha iyi bir seçimdir. Streams sayesinde olayları depolayabilir, ACK ile işleyebilir ve yeniden başlatmalardan sonra kurtarabilirsiniz—hafif bir mesaj kuyruğuna daha yakın bir deneyim sunar.
Gerçek dağıtımlarda birden çok uygulama örneği abone olacaktır. Pratik ipuçları:
app:{env}:{domain}:{event} (örn. shop:prod:orders:created).notifications:global, kullanıcıya özel için notifications:user:{id}.Bu kullanımda Pub/Sub hızlı bir olay “sinyali” iken, kaybetmeyi göze alamayacağınız olayları Streams (veya başka bir kuyruk) yönetir.
Veri yapısı seçimi sadece "ne işe yarıyor" değil—bellek kullanımı, sorgu hızı ve zaman içinde kodun sadeliğini de etkiler. İyi bir kural, ileride hangi soruları soracağınızı (okuma desenleri) düşünerek yapı seçmektir, sadece veriyi nasıl sakladığınıza göre değil.
INCR/DECR ile atomik sayaçlar için de uygundur.SISMEMBER hızlıdır ve set işlemleri kolaydır.Redis komutları komut düzeyinde atomiktir, bu yüzden sayaçları yarış olmadan güvenle artırabilirsiniz. Sayfa görüntüleme ve oran-limit sayaçları genellikle expiry ile birlikte INCR ile yapılır.
Lider tablolarında sorted setler öne çıkar: skorları (ZINCRBY) güncelleyebilir ve en iyi oyuncuları (ZREVRANGE) verimli şekilde alabilirsiniz.
user:123:name, user:123:email, user:123:plan gibi çok sayıda anahtar oluşturmak anahtar başına ek bellek maliyeti yaratır ve yönetimi zorlaştırır.
Bunun yerine user:123 gibi bir hash ile name, email, plan alanlarını tutmak ilişkili veriyi bir arada tutar ve küçük güncellemeleri kolaylaştırır.
Şüphedeyseniz küçük bir örnek modelleyin ve yüksek hacimli veri için belleği ölçün.
Redis “bellek içi” olarak anılır, ama bir düğüm yeniden başlatıldığında, disk dolduğunda veya bir sunucu kaybolduğunda ne olacağı konusunda seçenekleriniz vardır. Doğru kurulum ne kadar veri kaybedebileceğinize ve ne kadar hızlı kurtulmanız gerektiğine bağlıdır.
RDB snapshot'ları veri setinizin nokta zamanı dökümünü kaydeder. Kompakt ve başlangıçta hızlı yüklenir; bu da yeniden başlatmaları hızlandırır. Dezavantajı, en son yazılanların kaybolabilmesidir.
AOF yazma işlemlerini gerçekleştikçe loglar. Genelde daha az veri kaybı sağlar ancak dosyalar büyüyebilir ve başlangıçta oynatma süresi uzayabilir—Redis AOF sıkıştırma/yeniden yazma ile bunu yönetir.
Birçok ekip her ikisini çalıştırır: daha hızlı yeniden başlatma için snapshot, daha iyi yazma dayanıklılığı için AOF.
Kalıcılık ücretsiz değildir. Disk yazmaları, AOF fsync politikaları ve arka plan yeniden yazma operasyonları, depolama yavaş veya doluysa gecikme sıçramalarına neden olabilir. Öte yandan kalıcılık, yeniden başlatmaları daha az korkutucu yapar: kalıcılık yoksa plansız bir yeniden başlatma boş bir Redis ile sonuçlanır.
Replikasyon, verinin kopyalarını replikalarda tutar, böylece birincil düştüğünde failover yapılabilir. Amaç genelde kullanılabilirlikdir, kusursuz tutarlılık değil. Arıza sırasında replikalar biraz geride kalabilir ve failover bazı son yazmaları kaybedebilir.
Herhangi bir şeyi ayarlamadan önce iki sayı yazın:
Bu hedefleri kullanarak RDB sıklığını, AOF ayarlarını ve replika/failover gereksinimlerini belirleyin—Redis rolünüz cache, oturum deposu, kuyruk veya birincil veri deposu olabilir.
Tek bir Redis düğümü sizi şaşırtıcı şekilde uzağa taşıyabilir: işletmesi basit, kafası kolay ve çoğu önbellek, oturum veya kuyruk iş yükü için genelde yeterince hızlıdır.
Ölçeklendirme, genellikle bellek sınırı, CPU doygunluğu veya tek düğümün kabul edilemez tek hata noktası olması gibi sert sınırlara geldiğinizde gerekli olur.
Aşağıdakilerden biri oluştuğunda daha fazla düğüm eklemeyi düşünün:
Pratik bir ilk adım genellikle iş yüklerini ayırmak (iki bağımsız Redis örneği) ve ardından kümelemeye geçmektir.
Sharding, anahtarlarınızı birden fazla Redis düğümüne bölmek demektir, böylece her düğüm sadece verinin bir kısmını tutar. Redis Cluster, anahtar alanını slotlara böler ve her düğüm bazı slotlara sahip olur.
Kazanım: toplam bellek ve toplam aktarım kapasitesi artar. Maliyet: karmaşıklık yükselir; çoklu anahtar işlemleri kısıtlanır (anahtarların aynı shard üzerinde olması gerekir) ve sorun giderme daha fazla parçayı içerir.
Eşit sharding olsa bile gerçek trafik dengesiz olabilir. Çok popüler bir anahtar ("hot key") bir düğümü aşırı yükleyebilir.
Azaltma yöntemleri: kısa TTL’ler ve jitter eklemek, değeri birden çok anahtara bölmek (key hashing) veya okuma desenlerini yeniden tasarlamak.
Redis Cluster cluster-aware bir istemci gerektirir—topolojiyi keşfetmeli, istekleri doğru düğüme yönlendirmeli ve slotlar taşındığında yönlendirmeyi takip etmelidir.
Geçmeden önce doğrulayın:
Ölçeklendirme planlı bir evrim olduğunda daha başarılı olur: yük testleriyle doğrulayın, anahtar gecikmesini ölçün ve trafiği kademeli olarak taşıyın.
Redis sıkça "iç boru hattı" olarak görülür; tam da bu yüzden hedef olur: tek açık port büyük bir veri sızıntısına ya da saldırgan kontrollü bir cache'e dönüşebilir. Redis'i hassas altyapı olarak değerlendirin, hatta sadece "geçici" veri saklasanız bile.
Önce kimlik doğrulamayı etkinleştirin ve ACL'leri (Redis 6+) kullanın. ACL'ler ile:
Tek bir parolayı tüm bileşenlerle paylaşmaktan kaçının. Hizmet başına ayrı kimlik bilgileri verin ve izinleri dar tutun.
En etkili kontrol Redis’in erişilebilir olmamasıdır. Redis’i özel bir arayüze bağlayın, özel bir alt ağa yerleştirin ve güvenlik grupları/firewall ile yalnızca ihtiyaç duyan hizmetlerin erişimini kısıtlayın.
Redis trafiği kontrolünüz dışında bir host sınırını geçiyorsa (çok AZ, paylaşılan ağlar, Kubernetes düğümleri veya hibrit ortamlar) TLS kullanın. TLS, dinleme ve kimlik bilgisi hırsızlığını engeller ve oturum tokenları veya kullanıcı verisi olan durumlarda küçük bir ek maliyete değer.
Kötüye kullanım durumunda büyük hasara yol açabilecek komutları kısıtlayın. Sıkça kısıtlanması veya ACL ile denetlenmesi gerekenler: FLUSHALL, FLUSHDB, CONFIG, SAVE, DEBUG, EVAL. rename-command yolunu dikkatle kullanın—ACL'ler genelde daha açık ve denetlenmesi kolaydır.
Redis kimlik bilgilerini kodda veya container görüntülerinde tutmayın; bir secrets manager kullanın ve rotasyon planlayın. Rotasyon, istemcilerin yeniden dağıtılmadan kimlik bilgilerini yeniden yükleyebilmesi veya geçiş penceresinde iki geçerli kimlik bilgisi desteklenmesiyle kolaylaşır.
Çalışma kitapçığınıza (runbooks) bu kontrol listesini ekleyin ve operasyon notlarınızı /blog/monitoring-troubleshooting-redis gibi bir yerde tutun.
Redis çoğunlukla “iyi görünüyor” hissi verir… ta ki trafik değişene, bellek yavaşça artana veya yavaş bir komut her şeyi durdurana kadar. Hafif bir izleme rutini ve net bir olay kılavuzu çoğu sürprizi önler.
Takıma açıklayabileceğiniz küçük bir setle başlayın:
Bir şey “yavaş” olduğunda Redis’in kendi araçlarıyla doğrulayın:
KEYS, SMEMBERS veya büyük LRANGE çağrılarında alarm verir.Eğer gecikme artarken CPU normal görünüyorsa, ağ doygunluğunu, aşırı büyük payload’ları veya bloklanan istemcileri kontrol edin.
Büyümeyi planlarken headroom bırakın (genelde %20–30 boş bellek) ve lansmanlar ya da feature flag’lerden sonra varsayımları gözden geçirin. "Sürekli evictions"ı bir uyarı değil, bir kesinti olarak ele alın.
Olay sırasında sırayla kontrol edin: bellek/evictions, gecikme, istemci bağlantıları, slowlog, replikasyon gecikmesi ve son dağıtımlar. Tekrarlayan temel nedenleri yazın ve kalıcı düzeltmeler yapın—sadece alarmlar yeterli değildir.
Hızla iterasyon yapan ekipler için bu operasyonel beklentileri geliştirme iş akışınıza dahil etmek faydalıdır. Örneğin, Koder.ai’nın planlama modu, anlık görüntüler ve geri alma yetenekleri ile Redis destekli özellikleri (önbellekleme, oran sınırlama) yük altında test etmenize, kod tabanınızda tutmanıza ve gerektiğinde geri almanıza yardımcı olabilir.
Redis, paylaşılan, bellek içi bir “hız katmanı” olarak en iyi şekilde kullanılır:
Dayanıklı, yetkili veri ve karmaşık sorgular için birincil veritabanınızı kullanmaya devam edin. Redis’i hız arttırıcı ve koordinatör olarak değerlendirin; kayıt kaynağı olarak değil.
Hayır. Redis veri kalıcılaştırma yeteneklerine sahip olabilir, ancak “varsayılan olarak dayanıklı” değildir. Karmaşık sorgular, güçlü dayanıklılık garantileri veya analitik/raporlama ihtiyacı varsa bu veriler birincil veritabanında tutulmalı.
Birkaç saniyelik veri kaybının kabul edilemez olduğu durumlarda, Redis’in varsayılan ayarlarının yeterli olacağını varsaymayın; doğru yapılandırma veya farklı bir sistem düşünün.
Kabul edilebilir veri kaybı ve yeniden başlatma davranışına göre karar verin:
Önce RPO/RTO hedeflerinizi yazın, sonra kalıcılık ayarlarını buna göre düzenleyin.
Cache-aside modelinde uygulamanız mantığı yönetir:
Bu model, ara sıra miss’leri tolere edebilen ve süre sonlandırma/geçersiz kılma planı olan uygulamalar için uygundur.
TTL’leri kullanıcı etkisi ve arka uç yükü gözeterek seçin:
user:v3:123).Emin değilseniz daha kısa başlayın, veritabanı yükünü ölçün ve ayarlayın.
Aşağıdakilerden birini veya birkaçını kullanın:
Bu desenler, eşzamanlı cache miss’lerin veritabanınızı boğmasını engeller.
Güvenli bir yöntem genelde şöyledir:
sess:{sessionId} altında oturum verisini TTL ile saklayın (oturum süresine uygun).user:sessions:{userId} ile aktif oturum ID’lerini bir Set olarak tutun (tüm cihazlardan çıkış için).Her istekte TTL uzatma (sliding expiration) yapmaktan kaçının; bunun yerine sadece bitmeye yakın olduğunda uzatmak daha güvenlidir.
Sayacı doğru ve yarışsız tutmak için atomik güncellemeler kullanın:
INCR ve EXPIRE'i ayrı, korumasız çağrılar halinde çalıştırmayın.INCR ve expire atmayı yapan bir Lua script kullanmak güvenlidir.Anahtarları uygun şekilde ölçekleyin (user, IP, route) ve Redis ulaşılamadığında önce açık mı kapalı mı davranacağınıza (fail-open vs fail-closed) karar verin—özellikle giriş gibi hassas yollar için.
İhtiyaçlarınıza göre seçin:
LPUSH/BRPOP): basit, ama yeniden deneme, uçta bekleyen işler ve görünürlük zaman aşımı için ekstra mantık gerekir.Kısa yanıt:
Ayrıca operasyonel hijyen için ACL'ler, ağ izole etme ve gecikme/eviction izleme uygulayın; bir runbook’a (ör. /blog/monitoring-troubleshooting-redis) sahiptirseniz bunu oraya ekleyin.
İş yüklerini küçük tutun; büyük blob’ları başka yerde saklayıp referans geçin.