Przegląd:

• Intro
• Architektura serwera
• Architektura klienta
• przypadek aktualizacji
• Commit case
• konflikt sprawy
• wydajność i skalowalność

Cześć Raynos,

Nie będę tutaj omawiał żadnego konkretnego produktu. To, o czym inni wspominali, to dobry zestaw narzędzi, na który można już rzucić okiem (może dodać węzeł.js do tej listy).

Z architektonicznego punktu widzenia wydaje się, że masz ten sam problem, który można zobaczyć w oprogramowanie do kontroli wersji. Jeden użytkownik sprawdza zmianę obiektu, inny użytkownik chce zmienić ten sam obiekt w inny sposób => konflikt. Musisz integrować zmiany użytkowników w obiektach, a jednocześnie być w stanie dostarczać aktualizacje na czas i skutecznie, wykrywając i rozwiązując konflikty, takie jak powyższy.

Gdybym był na Twoim miejscu, rozwinąłbym coś takiego:

1. Server-Side:

• Określ rozsądny poziom, na którym zdefiniujesz co nazwałbym " atomic artefacts "(strona? Obiekty na stronie? Wartości wewnątrz obiektów?). Będzie to zależeć od serwerów WWW, sprzętu bazodanowego i buforowania, # użytkownika, # obiektów itp. Niełatwa decyzja.

• Dla każdego artefaktu atomowego mają:

  • unikalny identyfikator aplikacji
  • an incrementing version-id
  • mechanizm blokujący dostęp do zapisu (mutex)
  • mała historia lub" changelog " wewnątrz bufora ringbuffera (pamięć dzielona działa dobrze dla nich). Pojedyncza para klucz-wartość może być również OK, choć mniej rozszerzalna. zobacz http://en.wikipedia.org/wiki/Circular_buffer

• Komponent serwera lub pseudo-serwera, który jest w stanie dostarczyć odpowiednie changelogi do podłączonego użytkownika efektywnie. Obserwator-wzór jest twoim przyjacielem do tego.

2. Client-Side:

• Klient javascript, który może mieć długotrwałe połączenie HTTP z wyżej wymienionym serwerem, lub używa lekkiego sondażu.

• Komponent JavaScript artifact-updater, który odświeża zawartość witryny, gdy podłączony klient javascript powiadomi o zmianach w obserwowanej historii artefaktów. (ponownie wzór obserwatora może być dobrym wyborem)

• Komponent JavaScript artifact-committer, który może zażądać zmiany artefaktu atomowego, próbując zdobyć blokadę mutex. Wykryje, czy stan artefaktu został zmieniony przez innego użytkownika zaledwie kilka sekund przed (latancja klienta javascript i czynników procesu zatwierdzania w) poprzez porównanie znanego artifact-version-id klienta i bieżącego Artifact-version-id serwera.

• Javascript conflict-solver pozwalający na człowieka, który-zmienia-jest-właściwą decyzją. Możesz nie chcieć po prostu powiedzieć użytkownikowi " ktoś był szybszy od Ciebie. Usunąłem resztę. Idź się rozpłakać.". Wiele opcji z raczej technicznych różnic lub bardziej przyjaznych dla użytkownika rozwiązań wydaje się możliwych.

Więc jak to się potoczy ...

Przypadek 1: Rodzaj-of-sequence-diagram dla aktualizacji:

• przeglądarka renderuje stronę
• javascript "widzi" artefakty, z których każdy ma co najmniej jedno pole wartości, unikalny-i identyfikator wersji
• uruchamia się klient javascript, prosząc o "oglądanie" historii znalezionych artefaktów począwszy od ich znalezionych wersji (starsze zmiany nie są interesujące)
• proces serwera notuje żądanie i stale sprawdza i / lub wysyła historię
• wpisy historyczne mogą contain simple notifications "Artifact x has changed, Client pls request data" allowing the client to poll niezależnie lub Pełne zestawy danych"artifact x has changed to value foo"
• JavaScript artifact-updater robi, co może, aby pobrać nowe wartości, gdy tylko staną się znane jako zaktualizowane. Wykonuje nowe żądania ajax lub jest zasilany przez Klienta javascript.
• strony DOM-treść jest aktualizowana, użytkownik jest opcjonalnie powiadamiany. Oglądanie historii trwa.

Przypadek 2: Teraz dla:

• Artifact-committer zna żądaną nową wartość z danych wejściowych użytkownika i wysyła żądanie zmiany do serwera
• serwer mutex został przejęty
• serwer otrzymuje "Hej, znam stan artifact x z wersji 123, pozwól mi ustawić go na wartość foo pls."
• Jeśli Serverside wersja artifact x jest równa (nie może być mniejsza) niż 123 nowa wartość jest akceptowana, nowy ID wersji 124 wygenerowany.
• nowy stan-informacje " aktualizacja do wersji 124" i opcjonalnie nowa wartość foo jest umieszczana na początku bufora ringbuffera artefaktu x (changelog/history)
• serverside mutex is released
• zgłaszający Artifact commit chętnie otrzyma potwierdzenie zatwierdzenia wraz z nowym identyfikatorem.
• tymczasem komponent serverside Server wciąż przepycha bufory ringbuffers do podłączonych klientów. Wszyscy klienci Obserwujący bufor artifact x otrzymają nowe informacje o stanie i wartości w ramach zwykłego opóźnienia (patrz case 1.)

Przypadek 3: dla konfliktów:

• Artifact committer zna żądaną nową wartość z danych wejściowych użytkownika i wysyła żądanie zmiany do serwera
• W międzyczasie inny użytkownik pomyślnie zaktualizował ten sam artefakt (patrz przypadek 2.) ale z powodu różnych opóźnień jest to jeszcze nieznane naszemu drugiemu użytkownikowi.
W ten sposób mutex po stronie serwera jest pozyskiwany (lub czekany, aż "szybszy" użytkownik dokona zmiany)
• serwer otrzymuje "Hej, znam stan artifact x z wersji 123, ustawię na wartość foo."
• na serwerze wersja artifact x ma już 124. Klient żądający nie może znać wartości, którą nadpisałby.
• oczywiście serwer musi odrzucić żądanie zmiany (nie licząc interweniujących przez Boga priorytetów nadpisania), zwolnić mutex i jest na tyle uprzejmy, aby odesłać nowy identyfikator wersji i nową wartość bezpośrednio do klienta.
• skonfrontowany z odrzuconym żądaniem zatwierdzenia i wartością użytkownika żądającego zmiany jeszcze nie wiedziałem, że committer artefaktów javascript odnosi się do rozwiązującego konflikty, który wyświetla i wyjaśnia problem użytkownikowi.
• użytkownik, przedstawiony z niektórymi opcjami przez inteligentnego rozwiązującego konflikty JS, może ponownie spróbować zmienić wartość.
• Gdy użytkownik wybrał wartość, którą uważa za właściwą, proces rozpoczyna się od przypadku 2 (lub przypadku 3, jeśli ktoś inny był szybszy, ponownie)

Ankieta HTTP vs. HTTP "pushing"

Ankieta tworzy żądania, jeden na sekundę, pięć na sekundę, niezależnie od tego, co uznasz za akceptowalne opóźnienie. Może to być dość okrutne dla Twojej infrastruktury, jeśli nie skonfigurujesz swojego (Apache?) i (php?) wystarczająco dobrze, aby być" lekkim " przystawką. Pożądane jest zoptymalizowanie żądania ankiety po stronie serwera, tak aby trwało ono znacznie krócej niż długość interwału ankiety. Podzielenie tego środowiska uruchomieniowego na pół może oznaczać obniżenie całego systemu obciążenie do 50%,
• przepychanie przez HTTP (zakładając, że webworkerzy są zbyt daleko, aby je obsługiwać) będzie wymagało posiadania jednego procesu apache / lighttpd dostępnego dla każdego użytkownika przez cały czas. Pamięć rezydentna zarezerwowana dla każdego z tych procesów i całkowita pamięć Twojego systemu będzie jednym bardzo pewnym ograniczeniem skalowania, które napotkasz. Konieczne będzie zmniejszenie ilości pamięci łącza, a także ograniczenie ilości pracy procesora i wejścia/Wyjścia wykonywanej w każdym z te (chcesz dużo snu/czasu bezczynności)

Skalowanie Backend

• zapomnij o bazie danych i systemie plików, będziesz potrzebował jakiegoś backendu opartego na pamięci współdzielonej do częstego wyszukiwania (jeśli klient nie przepytuje bezpośrednio, to każdy uruchomiony proces serwera)
• jeśli wybierzesz memcache, możesz skalować lepiej, ale nadal jest drogi
• mutex dla commitów musi działać globalnie, nawet jeśli chcesz mieć wiele serwerów frontend do załadowania.

Skalowanie Frontend

• niezależnie od tego, czy przeprowadzasz ankietę, czy otrzymujesz "Wypychy", spróbuj uzyskać informacje o wszystkich obserwowanych artefaktach w jednym kroku.

" kreatywne " poprawki

• Jeśli klienci przeprowadzają ankiety i wielu użytkowników ogląda te same artefakty, możesz spróbować opublikować historię tych artefaktów jako plik statyczny, pozwalając apache ' owi na buforowanie go, mimo to odświeżając go po stronie serwera, gdy artefakty ulegną zmianie. To usuwa PHP / memcache gry Niektóre na życzenie. Lighthttpd jest bardzo skuteczny w obsłudze plików statycznych.
• Użyj sieci dostarczania treści, takiej jak cotendo.com żeby wypchnąć tam historię artefaktów. Opóźnienie push będzie większe, ale skalowalność to marzenie]}
• napisz prawdziwy serwer (nie używając HTTP), do którego użytkownicy łączą się za pomocą Javy lub Flasha(?). Masz do czynienia z obsługą wielu użytkowników w jednym serwerze-wątku. Jazda na rowerze przez otwarte gniazda, wykonywanie (lub delegowanie) wymaganej pracy. Może skalować za pomocą procesów rozwidlania lub uruchamianie kolejnych serwerów. Muteksy muszą jednak pozostać unikalne na całym świecie.
• w zależności od scenariuszy obciążenia Grupuj frontend-i backend-serwery według zakresów Artifact-id. Pozwoli to na lepsze wykorzystanie pamięci trwałej (Żadna baza danych nie zawiera wszystkich danych) i umożliwi skalowanie muteksowania. Twój javascript musi utrzymywać połączenia z wieloma serwerami jednocześnie.

Mam nadzieję, że to może być początek dla Twoich własnych pomysłów. Jestem pewien, że jest ich dużo więcej. możliwości. Jestem bardziej niż mile widziana jakakolwiek krytyka lub ulepszenia tego postu, wiki jest włączona.

Christoph Strasen