Redis ile veri erişimini tasarlayın.

Önbellek, oturum ve olay akışları için bellek içi veri yapılarını uygulamanızın ihtiyaçlarına göre ele alıyoruz.

İhtiyacınızı konuşalım
Redis ile bellekte veri paylaşımı Bellek katmanları ve veri yolları, uygulamadaki önbellek ve olay akışı kullanımını temsil ediyor. Katmanlar ve kayıtlar temsilidir.
ÖnbellekOlay akışlarıOlasılıksal yapılar

Kullanım alanları.

Redis için olası kullanım alanlarını işinize ve mevcut altyapınıza göre değerlendiriyoruz.

Önbellekleme

Sık okunan ürün, içerik veya sorgu sonuçlarını önbelleğe alabiliriz. Verinin ne kadar süre saklanacağı ve değiştiğinde nasıl yenileneceği kullanım senaryosuna göre belirlenir.

Oturumlar ve sayaçlar

Kullanıcı oturumları, sayaçlar ve istek hızı sınırları için uygun veri yapılarını değerlendiririz. Süre aşımı ve sınır aşıldığında uygulamanın davranışı birlikte tasarlanır.

Olaylar ve işler

Olay akışları ve arka plan işlerinin işlenmesi için Redis Streams gibi seçenekleri değerlendiririz. Tekrar işleme, hata ve tüketici davranışları uygulamanın ihtiyaçlarına göre ele alınır.

Üyelik ve tekrar kontrolü

Bloom ve Cuckoo filtreleriyle bir kaydın veya olayın daha önce görülüp görülmediğine dair ön kontrol yapabiliriz. Olası eşleşmelerin doğrulanmasını ve filtrelerin güncel tutulmasını uygulamayla birlikte ele alırız.

Yaklaşık ölçüm ve analiz

HyperLogLog tekil sayıları; Count-Min Sketch ve Top-K sıklık ve popülerliği; t-digest ise ölçümlerin yüzdeliklerini yaklaşık hesaplamak için kullanılabilir.

Nasıl destek oluruz?

Çalışmanın kapsamını ihtiyacınıza, mevcut sistemlerinize ve ekibinizin önceliklerine göre belirliyoruz.

Filtre ve analiz tasarımı

Filtrelerin kapasitesini, hata payını ve kaynak verilerle güncel kalmasını planlarız. Sıklık, popülerlik ve yüzdelik hesaplamaları için zaman aralığını belirleriz. Redis 8’in resmî ikili dağıtımlarında ek filtre ve analiz yapıları bulunur; eski kurulumlarda bunlar için Redis Stack veya RedisBloom gerekebilir. HyperLogLog yerleşiktir; her kurulumda komutları kontrol ederiz.

Örnek senaryolar.

Bu örnekler, farklı ihtiyaçlar için neler geliştirilebileceğini gösteriyor.
70 senaryo ve 4 ileri deseni inceleyin

Örnek: önbellekteki veriye erişim
  1. Uygulama isteği
  2. Redis önbelleği
  3. Önbellekteki veri

Veri önbellekte bulunmazsa kaynak sisteme başvurulabilir.

Ürün kataloğu önbelleği

Bir mağaza, sık görüntülenen ürün bilgilerini önbellekte tutabilir. Ürün değiştiğinde ilgili kayıtların nasıl yenileneceği kaynak sistemle birlikte planlanır.

API istek sınırları

Bir servis, belirli bir zaman aralığındaki istekleri sayarak kullanım sınırları uygulayabilir. Sınır aşıldığında verilecek yanıt uygulamanın kurallarına göre belirlenir.

Olmayan kayıtların ön kontrolü

Güncel ve eksiksiz bir Bloom filtresi, katalogda bulunmayan ürün kimliklerini veritabanı sorgusundan önce eleyebilir. Filtrenin hazır veya güncel olmadığı durumlarda ana kaynağa başvurulur; olası eşleşmeler de orada doğrulanır.

Kupon ve kampanya kontrolü

Bir Cuckoo filtresi geçerli kuponlar için ön kontrol yapabilir. Olası eşleşme ana kayıtta doğrulanır; tek kullanımlık kuponlar ve eşzamanlı kullanımlar ana sistemde yönetilir ve yalnızca gerçekten eklenmiş öğeler filtreden çıkarılır.

Olay ve webhook tekrarları

Bir Bloom filtresi, daha önce işlenmiş olabilecek olay kimliklerini ayırabilir. Olası tekrar kesin kayıttan doğrulanır; filtre tek başına kayıpsız veya yalnızca bir kez işleme garantisi vermez.

Popüler aramalar ve yoğun istekler

Count-Min Sketch ile bir arama teriminin veya uç noktanın görülme sıklığı, Top-K ile sık görülenler yaklaşık izlenebilir. Zaman aralığını uygulama yönetir; kesin kota kararları için ayrı sayaçlar kullanılır.

Servis yanıt süreleri

t-digest ile API yanıt sürelerinin p50, p95 veya p99 yüzdelikleri tahmin edilebilir. Sonuçların anlamlı olması için gözlem sayısı ve ölçüm dönemi dikkate alınır.

Tekil ziyaretçi ve kampanya erişimi

HyperLogLog, bir dönemdeki farklı ziyaretçilerin veya kampanyaya erişen kullanıcıların sayısını yaklaşık hesaplayabilir. Kişileri listelemez ve bir kişinin kümede olup olmadığını göstermez.

İşlem ve cihaz risk sinyalleri

Kullanıcı–cihaz geçmişi için Bloom filtresi ve bir IP’den gelen farklı hesapların sayısı için HyperLogLog kullanılabilir. Bu yaklaşık sinyaller, risk incelemesinde kesin kayıtlar ve diğer kurallarla birlikte değerlendirilir.

Filtre ve analiz örnekleri.

Bu katalog, yukarıdaki örneklerle birlikte farklı kullanım alanlarını da içerir. Her başlığı açarak senaryoları ve uygulama koşullarını inceleyin.

Bloom ile üyelik ön kontrolü18 örnek

Bloom filtreleri yanlış pozitif üretebilir ve tekil öğe silmez. Filtre eksik veya güncel değilse ana kaynağa başvurulur; olası eşleşmeler kesin kayıtta doğrulanır.

  • İşlem konumu. Geçmişte kullanılan konumlar ön kontrolden geçirilir; yeni bir konum tek başına dolandırıcılık kanıtı değildir.
  • Cihaz, IP ve e-posta geçmişi. Kullanıcıyla ilişkili cihaz veya adreslerin görülüp görülmediği incelenir; kimlik doğrulama ayrıca yapılır.
  • Satıcı, kategori ve tutar aralığı. Kullanıcı, satıcı, kategori ve uygulamanın belirlediği tutar aralıkları risk değerlendirmesine sinyal verebilir.
  • Bilinen risk kayıtları. Kayıp veya çalıntı kartlar ve riskli kimlikler ön kontrolden geçirilir; olası eşleşmeler ana listede doğrulanır.
  • Olmayan kayıtlar. Güncel ve eksiksiz filtre, bulunmayan ürün, hesap veya belge kimliklerini veritabanı sorgusundan önce eleyebilir.
  • Kullanıcı adı, e-posta ve içerik adresi. Kullanılmış olabilecek adlar önceden kontrol edilir; kesin benzersizlik veritabanında korunur.
  • Reklam tekrarları. Daha önce gösterilmiş olabilecek reklamlar ayrılabilir; gösterim sınırları için ayrıca sayaç gerekir.
  • İçerik, ürün ve arkadaş önerileri. Görülmüş olabilecek adaylar elenebilir; yanlış pozitif yeni bir adayı da gizleyebilir.
  • Taranmış URL’ler. Daha önce ziyaret edilmiş olabilecek adresler ayrılır; yeniden tarama takvimini uygulama yönetir.
  • Olay ve webhook tekrarları. Olası tekrarlar kesin kayıtta doğrulanır; filtre tek başına yalnızca bir kez işleme garantisi vermez.
  • Dosya ve veri blokları. Olası tekrarlar disk indeksinde doğrulanır; yeni veri yalnızca filtre sonucuna dayanarak atılmaz.
  • Zararlı adresler. URL, alan adı veya IP için olası risk eşleşmeleri doğrulanır; listede olmamak güvenlik garantisi değildir.
  • Sözlük ön kontrolü. Olası kelime eşleşmesi sözlükte doğrulanır; filtre düzeltme önerisi üretmez.
  • Disk dosyası okumaları. Dosya veya blok özetleri ilgisiz okumaları elemek için kullanılabilir; depolama katmanına özel entegrasyon gerekir.
  • Parquet parçaları. Sütun parçaları için ön eleme tasarlanabilir; Parquet’in kendi filtresi ayrı bir uygulamadır.
  • Log ve trace blokları. Kimlik içermeyen bloklar önceden elenebilir; özel indeksleme ve sorgu entegrasyonu gerekir.
  • Join öncesi eleme. Eşleşemeyecek anahtarlar ayrılabilir; gerçek join işlemi yine sorgu motorunda yapılır.
  • Dağıtık önbellek dizini. Olası düğümler özetlerle seçilir; içerik ilgili düğümden doğrulanır ve özetler güncel tutulur.
Cuckoo ile değişen üyelik10 örnek

Cuckoo filtreleri olası üyeliği denetler ve silmeyi destekler. Yalnızca gerçekten eklenmiş öğeler silinir; eşzamanlılık, süre ve kesin kararlar uygulamada yönetilir.

  • Kampanya hedef kitlesi. Katılımı doğrulanan kişiler aday kümesinden çıkarılabilir; katılım kaydı ayrıca tutulur.
  • Kuponlar. Geçerli kodlar ön kontrolden geçirilir; tek kullanımlık koşulu eşzamanlı isteklerde ana sistemde atomik olarak yönetilir.
  • Değişen risk ve güven listeleri. İnceleme sonucuna göre cihaz veya hesaplar listeye eklenir ya da listeden çıkarılır.
  • İptal edilen token ve API anahtarları. İptal kayıtları ön kontrolden geçirilir; imza, süre ve yetki doğrulaması ayrıca yapılır.
  • Oturum ve çevrimiçi cihazlar. Oturum veya WebSocket açılışında ve doğrulanmış kapanışta üyelik güncellenir; gerçek durum ayrıca tutulur.
  • Aktif katalog ve stok. Aktif ürünler ön kontrolden geçirilir; stok adedi ve rezervasyon kararları ana kayıtta tutulur.
  • Önbellek düğümleri. Nesnelerin bulunabileceği düğümler izlenir; çıkarma ve önbellek yenileme birlikte yönetilir.
  • Süreli olay ve URL takibi. Bir dönemde görülen kimlikler izlenir; süre ve çıkarma işlemlerini uygulama yönetir.
  • İçerik gizleme tercihleri. Geri alınabilen tercihler aday listesini süzebilir; asıl tercih kaydı ayrıca korunur.
  • İş ve abonelikler. Bekleyen iş veya aktif abonelikler ön kontrolden geçirilir; kilit ve yetki kararı ayrıca verilir.
Count-Min Sketch ile sıklık10 örnek

Count-Min Sketch bilinen öğelerin sıklığını yaklaşık tahmin eder. Adayları kendisi listelemez; dönem, kesin kota ve mali kayıtlar ayrıca yönetilir.

  • Ürün talebi. Ürün başına satış veya görüntülenme sıklığı izlenebilir; mali kayıt ayrı tutulur.
  • Giriş denemeleri. Kullanıcı veya IP başına artan denemeler inceleme sinyali verebilir; kesin engelleme için doğrulama gerekir.
  • Kart–işyeri tekrarları. İşlem eşleşmelerinin sıklığı risk değerlendirmesine girdi olabilir; tek başına dolandırıcılık kanıtı değildir.
  • API kullanımı ve kota. İstek sayısı yüksek müşteri ve uç noktalar incelenebilir; faturalama ve kesin kotalar ayrı kayıtlara dayanır.
  • Reklam gösterim sıklığı. Kullanıcı ve kampanya bazında gösterim yoğunluğu izlenir; sözleşmesel sayımlar ayrıca tutulur.
  • Log, hata ve cihaz olayları. Bilinen hata kodlarının veya cihaz olaylarının sıklığı izlenir; ham olay kayıtları korunur.
  • Sözcük, n-gram ve arama terimleri. Bilinen terimlerin sıklıkları karşılaştırılır; metnin ayrıştırılması uygulamaya aittir.
  • Önbelleğe alma kararı. Erişim sıklığı adayları karşılaştırmaya yardımcı olabilir; kabul ve yaşlandırma kuralları ayrıca tasarlanır.
  • Yoğun trafik adayları. Bilinen adayların trafiği toplamla karşılaştırılır; aday kimlikleri ayrı bir akıştan alınır.
  • Bölgesel sayımlar. Uyumlu bölge veya dönem özetleri birleştirilebilir; aynı olayın iki kez sayılmaması ayrıca yönetilir.
Top-K ile popülerlik10 örnek

Top-K sık görülen adayları yaklaşık izler. Zaman aralığı ve liste değişikliklerine bağlı işler uygulamada yönetilir; kesin sıralama garantisi yoktur.

  • Trend etiket ve içerikler. Belirli dönemde sık görülen etiket veya içerik adayları listelenebilir.
  • Popüler aramalar. Sık aranan terimler bulunabilir; sıklık kişisel ilgi veya anlamsal önem anlamına gelmez.
  • Popüler ürünler. Satış veya görüntülenme olayları ürün adaylarını sıralayabilir; kesin satış raporu ayrıca tutulur.
  • Yoğun ağ akışları. Paket sıklığına göre yoğun IP, port ve protokol akışları incelenebilir; veri aktarım maliyeti ölçülmelidir.
  • Bot ve saldırı incelemesi. Yoğun kaynaklar ayrıntılı incelemeye alınabilir; yüksek trafik tek başına saldırı kanıtı değildir.
  • Sıcak anahtarlar ve içerikler. Sık erişilen anahtarlar veya CDN içerikleri önbellek ve kapasite çalışmaları için aday olabilir; işlem ayrıca yürütülür.
  • Uç nokta ve müşteri yoğunluğu. Yoğun çağrı alan uç noktalar veya müşteri grupları belirlenebilir; çağrı sayısı işlem maliyeti değildir.
  • Yaygın hata imzaları. Sık görülen hatalar incelenebilir; seyrek ama kritik hatalar için ayrı alarmlar gerekir.
  • Aktivite ve oyun listeleri. Etkinlik sayısına dayalı listeler hazırlanabilir; kesin ödül ve skor kayıtları ayrıca tutulur.
  • Liste değişiklikleriyle iş başlatma. Aday listesi değiştiğinde vitrin veya inceleme kuyruğunu güncelleme mantığı uygulamada kurulur.
t-digest ile yüzdelikler10 örnek

t-digest yüzdelik ve dağılım sonuçları yaklaşık verir. Ölçüm dönemi, örneklem ve ayrı tutulması gereken olay kayıtları tasarımın parçasıdır.

  • API ve veritabanı gecikmeleri. p50, p95 ve p99 ile yanıt sürelerinin dağılımı incelenebilir; az gözlemde uç yüzdelikler dikkatle yorumlanır.
  • SLO eşikleri. Bir sürenin dağılımdaki yeri tahmin edilebilir; eşit değerlerin CDF hesabına etkisi ve kesin ihlal sayısı ayrıca değerlendirilir.
  • Kırpılmış ortalama. Seçilen yüzdelik aralığının ortalaması hesaplanabilir; dışlanan uç değerler ayrıca izlenmelidir.
  • Oyun skorlarının yüzdelikleri. Bir skorun geçmiş dağılımdaki konumu görülebilir; kesin oyuncu sırası ayrı tutulur.
  • Ağ trafiğinde olağandışı artış. Ölçümler geçmiş yüzdeliklerle karşılaştırılabilir; eşik aşımı tek başına saldırı kanıtı değildir.
  • IoT ve bakım. Sıcaklık veya akım gibi ölçümler olağan aralıklarla karşılaştırılarak incelemeye yönlendirilebilir.
  • Dağıtık ölçümlerin birleşimi. Uyumlu dağılım özetleri birleştirilir; ayrı p99 değerleri doğrudan ortalanmaz.
  • İşlem tutarları. Benzer işlem gruplarının tutar dağılımları karşılaştırılabilir; yüksek tutar tek başına risk kanıtı değildir.
  • Kuyruk ve teslimat süreleri. Bekleme ve tamamlanma süreleri özetlenebilir; iş kimlikleri ve olay sırası ayrıca tutulur.
  • A/B ve sürüm karşılaştırması. Ayrı grupların gecikme dağılımları incelenebilir; istatistiksel anlamlılık ayrıca değerlendirilir.
HyperLogLog ile tekil sayım12 örnek

HyperLogLog farklı öğelerin sayısını yaklaşık tahmin eder; kişileri listelemez veya tek tek üyelik sorgulamaz. Dönem özetleri toplanmak yerine birleştirilir.

  • Tekil ziyaretçiler. Bir dönemdeki farklı ziyaretçi kimlikleri yaklaşık sayılır; IP adresi her zaman tek bir kişiyi temsil etmez.
  • Video ve müzik erişimi. İçerik başına farklı izleyici veya dinleyici sayısı tahmin edilir; oynatma süresi ayrıca ölçülür.
  • Benzersiz arama sorguları. Normalleştirilmiş sorguların çeşitliliği izlenir; sorguların listesi ve sıklığı ayrı tutulur.
  • Taranan URL kapsamı. Dönem içinde kaç farklı adrese ulaşıldığı tahmin edilir; belirli bir URL’nin üyeliği sorgulanamaz.
  • Günlük, haftalık ve aylık kullanıcılar. Günlük özetler birleştirilerek dönemlik aktif kullanıcı tahmini yapılır; günlük sayılar toplanmaz.
  • Kampanya erişimi. Kanalların kullanıcı özetleri birleştirilebilir; ortak kimlik eşleştirmesi uygulamaya aittir.
  • Bölge ve servisler arası sayım. Farklı kaynaklardaki kimliklerin birleşim sayısı uyumlu özetlerden yaklaşık hesaplanabilir.
  • IP, hesap ve cihaz çeşitliliği. Bir IP’ye bağlı farklı hesap veya bir hesabın kullandığı farklı cihaz sayısı risk sinyali olabilir.
  • Etkin IoT cihazları. Dönemde veri gönderen cihazlar sayılabilir; hangi cihazın çevrimdışı olduğu ayrı kayıttan bulunur.
  • Müşteri ve ürün çeşitliliği. Farklı müşteri veya satılan ürün sayısı tahmin edilir; sipariş adedi ve ciro ayrı ölçülür.
  • Veri profilleme. Bir alandaki farklı değer sayısının değişimi izlenebilir; kesin benzersizlik kontrolü yerine geçmez.
  • Log ve metrik çeşitliliği. Hata veya etiket çeşitliliği izlenebilir; artışa yol açan değerler için ayrı kayıt gerekir.
Özel algoritma gerektiren desenler4 örnek

Bu desenlerde Bloom yalnızca bir bileşendir. Yönlendirme, hata düzeltme, graf işleme veya fark çözümleme için ayrı algoritmalar ve özel entegrasyon gerekir.

  • IP önekleriyle yönlendirme. Önek uzunlukları ayrı filtrelerle ön kontrolden geçirilebilir; en uzun eşleşme ve yönlendirme mantığı ayrıca geliştirilir.
  • Katmanlı engel listeleri. Sertifika veya eklenti listelerinde katmanlı filtreler tasarlanabilir; kapsam ve yanlış pozitif düzeltmesi ayrıca yönetilir.
  • Biyoinformatik grafı. Dizi parçaları filtrelerle özetlenebilir; grafı kurma ve yanlış dalları düzeltme algoritmaları ayrıca gerekir.
  • Dağıtık kümeleri eşitleme. Bloom ön elemesi bir fark çözümleme protokolüyle birleştirilebilir; filtre eksik öğeleri tek başına listelemez.