NovaLst 1
NovaLst
bikral 1
bikral
ShadowFon 1
ShadowFon
D 1
delimuratt
PrimeAC 1
PrimeAC
noisiv 1
noisiv
Manwe Work 1
Manwe Work
Best Studio 1
Best Studio
Hikaye Ekle
Reklam vermek için turkmmo@gmail.com
Kaynak ikonu

QF yerine Redis kullanmak 2025-07-07

indirmek için izniniz yok
  • Konuyu başlatan Konuyu başlatan mistikaptal
  • Başlangıç tarihi Başlangıç tarihi
  • Cevaplar Cevaplar 13
  • Görüntüleme Görüntüleme 1K
5.00 yıldız(lar) 2 Değerlendirme Değerlendirenler

ROHAN2 WORLD 1-120 TR TİPİ OFFICIAL YOHARA, BALATHOR VE AMON! 80. GÜNÜNDE! +10.000 ONLİNE! HİLE VE BOT %100 ENGELLİ HEMEN TIKLA!

Konunun neden oluştuğunu düşünürsek db iletişimini düşürmek yada modüler bir yapı ihtiyacı olabilir gördüğüm kadarıyla ama gereklilik konusu şüpheli belki quest, affect tablolarında kullanılabilir tek olasılık o, sql üzerinden çalışıyor ve cache yazılmamışsa gerekliliği var c++ üzerinde yazılmış bir kod yada cache daha yüksek performans verecektir.

Bu yüzden redis kullanım gerekliliğini tam açıklamak gerekli konunun eksiği bu şu an, sadece quest flag ve veritabanı olmaz bunlar için tamamen gereksiz. Sıfırdan farklı bir oyun geliştiriliyor ise o zaman evet gerek duyulur.

quest flag'den çok db konusunda gerekli bir olay aslında. duruma göre onlarca ayrı game(ch ve alt corelar) tek bir single thread db uygulamasına aktarmak yerine cache kısmını redis'e, db uygulamasıda redis verilerini sql motoruna aktarırsa tam olarak amacını karşılamış olur
 
quest flag'den çok db konusunda gerekli bir olay aslında. duruma göre onlarca ayrı game(ch ve alt corelar) tek bir single thread db uygulamasına aktarmak yerine cache kısmını redis'e, db uygulamasıda redis verilerini sql motoruna aktarırsa tam olarak amacını karşılamış olur

Evet haklısın böyle olursa iyi olur. Game db yerine komple Redis(KeyDB) gibi bir yapı üzerinden geçerse o durumda çok daha hızlı çalışır sabit tablolar ve küçük veriler ile. İtem tablosu redise bağlanmadığı sürece daha iyi büyük veriler redis için biraz sıkıntı hepsini anlık çekmek oyuncu sayısını göre normalden daha yavaş örnek bakım sonrası otomatik girişle oluşan istek sayısı çok büyük ve bu anlık işleme göre katlanıyor. Ham performans ve verimlilik için benim tercihim db yi baştan yazmak daha avantajlı uzun vadeli işlemlerde daha iyi. İtem gibi toplu büyük verilerde db kullanılır ise gerisinde Redis(KeyDB) kullanır gayet iyi bir performans sağlar diye düşünüyorum. Büyük verilerde şuanki mevcut socket yapısı daha hızlı ve verimli sadece db nin çoklu çekirdeğe ihtiyacı var ve paket önceliklendirme sistemine.
 
Eline sağlık mistik başarılı konu olmuş
 
Eline sağlık, uygulama için teşekkürler! Ancak bu yaklaşımın performans açısından beklenen avantajları tam olarak sağladığını düşünmüyorum. Yanlış hatırlamıyorsam, setflag zaten bellekte map yapısıyla tutuluyor ve hızlı erişim sağlıyor. Redis’e geçmek, yalnızca game proccessler arasında senkronizasyon sağlayacaktır. Eğer hedef buysa, bu mantıklı bir seçim olabilir, ancak çoğu durumda network üzerinden Redis’e erişim, yerel bellek kullanımına kıyasla ek yük getirebilir.Bence daha verimli bir yaklaşım, Redis’i game'e entegre etmek yerine db'ye önbellek olarak kullanmak olurdu. Örneğin, sık sorgulanan verileri Redis’te tutarak MySQL’e olan yükü azaltabiliriz. Redis’in kendi persistence özelliklerinden (RDB veya AOF) faydalanmak veri kaybını önlemek için daha pratik olabilir. Bu sayede hem performans artar hem de veri tutarlılığı sağlanır.

Redis ile mesela anlık güncellenen oyun içi sıralama yapılabilir. Veritabanına giden doğruluğu hayati öneme sahip olmayan şeyler de tutulabilir. Bunlar da farklı uygulama önerilerim.
 
Son düzenleme:
İleriye dönük bir konu anlatımı olmuş ellerine sağlık. Dediğin gibi Redis kullanımı daha rahat ve daha stabil veri aktarımı sağlar anca deneyen varmı hiç denendimi bununla ilgili konuşmak lazım…
 

Şu an konuyu görüntüleyenler (Toplam : 0, Üye: 0, Misafir: 0)

Geri
Üst