İçeriğe geç
Her adımda yanınızdayız 7/24 destekdestek@mezuhost.com
Mezuhost — 11. yılında
Rehber · MEZUHOST BİLGİ MERKEZİ

Metin2 Sunucusunda Çevrimdışı Pazar: Eşya ve Yang Kaybını Önlemek İçin Nelere Dikkat Edilmeli?

Metin2 çevrimdışı pazar sisteminde satış, bağlantı kopması ve yeniden başlatma senaryolarını inceleyin; eşya ve Yang tutarlılığı için test planı oluşturun.

Mezuhost03.11.20264 dk okuma

Metin2 çevrimdışı pazar sistemi, oyuncu bağlı değilken de satış işlemlerinin doğru tamamlanmasını gerektirir. Bir eşyanın alıcıya geçmesi, satıcının gelirinin kaydedilmesi ve pazar ilanının kapanması birbiriyle ilişkili adımlardır. Bu adımların yalnızca bir kısmı tamamlanırsa oyuncu ekranında görülen sonuç ile sunucudaki kayıtlar birbirinden ayrılabilir.

Bu rehber belirli bir files paketine hazır kod sunmaz. Çevrimdışı pazar uygulamaları farklı olduğu için geliştiricinizle birlikte değerlendirebileceğiniz işlem kurallarını ve test senaryolarını anlatır. Amaç, genel yedekleme konusundan ayrı olarak satış anındaki veri tutarlılığına odaklanmaktır.

Bir satışta hangi kayıtların birlikte değiştiğini belirleyin

Önce kendi sisteminizde satışın nasıl gerçekleştiğini çıkarın. Eşya hangi kayıtta tutuluyor? Satıcının kazancı doğrudan bakiyeye mi, ayrı bir tahsilat alanına mı yazılıyor? Alıcının envanteri doluysa işlem reddediliyor mu, yoksa teslimat kuyruğuna mı alınıyor? Pazar kapanırken satılmamış eşyaların nasıl geri verildiği de aynı tasarımın parçasıdır.

Sağlam bir işlem kuralı şudur: Başarılı satışta ödeme ve teslimat birbiriyle uyumlu olmalı; başarısız satışta ise yarım kalan değişiklikler kontrolsüz biçimde bırakılmamalıdır. Ancak tüm adımlar farklı süreçlerde veya farklı depolarda yürütülüyorsa tek bir veritabanı işlemi her şeyi kapsamayabilir.

Veritabanı işlemi faydalıdır, tek başına bütün çözüm değildir

İlgili tablolar işlem desteği sunan bir motor kullanıyorsa, birbiriyle bağlı veritabanı değişiklikleri aynı transaction içinde ele alınabilir. Başarı durumunda commit, başarısızlıkta rollback yaklaşımı değerlendirilir. İşlem desteklemeyen tabloları kullanan eski bir yapıda aynı güvenceyi varsaymayın; önce mevcut motorları ve kod akışını inceleyin.

Aynı ilana iki alıcının eş zamanlı erişmesi ayrıca ele alınmalıdır. Kilitleme veya koşullu güncelleme gibi yöntemler, yalnızca geçerli durumdaki ilanın satılabilmesini sağlayacak şekilde tasarlanır. Veritabanı kilitleri, oyun sürecindeki eski envanter bilgisini kendiliğinden düzeltmez. Kalıcı kayıtlar ile bellekteki durumun nasıl eşleştirileceği de belirlenmelidir. Temel kavramlar için MySQL InnoDB işlem modeli incelenebilir.

Bağlantı kopunca aynı satın alma tekrar gönderilebilir

Oyuncu satın alma düğmesine bastıktan sonra yanıt gelmeyebilir. Bu, satışın kesinlikle başarısız olduğu anlamına gelmez; kayıt tamamlanmış ancak yanıt oyuncuya ulaşmamış olabilir. Tekrar denenen isteğin yeni bir satış gibi işlenmesi, mükerrer tahsilat veya teslimat riski oluşturur.

Bu nedenle sistemin aynı işleme ait tekrarları tanıması gerekir. İşlem kimliği, kalıcı sonuç kaydı ve aynı isteğe aynı sonucun döndürülmesi bu yaklaşımın parçalarıdır. Kimliği yalnızca istemcinin verdiği bir değere güvenerek kullanmak yeterli değildir; kullanıcı, ilan, tutar ve işlem yetkisi sunucu tarafında doğrulanmalıdır.

Test ortamında uygulanacak beş senaryo

  1. Eş zamanlı satın alma: İki test hesabı aynı tekil ilanı almaya çalışsın. Eşyanın yalnızca bir alıcıya geçtiğini ve diğer hesabın bakiyesinin doğru kaldığını kontrol edin.
  2. Yanıt kaybı: Satış tamamlandıktan sonra yanıtın ulaşmadığı durumu kontrollü biçimde oluşturun. Tekrar denemede ikinci tahsilat oluşmadığını doğrulayın.
  3. Dolu envanter: Alıcıda yer olmadığında belgelenmiş davranışın uygulandığını kontrol edin. Para düşüp teslimatın belirsiz kalmaması gerekir.
  4. Pazarın kapanması: Satın alma ile pazar kapatma aynı zamana denk geldiğinde eşyanın hem alıcıya hem satıcıya verilmediğini doğrulayın.
  5. Yeniden başlatma: İşlem akışının farklı noktalarında test sürecini durdurup başlatın. Bekleyen kayıtların yeniden ele alınabildiğini kontrol edin.

Bu denemeleri gerçek oyuncu bakiyelerinde yapmayın. Ayrı bir Metin2 test sunucusu kullanın ve test hesaplarının başlangıç bakiyelerini kaydedin. Her senaryonun sonunda yalnızca ekrana değil, kalıcı kayıtlara ve yeniden giriş sonrası duruma da bakın.

İtiraz geldiğinde hangi kanıtlar gerekli?

İşlem kimliği, ilan kimliği, eşyanın tekil kimliği, alıcı ve satıcı hesap referansları, tutar, saat ve sonuç durumu birlikte tutulmalıdır. Loglara parola veya gereksiz kişisel bilgi yazılmamalıdır. Kayıtların saklama süresi ve erişim yetkileri de belirli olmalıdır.

“Yang kayboldu” bildirimi geldiğinde doğrudan elle bakiye eklemek yerine önce ilgili işlem izlenmelidir. Aksi halde başarılı fakat geç görünen bir satışa ikinci kez ödeme yapılabilir. Düzeltme gerekiyorsa işlemin nedeni ve yetkili kişi kayıt altına alınmalıdır.

Sunucu altyapısının rolü nedir?

Yeterli kaynak, sağlıklı depolama ve izleme, pazar işlemlerinin istikrarlı çalışmasına yardımcı olur. Ancak daha fazla RAM almak yazılımdaki mükerrer işlem hatasını çözmez. Metin2 sunucu planlamasında altyapı ile uygulama kontrollerini birlikte değerlendirin. Yedekleme kurtarma planının bir parçasıdır; satış akışının doğruluğunun yerine geçmez.

Sık sorulanlar

Çevrimdışı pazar mutlaka veri kaybına yol açar mı?

Hayır. Belirleyici olan sistemin nasıl geliştirildiği, hataların nasıl ele alındığı ve hangi senaryolarla test edildiğidir.

Bütün veritabanını geri almak doğru çözüm müdür?

Tek bir satış sorunu için bütün veritabanını geri almak, diğer oyuncuların geçerli ilerlemesini de kaybettirebilir. Müdahale kapsamı kayıtlar incelendikten sonra belirlenmelidir.

OKUMAYA DEVAM EDİN

İlginizi çekebilecek rehberler

SATIŞ VE TEKNİK DESTEK

Hizmetlerimiz hakkında bilgi alın

Hosting, sunucu veya taşıma konusunda bize danışın.

Mezuhost ile iletişime geçin
Mezuhost destek ekibi için hazırlanmış üç boyutlu illüstrasyon

Altyapımızda kullandığımız teknolojiler

  • Juniper Networks
  • Dell
  • MikroTik
  • Arbor Networks
  • StormWall
  • Cloudflare