A look at how Tencent Games built service architecture based on CQRS and event sourcing patterns with Pulsar and ScyllaDB. Tencent Interactive Entertainment Group Global (IEG Global) bir parçası olarak, Proxima Beta, takımlarımızı ve stüdyolarımızı dünyanın dört bir yanındaki milyonlarca oyuncuya benzersiz ve heyecan verici oyunlar sunmak için desteklemeye kararlıdır. Level Infinite (dünyalı yayıncılık markası) ekibimiz, işimiz için çeşitli risklerin yönetilmesinden sorumludur – örneğin dolandırıcılık faaliyetleri ve zararlı içerikler. bu ilanı beğen Ağu 21 I'll be able to use this software for the first time. ( ) ve olay kaynak modelleri ile ScyllaDB ve ScyllaDB. Son olarak, çok sayıda oyun oturumuna olayları gönderme sorunu çözmek için ScyllaDB'yi nasıl kullandığımızı inceleyeceğiz. KPSS Apache Pulsar Hakkında Kullanım Olayı: Tencent Oyunlarında Risklerin Çözülmesi Ne ile çalıştığımızın ve karşılaştığımız zorlukların gerçek bir örneğiyle başlayalım. Bu, bir 3D eylem rol oynama oyunu olan Tower of Fantasy'den bir ekran görüntüsü. Oyuncular, farklı nedenlerle başka bir oyuncuya karşı bir rapor göndermek için bu diyalogu kullanabilirler. Tipik bir CRUD sistemi kullanırsanız, bu kayıtları takip etmek için nasıl saklarsınız? İlk zorluk, bu formu depolamak için hangi ekibin veritabanına sahip olacağını belirlemek olacaktır. bir rapor oluşturmak için farklı nedenler vardır (Öteki adı verilen bir seçenek de dahil olmak üzere), böylece bir durum farklı işlevsel ekipler tarafından ele alınabilir. Bu nedenle, bu olayı bir olay olarak yakalamak, örneğin “bir olayı bildirmek” gibi doğal bir seçimdir. Tüm bilgiler bu olaya benzer şekilde yakalanır. Tüm fonksiyonel ekiplerin sadece bu olaya abone olması ve kendi filtreleme yapmaları gerekir. eğer durumun kendi alanlarına düştüğünü düşünürlerse, sadece onu yakalayabilir ve daha fazla eyleme neden olabilirler. CQRS ve Event Sourcing Bu örneğin arkasındaki hizmet mimarisi, CQRS ve olay kaynak şekillerine dayanmaktadır. Bu terimler sizin için yeni ise, endişelenmeyin! Bu genel bakışın sonunda, bu kavramların sağlam bir anlayışına sahip olmalısınız. . Bu konuya adanmış blog Burada anlamanın ilk kavramı olay kaynaklarıdır. olay kaynaklarının arkasındaki temel fikir, bir sistem durumuna yapılan her değişiklikin bir olay nesnesinde yakalanması ve bu olay nesnelerinin sistem durumuna uygulandıkları sırada depolanmasıdır. Diğer bir deyişle, sadece mevcut durumunu depolamak yerine, bu duruma alınan tüm eylemlerin dizisini kaydetmek için bir eklenti depolaması kullanıyoruz. Bir sonraki kavram CQRS, Command Query Sorumluluk Ayrımcılığı anlamına gelir. CQRS, on yıldan fazla bir zaman önce Greg Young tarafından icat edilmiş ve Command ve Query Ayrımcılığı Prensibinden kaynaklanmıştır. Temel fikri, her iki amaç için de aynı modeli kullanmak yerine, aynı modelin okunması ve yazılması için ayrı veri modellerini oluşturmaktır. CQRS şablonuna uymakla, her API, bir eylemi gerçekleştiren bir komut ya da çağrıcıya verileri geri veren bir sorgu olmalıdır - ancak her ikisi de değildir. Bu, doğal olarak sistemin iki bölümüne bölünür: yazma tarafı ve okunma tarafı. Bu ayrılık birkaç avantaj sunar. örneğin, maliyet verimliliğini optimize etmek için yazma ve okuma kapasitesini bağımsız olarak ölçebiliriz. Takım çalışması açısından farklı ekipler aynı verilerin farklı görünümlerini daha az çatışma ile oluşturabilir. Yazma tarafındaki yüksek düzeyde iş akışı şu şekilde özetlenebilir: Çok sayıda oyun oturumlarında meydana gelen olaylar sınırlı sayıda olay işlemcisine aktarılır. Uygulama aynı zamanda basittir, tipik olarak Pulsar, Kafka gibi bir mesaj otobüsü veya bir olay mağazası olarak hareket eden daha basit bir sırt sistemi içerir. Müşterilerin olayları olay mağazasında temaya göre devam eder ve olay işlemcileri olayları temaya abone ederek tüketir. Eğer neden Apache Pulsar'ı diğer sistemlere göre seçtiğimizi merak ediyorsanız, daha fazla bilgi bulabilirsiniz . Önceki YazıSonraki Blog Sırt gibi sistemler genellikle tek yönde dolaşan trafiği (örneğin fan-in) yönetmek için verimli olsa da, ters yönde dolaşan trafiği (örneğin fan-out) yönetmek için verimli olmayabilirler. Sıralamamızda, oyun oturumlarının sayısı büyük olacak ve tipik bir sır sisteminin iyi uyumlu olmayacağından, her oyun oturumunda özel bir sır oluşturmak zorunda değiliz. Sonuçları ve ölçütleri Query API'leri aracılığıyla bireysel oyun oturumlarına dağıtmanın pratik bir yolunu bulmalıyız. Bu nedenle, olay fan-out için optimize edilmiş bir başka sır gibi bir etkinlik mağazası oluşturmak için ScyllaDB'yi kullanıyoruz. Devam etmeden önce, burada hizmet mimarlığımızın bir özetidir. Yazma tarafından başlayarak, oyun sunucuları Komut Sonuçları aracılığıyla sistemimize olayları göndermeye devam eder ve her olay bir oyun oturumunda meydana gelen belirli bir tür aktiviteyi temsil eder. Olay işlemciler, her oyun oturumunun olay akışlarına karşı bulgular veya metrikler üretir ve iki taraf arasında bir köprü olarak hareket eder. Okuma tarafında, oyun sunucularına veya diğer istemcilere sahibiz. Zaman serisi etkinlikleri için dağıtılmış Queue-Like Event Store Şimdi, ScyllaDB'yi çok sayıda oyun oturumuna etkinlik gönderme sorunu çözmek için nasıl kullandığımızı inceleyelim. Aksi takdirde, Google "Cassandra" ve "çizgi" ile karşılaşırsanız, Cassandra'yı bir sıra olarak kullanmanın bir anti-pattern olduğunu belirten on yıldan fazla bir zamana ait bir makale ile karşılaşabilirsiniz. Bu o zamanlarda doğru olabilse de, bugün sadece kısmen doğru olduğunu iddia edeceğim. Her bir oyun oturumuna olayların gönderilmesini desteklemek için, her bir oyun oturumunun kendi bölümü vardır ve belirli bir oyun oturumuna ait olayların oturum id tarafından etkin bir şekilde bulunabilmesi için bölüm anahtarı olarak oturum kimliğini kullanırız. Her olay aynı zamanda grubu anahtarı olarak bir zaman UUID olan benzersiz bir olay kimliğine sahiptir. Aynı bölüme ait kayıtlar grubu anahtarı tarafından sıralandığından, olay kimliği bir sırada konum kimliği olarak kullanılabilir. Son olarak, ScyllaDB müşterileri en son alınan olayın olay kimliğini izleyerek yeni gelen olayları verimli bir şekilde alabilir. Bu yaklaşımı kullanırken göz önünde bulundurmanız gereken bir uyarı var: tutarlılık sorunu. En son olay kimliğini izleyerek yeni olayları bulmak, gelecekte daha küçük bir olayın gerçekleşmeyeceği varsayımına dayanır. Ancak, bu varsayım her zaman doğru olmayabilir. Örneğin, iki düğüm aynı anda iki olay kimliğini oluşturursa, daha küçük bir olay kimliğine sahip bir olay daha sonra eklenebilir. “Fantom okuma” olarak adlandırdığım bu sorun, aynı soruyu tekrarlamak, başka bir işlem tarafından yapılan taahhüt edilmemiş değişiklikler nedeniyle farklı sonuçlar verebileceği SQL dünyasında meydana gelen fenomenle benzerdir. Bu sorunu çözmenin birkaç yolu vardır.Bir çözüm, tüm olay işlemcileri arasında hareketli zaman çizelgelerinin en küçük değerine dayanan bir "pseudo şimdi" olarak adlandırdığım bir kümelendirme statüsünü sürdürmektir.Her olay işlemcileri aynı zamanda tüm gelecekteki olayların mevcut zaman çizelgelerinden daha büyük bir olay kimliğine sahip olmasını sağlamalıdır. Başka bir önemli düşünce, TimeWindowCompactionStrategy'nin, mezar taşlarının neden olduğu olumsuz performans etkilerini ortadan kaldırmasıdır. mezar taşlarının birikimi, TimeWindowCompactionStrategy'nin kullanılmadan önce Cassandra'nın bir sıra olarak kullanılmasını engelleyen önemli bir sorundur. Şimdi, ScyllaDB'yi bir gönderme sırası olarak kullanmanın ötesinde diğer avantajları tartışmaya geçelim. Küresel veri dağıtımının karmaşık zorluklarını kolaylaştırmak Dünyanın dört bir yanındaki müşterilere hizmet vermek için çoklu kiralık bir sistem kurduğumuzdan, farklı bölgelerdeki gruplar arasında müşteri yapılandırmalarının tutarlı olmasını sağlamak önemlidir. Bu sorunu, tüm veri merkezlerinde anahtar alanında veri kopyalamasını basitçe etkinleştirerek çözdük.Bu, bir veri merkezinde yapılan herhangi bir değişiklikin sonunda diğerlerine yayılması anlamına gelir. ScyllaDB'ye, DynamoDB'ye ve Cassandra'ya, bu zorlu sorunu küçük görünen ağır kaldırma için teşekkür ederiz. Herhangi bir tipik RDBMS kullanarak aynı sonucu elde edebileceğinizi düşünebilirsiniz, çünkü çoğu veritabanı da veri kopyalamayı desteklemektedir. Bu, belirli bir bölgede çalıştırılan kontrol panelinin yalnızca bir örneği varsa doğrudur. Tipik bir ana/replika mimarisinde, yalnızca ana düğme okuma/yazma desteklemektedir, ancak replika düğmeleri sadece okuma içerir. Bununla birlikte, farklı bölgelerde kontrol panelinin birden fazla örneğini çalıştırmanız gerektiğinde – örneğin, her kiracının ev bölgesinde çalıştırılan bir kontrol paneline sahip olması veya hatta her bölgede yerel ekipler için çalıştırılan bir kontrol paneline sahip olması – bu tipik bir ana/replika mimarisini kullanarak uygulanması çok daha zordur. AWS DynamoDB'yi kullandıysanız, uygulamaların yerel olarak okumalarını ve yazmalarını ve verileri küresel olarak erişmesini sağlayan Global Tablo olarak adlandırılan bir özelliğe aşina olabilirsiniz. ScyllaDB ile anahtar alanlarında kopyalamayı etkinleştirmek benzer bir özellik sunar, ancak tedarikçi kilidi olmadan. Anahtar alanlar veri konteynerleri olarak Daha sonra, küresel veri dağıtımının şeffaflığını artırmak için anahtar alanları veri konteynerleri olarak nasıl kullandığımızı inceleyelim. Aşağıdaki tabloya bir göz atalım.Bilgi koruma kanunları tarafından zorunlu olan tipik bir veri dağıtım sorunu için bir çözüm sunar.Örneğin, bölge A, orijinal bir kopyayı kendi bölgesi içinde sakladığınız sürece sınırları dışındaki belirli tür verilerin işlenmesine izin verir.Bir ürün sahibi olarak, tüm uygulamalarınızın bu düzenlemeye uymalarını nasıl sağlayabilirsiniz? * İÇİN * İÇİN Bu yaklaşım, uygulama geliştiricilerinin verileri doğru şekilde dağıtmak için tam sorumluluğu üstlenmeleri gerektirir. Ancak, uygulamaların sayısı arttıkça, her uygulamanın bu sorunu bireysel olarak ele almak pratik olmayacak ve E2E testleri hem zaman hem de para açısından giderek daha pahalı hale gelecektir. Anahtar alanlarda veri kopyalamasını etkinleştirerek, verileri doğru şekilde dağıtma sorumluluğunu iki göreve bölebiliriz: 1) veri türlerini tanımlamak ve hedefleri ilan etmek ve 2) verileri kopyalama veya beklenen konumlara taşıma. Bu iki görevi ayırarak, uygulamalardan karmaşık yapılandırmalar ve düzenlemeler çıkarabiliriz.Bu, verileri başka bir bölgeye aktarma süreci genellikle ağ sınırlarını geçmek, trafiği doğru bir şekilde şifrelemek ve kesintilerle başa çıkmak gibi en karmaşık parçadır. Bu iki görevi ayırt ettikten sonra, uygulamalar sadece ilk adımı doğru bir şekilde gerçekleştirmek için gereklidir, bu da geliştirme döngüsünün daha önceki aşamalarında test ederek doğrulanması çok daha kolaydır. ek olarak, veri dağıtımı için yapılandırmaların doğruluğu doğrulamak ve denetlemek çok daha kolay hale gelir. Benzer bir yol izleyenler için ipuçları Sonuç olarak, size öğrendiklerimizle ilgili önemli dersler bırakacağız ve eğer bizimle benzer bir yol izlerseniz uygulamanızı öneririz: ScyllaDB'yi bir olay dağıtım sırası olarak kullanmak gibi zaman serisi verileri işlemek için kullandığınızda, zaman penceresi sıkıştırma stratejisini kullanmayı unutmayın. Veri dağıtımının sorumluluğunu ayırmak için anahtar alanları veri konteynerleri olarak kullanmayı düşünün.Bu, karmaşık veri dağıtım sorunlarını çok daha kolay yönetebilir. Tech Talks On-Demand İzle Bu makale, ScyllaDB Summit 2023'de sunulan bir teknoloji konuşmasına dayanıyor.Bu konuşmayı – Discord, Epic Games, Disney, Strava, ShareChat ve daha fazlasının mühendisleri tarafından talep üzerine konuşulan konuşmaları da izleyebilirsiniz. Tech Talks On Demand İzle
