Redis ile Önbellekleme: Bahis Platformu Performansını Artırın

Redis, bahis platformlarında yalnızca bir önbellek değil, operasyonun kritik bir parçasıdır. Doğru kullanıldığında veritabanına giden okuma yükünü belirgin biçimde azaltır, yanıt sürelerini kısaltır ve yoğun maç anlarında sistemin nefes almasını sağlar. Yanlış kullanıldığında ise eski oranlar gösterir, tutarsız verilere yol açar ya da tek bir arızayla tüm sistemi etkiler. Bu yazıda bahis platformunda Redis'in nerede ve nasıl kullanılması gerektiğini ele alıyoruz.

Neler önbelleğe alınır?

• Maç öncesi oranlar: Görece seyrek değişir; kısa bir TTL ile önbellekte tutulabilir. Her kullanıcı isteğinde veritabanına gitmek yerine Redis'ten yanıt dönülür.
• Spor, lig ve takım kataloğu: Gün içinde nadiren değişir; daha uzun TTL uygundur.
• Oturumlar: Redis tabanlı oturum yönetimi, çıkış yapıldığında oturumun anında geçersiz kılınmasını ve çok cihazlı oturumların yönetimini kolaylaştırır.
• Hız sınırlama sayaçları: IP, kullanıcı ya da uç nokta bazında istek sayılarını tutmak için idealdir.
• Sık okunan kampanya ve bonus kuralları: Her kupon doğrulamasında veritabanına gitmeyi önler.

Bakiye gibi doğruluğu kritik veriler için Redis'i tek doğruluk kaynağı olarak kullanma. Önbellek, veritabanındaki gerçeğin hızlı bir kopyasıdır; çelişki durumunda veritabanı kazanmalıdır.

Önbellek desenleri

Cache-aside

1. Uygulama önce Redis'e bakar.
2. Veri varsa doğrudan döner.
3. Yoksa veritabanından okur, Redis'e TTL ile yazar ve döner.
4. Veri güncellendiğinde ilgili anahtar silinir ya da güncellenir.

Bu desen basittir ve okuma ağırlıklı verilerin çoğu için yeterlidir. Asıl zorluk, güncellemelerde önbelleğin zamanında geçersiz kılınmasıdır. Anahtar adlarını tutarlı bir şemayla (örneğin odds:prematch:etkinlik-kimliği) kurmak, geçersiz kılma işini kolaylaştırır.

Önbellek çığını önlemek

Popüler bir anahtarın süresi dolduğunda yüzlerce istek aynı anda veritabanına yönelebilir. Büyük maç öncesi bu durum veritabanını kilitleyebilir. Üç basit önlem işe yarar: TTL değerlerine küçük rastgele sapmalar eklemek, anahtarı yeniden doldurma işini tek bir isteğe bırakan kısa süreli bir kilit kullanmak ve süre dolmadan arka planda yenileme yapmak.

Hız sınırlama örneği

Redis'in INCR ve EXPIRE komutları, sabit pencereli basit bir hız sınırlayıcı için yeterlidir. Aşağıdaki örnekte her IP için 60 saniyelik pencerede giriş denemeleri sayılır; EXPIRE komutundaki NX seçeneği Redis 7 ve sonrasında süreyi yalnızca anahtarın henüz süresi yoksa ayarlar:

MULTI
INCR rl:login:203.0.113.7
EXPIRE rl:login:203.0.113.7 60 NX
EXEC

Uygulama, INCR'nin döndürdüğü değer belirlediğin sınırı aşarsa isteği 429 ile reddeder. Daha pürüzsüz bir davranış gerekiyorsa kayan pencere ya da token bucket algoritmalarını sıralı kümeler (sorted set) veya Lua betikleriyle uygulayabilirsin.

Canlı oranlar için Pub/Sub ve Streams

Canlı maç oranları saniyeler içinde değişebilir; bunları klasik önbellek mantığıyla yönetmek ya eski veri gösterir ya da veritabanını yorar. Daha iyi bir yaklaşım, oran sağlayıcısından gelen güncellemeleri Redis Pub/Sub ya da Redis Streams üzerinden yayınlamak ve WebSocket bağlantılarıyla istemcilere itmektir. Böylece istemciler sürekli sorgu yapmaz, güncelleme olduğunda haberdar edilir. Yalnızca anlık dağıtım gerekiyorsa Pub/Sub, kalıcılık ve kaldığı yerden okuma gerekiyorsa Streams uygundur.

Veri yapısı seçimi

• String: Basit değerler ve sayaçlar.
• Hash: Maç ya da kullanıcı profili gibi çok alanlı nesneler; tek bir alanı okumak ya da güncellemek kolaydır.
• Sorted set: Lider tabloları, zaman bazlı kuyruklar ve kayan pencereli hız sınırlama.
• List ve Stream: Son etkinlikler, aktivite akışları ve olay kuyrukları.

Yüksek erişilebilirlik

Tek bir Redis sunucusu çöktüğünde tüm okuma yükü aniden veritabanına biner. Redis Sentinel, birincil sunucuyu izleyen ve arıza durumunda bir replikayı otomatik olarak birincil yapan bir çözümdür; sağlıklı karar alabilmesi için en az üç Sentinel süreci önerilir. Veri hacmi tek sunucuya sığmıyorsa Redis Cluster ile veriyi birden fazla düğüme bölebilirsin. Her iki durumda da uygulamanın Redis'e ulaşamadığında kontrollü biçimde veritabanına düşmesi ve bunu yaparken veritabanını boğmaması gerekir.

Bellek yönetimi

# redis.conf
maxmemory 4gb
maxmemory-policy volatile-lru

maxmemory değerini açıkça belirlemezsen Redis sunucunun belleğini tüketebilir. volatile-lru yalnızca TTL tanımlı anahtarlar arasından en az kullanılanları siler; TTL'siz tutmak istediğin veriler korunur. Tüm anahtarlar önbellek niteliğindeyse allkeys-lru daha uygun olabilir.

Sık yapılan hatalar

• TTL'siz önbellek anahtarları: Süresi olmayan önbellek verisi zamanla belleği doldurur ve eski veri sunulmasına yol açar.
• KEYS komutunu canlı ortamda kullanmak: Tüm anahtar uzayını tarayan bu komut büyük veri setlerinde Redis'i bloke eder; bunun yerine SCAN kullan.
• Çok büyük değerler: Tek bir anahtarda megabaytlarca veri tutmak ağ ve bellek üzerinde gereksiz yük oluşturur; veriyi mantıklı parçalara böl.
• Önbelleği güvenlik sınırı sanmak: Redis'i internete açık bırakma, parola ya da ACL tanımla ve yalnızca uygulama sunucularının erişebileceği bir ağda çalıştır.

Değişikliklerin etkisini ölçmek

Önbellek değişiklikleri iç metriklerde iyi görünse de kullanıcının deneyimini ayrıca doğrulamalısın. Büyük bir değişiklikten sonra yük testi yap, veritabanı tarafındaki etkiyi PostgreSQL performans ipuçlarıyla birlikte değerlendir ve sitelerin dışarıdan ölçülen yanıt sürelerini izle. LLCBullet'te paketindeki altyapılara bağlı siteler için kurduğun site kontrolü görevleri her çalıştırmada yanıt sürelerini kaydeder; değişiklik öncesi ve sonrası karşılaştırma için pratik bir referans sağlar.

Sonuç

Redis, doğru desenlerle kullanıldığında bahis platformunun performansını ve dayanıklılığını belirgin şekilde artırır. Neyi önbelleğe aldığını bilinçli seç, TTL ve çığ önlemlerini planla, yüksek erişilebilirliği baştan kur ve etkisini hem içeriden hem dışarıdan ölç.