Mój turowy serwer gier C ++ (który korzysta z bazy danych) nie jest w stanie przeciwstawić się bieżącej średniej liczbie klientów (graczy), dlatego chcę rozszerzyć go na wiele (więcej niż jedną) liczbę komputerów i baz danych, w których wszyscy klienci nadal pozostaną w obrębie jeden świat gry (serwery muszą się ze sobą komunikować i korzystać z wielu baz danych).
Czy są jakieś tutoriale / książki / wspólne standardy, które wyjaśniają, jak to zrobić w najlepszy sposób?
Odpowiedzi:
Terminologia MMO dotycząca „pozostania w jednym świecie gry” jest pojedyncza odłamkiem . EVE online jest jedyną znaczącą grą MMO, w której każdy gracz może umieścić jednego gracza w jednym odłamku.
Na szczęście opublikowali bardzo pouczający artykuł na temat tego, jak to robią.
(źródło: gamasutra.com )
Złe wiadomości. Zasadniczo nie można stosować technik EVE online. Ich rozwiązania są absolutnie dostosowane do konkretnego gatunku i wdrożenia.
UWAGA : W przypadku wszystkich bardzo fantazyjnych sieci z jednym odłamkiem EVE online korzystają one z jednej bazy danych. Nie byli w stanie zaprojektować skalowalnego, spójnego rozwiązania w umiarkowanym czasie rzeczywistym dla rozproszonych baz danych.
Tak czy inaczej, przeczytanie, w jaki sposób to zrobiło, powinno pomóc ci zaprojektować własne rozwiązanie. Uważaj jednak, próbujesz rozwiązać bardzo trudny problem.
Zamiast dystrybuować serwer gry, sugeruję najpierw zbadanie innych możliwości.
Pierwszym krokiem powinno być oddzielenie bezpośredniego dostępu do bazy danych od serwera gry i użycie oprogramowania pośredniego specyficznego dla użytkowania do przygotowania danych dla serwera (np. XML, JSON). Będą one w stanie obsłużyć dowolną liczbę baz danych, a co ważniejsze, będą w stanie zapewnić ci opcje buforowania specyficzne dla aplikacji. Buforuj wszystko, co możesz i dokuczaj db tylko wtedy, gdy musisz. Dokonuj dużych pobrań i rzadko zamiast wielu małych zapytań, aby osiągnąć najlepszą możliwą wydajność w twoim scenariuszu.
Wybrana baza danych może również umożliwiać obsługę klastrów, które ułatwiają rozbudowę dostępnych zasobów bazy danych i szybsze dostarczanie wyników, ale jest to temat wymagający dużego doświadczenia i dedykowanego administratora bazy danych do skonfigurowania i utrzymania - i nie do końca z budżetu indie.
W odniesieniu do serwera gry: Powszechną strategią jest używanie wielu serwerów, z których każdy zarządza częścią świata gry. Każdy użytkownik zwykle musi tylko wiedzieć o tym, co się wokół niego dzieje, dlatego warto podzielić świat według lokalizacji. To niestety komplikuje się znacznie bardziej, gdy masz otwarty świat bez granic zamiast świata składającego się z zamkniętych stref i graczy teleportujących się między nimi. Gdy masz otwarty świat, potrzebujesz sposobu na płynne przenoszenie graczy między strefami oraz synchronizacji obszarów w pobliżu granic między serwerami. To podchwytliwy problem.
Jeśli chodzi o bazę danych: bazy danych SQL zwykle źle się skalują. Nie są przeznaczone do dystrybucji. Ale obecnie istnieje dość nowy trend w bazach danych NoSQL, takich jak MongoDB lub Cassandra, które zostały zaprojektowane do dystrybucji na wielu serwerach. Ułatwiają zwiększenie pojemności poprzez dodanie większej liczby serwerów. Dlaczego więc wszystkie duże gry się do nich nie przełączają? Bo:
Kiedy Twój projekt jest już bardzo zaawansowany, przejście na inne rozwiązanie bazodanowe może być dużym ryzykiem i bardzo dużą inwestycją czasu i energii.
Nie. To niezwykle trudny obszar, który nie został jeszcze rozwiązany.
Wiem, że to stare, ale ....
Są dwa obszary, na których należy się skupić.
Musisz rozpowszechnić aplikację na kilku serwerach. Musisz rozpowszechnić bazę danych na kilku serwerach.
I musisz mieć redundancję dla obu.
Istnieje kilka rozwiązań tego typu. Farmville jest dobrym przykładem użycia MemSQL / Couchbase.