Scala + Akka: jak stworzyć Klaster wielozadaniowy
Tworzymy system serwerowy w Scala + Akka dla gry, która będzie obsługiwać klientów na Androida, iPhone ' a i Second Life. Istnieją części tego serwera, które muszą być wysoce dostępne, działające na wielu komputerach. Jeśli jeden z tych serwerów umrze (np. z powodu awarii sprzętu), system musi nadal działać. Myślę, że chcę, aby klienci mieli listę maszyn, z którymi spróbują się połączyć, podobnie jak Cassandra.
Przykłady wielu węzłów widziałem do tej pory z Akka wydaje mi się, że koncentruje się wokół idei skalowalności, a nie wysokiej dostępności (przynajmniej w odniesieniu do sprzętu). Przykłady wielu węzłów wydają się zawsze mieć jeden punkt awarii. Na przykład istnieją Równoważniki obciążenia, ale jeśli muszę ponownie uruchomić jedną z maszyn, które mają Równoważniki obciążenia, mój system będzie cierpiał na pewne przestoje.
Czy są jakieś przykłady, które pokazują tego typu odporność na awarie sprzętu dla Akka? Czy masz jakieś pomysły na dobre sposoby, aby to zrobić stało się?
Jak dotąd, najlepszą odpowiedzią, jaką udało mi się wymyślić, jest studiowanie dokumentów Erlang OTP, medytowanie nad nimi i próbowanie dowiedzieć się, jak połączyć mój system z pomocą klocków dostępnych w Akce.
Ale jeśli są zasoby, przykłady lub pomysły na to, jak dzielić Stan między wieloma maszynami w taki sposób, że jeśli jeden z nich pójdzie w dół, to na pewno będę je doceniał, ponieważ obawiam się, że mogę ponownie wynaleźć koło tutaj. Może jest kontener STM z wieloma węzłami, który automatycznie synchronizuje stan współdzielony między wieloma węzłami? A może jest to tak łatwe do wykonania, że dokumentacja nie przeszkadza Pokazywanie przykładów, jak to zrobić, a może nie byłem wystarczająco dokładny w moich badaniach i eksperymentach jeszcze. Wszelkie myśli lub pomysły zostaną docenione.
4 answers
Ha i zarządzanie obciążeniem jest bardzo ważnym aspektem skalowalności i jest dostępne jako część oferty handlowej AkkaSource.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-03-23 10:51:54
Jeśli wymieniasz już wiele potencjalnych hostów w swoich klientach, mogą one skutecznie stać się równoważnikami obciążenia.
Możesz zaoferować usługę sugestii hosta i polecić klientowi, do którego komputera powinien się podłączyć( na podstawie aktualnego obciążenia, czy cokolwiek), a następnie klient może do tego przypinać, dopóki połączenie nie zawiedzie.
Jeśli usługa sugestii hosta nie istnieje, klient może po prostu wybrać losowy host z wewnętrznej listy, wypróbowując je, dopóki się nie połączy.
Najlepiej przy pierwszym uruchomieniu, klient połączy się z usługą sugestii hosta i nie tylko zostanie skierowany do odpowiedniego hosta, ale także listy innych potencjalnych hostów. Ta lista może być rutynowo aktualizowana za każdym razem, gdy klient się łączy.
Jeśli usługa sugestii hosta jest wyłączona na pierwszej próbie klientów (mało prawdopodobne, ale...) następnie możesz wstępnie wdrożyć listę hostów w instalacji klienta, dzięki czemu można rozpocząć od razu losowo wybierając hosty od samego początku jeśli też.
Upewnij się, że lista hostów to rzeczywiste nazwy hostów, a nie adresy IP, które zapewniają większą elastyczność w dłuższej perspektywie (np. host1.example.com, host2.example.com ... itd. nawet jeśli przenosisz infrastrukturę i zmieniasz adresy IP).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-09-11 21:23:34
Możesz spojrzeć jak reddwarf i to jest Widelec DimDwarf są zbudowane. Są to zarówno skalowalne poziomo serwery aplikacji do gier, a DimDwarf jest częściowo napisany w Scali (nowa funkcjonalność przesyłania wiadomości). Ich podejście i architektura powinny pasować do Twoich potrzeb całkiem dobrze:)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-09-12 09:28:20
2 centy..
"jak współdzielić Stan między wieloma maszynami w taki sposób, że jeśli jedna z nich pójdzie w dół, wszystko będzie działać"
Nie dziel stanu między maszynami, zamiast tego dziel Stan między maszynami. Nie znam Twojej domeny, więc nie wiem, czy to zadziała. Ale zasadniczo, jeśli przypisujesz pewne Agregaty ( w terminach DDD ) do pewnych węzłów, możesz zachować te Agregaty w pamięci (aktor, agent, itp.), gdy są używane. Aby to zrobić, musisz użyć coś jak zookeeper do koordynowania, które węzły obsługują które Agregaty. W przypadku awarii można przenieść agregat na inny węzeł.
Co więcej, jeśli używasz modelu pozyskiwania zdarzeń do budowania agregatów, prawie trywialne staje się posiadanie kopii w czasie rzeczywistym ( niewolników ) agregatu na innych węzłach przez te węzły nasłuchujące zdarzeń i utrzymujące własne kopie.
Używając Akka, otrzymujemy remotowanie między węzłami prawie za darmo. Oznacza to, że każdy węzeł obsługuje żądanie, które może wymagać interakcji z agregatem/jednostką na innych węzłach, może to zrobić za pomocą RemoteActors.
To, co tu opisałem jest bardzo ogólne, ale daje podejście do rozproszonej tolerancji błędów z Akką i Zookeeperem. To może pomóc lub nie. Mam nadzieję.
All the best, Andy
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-01-30 21:13:12