İLERİ
Sentinel vs Cluster: Farkı Anla, Doğru Seç
Redis 8 ve .NET 10 ile caching, veri yapıları, messaging, ölçekleme, dayanıklılık ve production operasyonları.
En sık karıştırılan Redis kavramı. İkisi de "yüksek erişilebilirlik" sağlar ama tamamen farklı problemleri çözer. Yanlış seçim: ya gereksiz karmaşıklık ya da ölçeklenememe.
Ne Zaman Hangisi?
| Senaryo | Sentinel | Cluster | Neden |
|---|---|---|---|
| Veri <32GB, HA istiyorum | Gereksiz karmaşıklık, Sentinel yeterli | ||
| Veri >64GB (tek node'a sığmıyor) | Veriyi dağıtman gerekiyor | ||
| >100K ops/s write throughput | Tek master write bottleneck | ||
| MGET, TRANSACTION, Lua multi-key | Cluster'da hash tag zorunlu, kısıtlı | ||
| Basit mimari, az ops overhead | Cluster yönetimi daha karmaşık | ||
| AWS ElastiCache / Azure Cache managed | ya da | Managed service'te her ikisi de kolay | |
| Mevcut uygulama multi-DB (SELECT 1,2..) | Cluster'da SELECT yasak |
Gerçek hayat kararı: Çoğu startup ve orta ölçek SaaS için Sentinel yeterli. 64GB RAM'lik bir Redis server milyarlarca küçük key barındırabilir. Cluster'a geçiş: veri RAM'e sığmadığında veya write throughput tek master'ı doyurduğunda düşün. Erken optimize etme — Sentinel ile başla, ölç, gerekirse Cluster'a geç.
Hibrit kullanım: Cluster mode'da her master node'un zaten replica'ları var (built-in HA). Yani Cluster = Sentinel + Sharding. Cluster seçersen ayrıca Sentinel kurmanıza gerek yok — Cluster kendi failover'ını yönetir.