EMZETT.
Giriş yap

Upstash Redis

Kısaca: Bir “sunucusuz Redis” sağlayıcısı — hızlı, kısa ömürlü veriler için (örneğin oturumlar, hız sınırlama sayaçları) bir bellek içi veri tabanı; klasik bir Redis bağlantısı yerine REST API üzerinden erişilir.

Biraz daha ayrıntılı: Erişim, panelde kalıcı olarak görülebilen bir REST URL’si + belirteç (UPSTASH_REDIS_REST_URL/_TOKEN) üzerinden yürür. Bağlantı eksikse birçok uygulama bir geri dönüş kipine düşer; bu çoğu zaman ani yavaşlık olarak görünür.

Bizim bağlamımız: Emzett’te diğer şeylerin yanı sıra küresel hız sınırlama için kullanılır — taşımadan sonra Redis bağlantısı eksik olduğunda bu, fark edilir derecede yavaş sayfalara yol açtı (her istek başarısız biçimde bağlanmaya çalıştı).

Ayrıntılı

Klasik Redis genellikle uzun süre çalışan bir sunucu sürecinde tutulan kalıcı açık bir TCP bağlantısı olarak çalışır. Sunucusuz ortamlar (örneğin Vercel Functions) ise sürekli işlev örnekleri başlatıp durdurur — kalıcı bir TCP bağlantısı bu modele uymaz ve her yeni örnek önce yeniden pahalı bir bağlantı kurmak zorunda kalırdı. Upstash bunu, Redis komutlarını sıradan HTTP istekleriyle (özel bir ikili protokol yerine gövdede komutla GET/POST) kabul ederek çözer — bu da onu bağlantı havuzu sorunları olmadan tam olarak “kısa ömürlü işlev çağrıları” modeline oturtur.

Böyle bir bellek içi veri tabanının tipik kullanımları, hızlıca erişilebilir olması gereken ama ana veri tabanına (PostgreSQL/Neon) kalıcı olarak girmesi gerekmeyen verilerdir: oturum durumu, hız sınırlama sayaçları, kısa ömürlü önbellekler veya özellik bayrağı değerleri (bkz. Özellik bayrakları). Normal bir veri tabanından önemli bir fark: Redis değerlerine bir TTL (time to live) verilebilir — kendi temizlik işin olmadan bir süre sonunda otomatik olarak kaybolurlar.

await redis.set(`ratelimit:${ip}`, count, { ex: 60 }) // 60 sn sonra otomatik sona erer

Salt anahtar-değerden fazlası

Basit dizgi değerlerinin ötesinde Redis (dolayısıyla Upstash), belirli görevler için klasik ilişkisel bir veri tabanında yeniden kurmaktan çok daha verimli özel veri yapıları sunar: sıralı kümeler (ZADD/ZRANGE) örneğin skor tabloları için idealdir (değerler skora göre otomatik sıralanır), basit kuyruklar için listeler (LPUSH/RPOP) ve her alan için ayrı bir Redis anahtarına ihtiyaç duymadan tek bir anahtar altında yapılandırılmış nesneler için hash’ler.

Kayan pencere ve sabit pencere hız sınırlama

Hız sınırlama için (yukarıdaki örnekte olduğu gibi) iki yaygın strateji vardır: sabit pencere istekleri sabit zaman pencereleri içinde sayar (örneğin “0-60 sn”, “60-120 sn”) — uygulaması basit, ancak pencere sınırlarında bir zayıflığı vardır (bir kullanıcı bir sınırdan hemen önce VE hemen sonra tam limiti kullanarak kısa sürede amaçlanandan iki kat fazla isteği geçirebilir). Kayan pencere ise sabit sınırlardan bağımsız olarak her zaman geçerli ana göre son N saniyeye bakar — daha doğru, ama uygulaması biraz daha karmaşık. @upstash/ratelimit gibi hazır kütüphaneler iki stratejiyi de doğrudan sunar; kendin yeniden kurmak zorunda kalmazsın.

Ayrıca bak: Hız sınırlama, TTL, Neon