Dockup'ta Redis Cache ve Queue İş Yükleri

Redis cache ve queue iş yükleri aynı yönetilen Redis servisini kullanabilir, ancak doğruluk gereksinimleri farklıdır. Bir cache genellikle kaybolduktan sonra yeniden oluşturulabilir. Bir queue ise sessizce silinmemesi veya iki kez işlenmemesi gereken işleri temsil edebilir.

Dockup, Redis'i yönetilen bir veritabanı olarak oluşturur; boyut ve log işlemleri sunar, backup ve node migration iş akışlarını destekler ve veritabanını project-private networking üzerinden uygulama servislerine bağlayabilir.

Yönetilen Redis nasıl oluşturulur?

Seçili workspace'te Redis oluşturun:

dockup db create \
  --name app-redis \
  --type redis \
  --json

Veritabanı hedefini doğrulayın:

dockup db list --json

Dönen bağlantı bilgilerini source control dışında saklayın ve tüketici servise secret olarak ekleyin:

dockup env set REDIS_URL="$REDIS_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Redeploy işlemi, güncellenmiş environment ile yeni bir uygulama container'ı oluşturur. Eski container'ı yeniden başlatmak, yeni kaydedilmiş istenen değeri uygulamaz.

Cache eviction davranışı ile kritik queue retention davranışının aynı bellek için rekabet etmemesi gereken durumlarda ayrı Redis veritabanları veya instance'ları kullanın. İzolasyon, incident teşhisini ve access control işlemlerini de kolaylaştırır.

Redis ne zaman cache olarak kullanılmalıdır?

Cache, türetilmiş verileri saklayarak tekrarlanan işi veya gecikmeyi azaltır. Source of truth başka bir yerde kalır; bu genellikle PostgreSQL, MySQL, MongoDB, harici bir API veya deterministik bir hesaplamadır.

Sağlam bir cache tasarımı şunları tanımlar:

• Cache key formatı ve namespace.
• Time to live.
• Kabul edilebilir en yüksek stale olma süresi.
• Invalidation tetikleyicisi.
• Cache miss durumundaki davranış.
• Redis kullanılamadığında davranış.
• Thundering herd'a karşı koruma.
• Hangi verilerin asla cache'lenmemesi gerektiği.

Hata	Güvenli cache davranışı
Key bulunamıyor	Yeniden hesaplayın veya source of truth'tan okuyun
Redis kullanılamıyor	Rate protection uygulayarak source'a geçin
Stale entry	Süresi dolsun veya invalidate edin
Serialization değişikliği	Key namespace'i sürümlendirin
Bellek baskısı	Önce yeniden oluşturulabilir verileri evict edin
Hot key	Local cache, sharding veya request coalescing ekleyin

Yalnızca opsiyonel bir cache çalışmıyor diye tüm uygulamayı kullanılamaz hâle getirmeyin. Bounded timeout'lar ve fallback yolları kullanın. Öte yandan tüm hataları gizlemeyin; uzun süren bir cache kesintisi source veritabanına aşırı yük bindirebilir.

Redis job queue olarak kullanıldığında ne değişir?

Queue, bekleyen işleri temsil eder; bu nedenle uygulama delivery ve recovery semantiklerini tanımlamalıdır. Redis'in kendisi bir data structure server'dır; garantiler queue library'sine ve worker protokolüne bağlıdır.

Şunlara karar verin:

1. Bir job ne zaman kabul edilmiş sayılır?
2. Ne zaman acknowledge edilir?
3. Bir worker side effect'i gerçekleştirdikten sonra ancak acknowledge etmeden önce çökerse ne olur?
4. Retry'lar nasıl geciktirilir ve sınırlandırılır?
5. Kalıcı olarak başarısız olan işler nereye gider?
6. Duplicate execution nasıl güvenli hâle getirilir?
7. Queue depth nasıl gözlemlenir?
8. Job payload yeniden oluşturulabilir mi?

Idempotent worker'lar geliştirin. Bir payment capture, e-posta veya data import işlemi bir hatadan sonra birden fazla kez teslim edilebilir. Bir business idempotency key kullanın ve tamamlanma durumunu source-of-truth veritabanına kaydedin.

İş yüklerini ve öncelikleri queue adlarıyla ayırın. Yavaş bir media job'ı, password-reset veya webhook işlemlerinin önüne geçmemelidir. Bir reference ID yeterliyse job payload'larına secret koymaktan kaçının.

Bir Redis cache ve queue deployment'ı, hangi key'lerin atılabilir olduğunu ve hangilerinin iş süreçlerini temsil ettiğini belgelemelidir.

Private networking servisleri Redis'e nasıl bağlar?

Project networking'i etkinleştirin:

dockup network enable production --json

Redis servisine, aynı project içindeki servislerden kararlı <slug>.internal hostname'i üzerinden erişilebilir. Dockup'un internal connection variable'larını enjekte edebilmesi için uygulamayı yeniden deploy edin.

Redis'i yalnızca private erişime açmak için:

dockup db private production/app-redis --json

Gerektiğinde public listener'ı yeniden etkinleştirin:

dockup db private production/app-redis --off --json

Private networking, aynı project içi trafik için public internet yolunu kaldırır; ancak authentication'ın yerini almaz. Redis bağlantı bilgilerini secret olarak saklayın ve bunları hangi servislerin alacağını kısıtlayın.

Farklı project'ler birbirlerinin private network'üne erişemez. Bu sınır, production ve staging ortamlarının aynı cache key'lerini veya queue işlerini paylaşmaması gerektiğinde faydalı olabilir.

Tam model için private networking ve internal domain'ler sayfasına bakın.

Redis hataları uygulamayı nasıl etkilemelidir?

Recovery kodunu yazmadan önce iş yükünü sınıflandırın.

İş yükü	Veri kaybı toleransı	Kesinti yanıtı
HTML fragment cache	Yüksek	Source'tan yeniden oluşturun
Session store	Düşük - orta	Kullanıcıların oturumunu kapatabilir; fallback tasarlayın
Rate-limit sayaçları	Policy'ye bağlı	Fail open veya fail closed davranışını açıkça belirleyin
Job queue	Düşük	Yeni kabulü durdurun veya başka yerde persist edin
Distributed lock	Kritik bölümler için çok düşük	Fencing/idempotency kullanın
Feature cache	Yüksek	Default veya source kullanın

Bir cache client'ı sonsuza kadar retry etmemelidir. Uzun retry'lar tüm application worker'larını tüketerek bir Redis incident'ını tam kapsamlı bir kesintiye dönüştürebilir. Queue worker'ları back off etmeli, başarısız işleri görünür kılmalı ve tanımlanmış bir policy sonrasında durmalıdır.

Redis boyutunu ve tüketici uygulamanın runtime log'larını inceleyin:

dockup db size production/app-redis --json
dockup logs production/api --json

Boyut artışı; expiration eksikliğine, kontrolsüz queue depth'e, aşırı büyük payload'lara veya terk edilmiş namespace'lere işaret edebilir. Application timeout'larına verilen ilk yanıt olarak veritabanını restart etmeyin; önce configuration, networking ve client davranışını kontrol edin.

Backup, migration ve monitoring Redis kullanımına nasıl dahil olur?

Dockup, yönetilen veritabanı backup iş akışını sunar:

dockup db backups production/app-redis --json
dockup db backup production/app-redis --json

Bir Redis backup'ının iş yükünün recovery hedefini karşılayıp karşılamadığı, verinin ne anlama geldiğine bağlıdır. Bir cache backup'ı gereksiz olabilir. Bir queue backup'ı, backup noktasından sonra kabul edilen işleri yine de kaybedebilir. Kritik business job'ları için mümkün olduğunda queue dışında kurtarılabilir bir source record bulundurun.

Redis'i node'lar arasında şu komutla taşıyın:

dockup db migrate production/app-redis \
  --node <nodeId> \
  --json

Migration'ın client'lar ve worker'lar üzerindeki etkisini planlayın. Production'dan önce reconnection, retry ve idempotency davranışlarının çalıştığını doğrulayın.

Veritabanı boyutuna ek olarak application-level metric'leri izleyin:

• Cache hit ratio.
• Miss latency.
• Eviction'lar.
• Queue depth ve en eski job'ın yaşı.
• Job başarı, retry ve hata sayıları.
• Worker concurrency.
• Redis connection error'ları.
• Payload boyutu.

Dockup, plan bakiyesine göre CPU, RAM ve disk tüketimini dakika bazında ölçer. Önerilen Pro planı ayda $20 tutar ve $20 kullanım kredisi içerir; ancak kapasite kararlarını plan adı değil, iş yükü metric'leri yönlendirmelidir.

Güvenli bir Redis production checklist'i nedir?

Launch öncesinde şunları doğrulayın:

1. Kesin project/db hedefi.
2. Cache ve queue sorumlulukları belgelenmiş olmalı.
3. Connection URL maskelenmiş bir secret olmalı.
4. Private networking policy belirlenmiş olmalı.
5. Her cache için TTL veya açıkça tanımlanmış invalidation bulunmalı.
6. Queue worker'ları idempotent olmalı.
7. Retry ve dead-letter davranışı queue system tarafından tanımlanmış olmalı.
8. Size ve queue-depth alert'leri bulunmalı.
9. Backup'ın değeri ve sınırlamaları anlaşılmış olmalı.
10. Restart ve migration işlemleri approval gerektirmeli.

Cache ve queue ayrımı örneği

Küçük bir uygulama, risk düşük olduğunda tek bir Redis veritabanıyla başlayabilir; ancak açık key prefix'leri kullanmalıdır:

cache:user-profile:v2:<user-id>
cache:catalog:v5:<product-id>
queue:email:waiting
queue:email:active
lock:invoice:<invoice-id>

İş yükü büyüdükçe kritik queue state'ini agresif biçimde evict edilen cache state'inden ayırın. Bu, yalnızca bir isimlendirme tercihi değil, operasyonel bir sınırdır.

Başarılı bir Redis cache ve queue tasarımı, Redis hızlı, yavaş, boş veya kullanılamaz olduğunda uygulamanın davranışını öngörülebilir hâle getirir.

Relational source-of-truth işlemleri için managed PostgreSQL sayfasına bakın. Daha kapsamlı kapasite seçenekleri için database scaling strategies sayfasını inceleyin. Güncel veritabanı komutları için Dockup CLI reference sayfasını kullanın.

Key ve payload evolution'ı tanımlayın

Cache ve queue verileri tek bir application process'in ömründen daha uzun yaşayabilir. Blue-green cutover sırasında yeni bir release, önceki release'in yazdığı key'leri okuyabilir. Her iki sürümün birlikte çalışabilmesi için key namespace'lerini ve job payload'larını sürümlendirin.

Queue'lar için payload version ekleyin ve worker'ların hâlâ bekliyor olabilecek tüm sürümleri işleyebilmesini sağlayın. Bir deployment rollback'i eski kodu geri yüklerken yeni formatlı job'lar Redis'te kalabilir. Uyumluluk yoksa application rollback'i hataları artırabilir.

Resource pressure'ı bilinçli olarak test edin

Non-production ortamında eksik key'leri, yavaş Redis yanıtlarını, connection reset'lerini, queue backlog'unu, duplicate delivery'yi ve dolu ya da dolmaya yakın bellek durumunu test edin. Uygulamanın fail open, fail closed, retry veya başka bir dependency'yi aşırı yükleme davranışlarından hangisini sergilediğini gözlemleyin.

Bir Redis cache ve queue runbook'u retry denemeleri ve concurrency için limitler belirlemelidir. Sınırsız retry loop'ları tüm worker'ları tüketebilir ve recovery'yi asıl incident'tan daha zor hâle getirebilir.

Source-of-truth recovery yolunu koruyun

Kritik job'lar için, Redis kaybından sonra işi yeniden oluşturmak üzere primary database'de yeterli state saklayın. Queue, işlemenin hızlanmasını sağlamalıdır; bir müşteri işleminin gerçekleştiğine dair tek kayıt hâline gelmemelidir.

Doğrulanabilir bir deployment ile başlayın

Redis'i non-production bir project'te oluşturun, cache fallback'ini ve duplicate job delivery'yi test edin ve kritik işleri yönlendirmeden önce failure policy'yi açıkça belirleyin.

app.dockup.ai'da ücretsiz başlayın. Free plan aylık $0'dır, başlangıç kredisi olarak $10 içerir ve bir workspace, üç veritabanı ve üç deployment destekler.

SSS

Dockup managed Redis oluşturabilir mi?

Evet. Type olarak redis belirterek managed database create komutunu kullanın; ardından dönen connection material'ını secret olarak saklayıp uygulamayı bağlayın.

Cache ve queue verileri aynı Redis instance'ını paylaşmalı mı?

Küçük ve düşük riskli bir iş yükünde paylaşabilirler; ancak cache eviction ile kritik queue retention'ın availability ve bellek gereksinimleri farklı olduğunda ayırmak daha güvenlidir.

Redis, sıraya alınan bir job'ın tam olarak bir kez çalışacağını garanti eder mi?

Hayır, genel bir exactly-once garantisi varsayılmamalıdır. Delivery semantikleri queue library'sine ve worker tasarımına bağlıdır; bu nedenle side effect'leri idempotent hâle getirin.

Redis, Dockup private networking'i kullanabilir mi?

Evet. Project network'ünü etkinleştirin, consuming service'leri internal variable'lar için yeniden deploy edin ve isteğe bağlı olarak Redis veritabanını yalnızca private erişime açın.

Kritik bir job queue için Redis backup'ı yeterli midir?

Her zaman değil. Backup belirli bir zaman noktasını temsil eder ve daha sonra kabul edilen yeni işleri içermeyebilir. Kurtarılabilir source record'ları saklayın ve application-level job recovery tanımlayın.