Jak wygenerować delty dla usuniętych danych w architekturze serwera klienta?

Question

Moi koledzy i ja stworzyliśmy kilka programów architektury klienckiej, które używają delt do synchronizacji klienta z serwerem. Problem związany z usuwaniem rekordów pojawia się w wielu projektach. W jaki sposób serwer może usuwać rekordy lokalnie i nadal ma wystarczającą ilość informacji do wygenerowania informacji o delcie usuwania dla przyszłych klientów?

Przykład 1:

gra w czasie rzeczywistym wykorzystuje UDP klient-serwer do zsynchronizowania podmioty między grami. Przesyłane są tylko delty zawierające zmodyfikowany stan gry i wcześniej upuszczone dane pakietowe. Jeśli serwer usunie encję, może wysłać deltę usuwania, każąc każdemu klientowi usunąć ten obiekt. Działa to, chyba że pakiet zostanie upuszczony. Jest to możliwe w przypadku normalnych danych stanu, ponieważ serwer może zidentyfikować, które dane zostały usunięte, i ponownie przesłać z nich delta, ale to oznaczałoby, że serwer nie mógłby lokalnie usunąć encji serwera (bez wykonywania pełnego potwierdzenia od każdego klienta), ponieważ istniałyby dane generujące delta usuwania z.

Przykład 2:

klient chce zsynchronizować z bazą danych przechowywanych na serwerze. Serwer przechowuje zmodyfikowaną datę dla każdego rekordu na serwerze. Gdy klient zażąda synchronizacji, przesyła ostatnią datę, która została zaktualizowana. Serwer zbiera wszystkie rekordy, które zostały zmodyfikowane od tej daty i wysyła je do klienta. Działa to z usuwaniem tylko wtedy, gdy serwer zachowuje każdy rekord usunięty i używa flagi do wskazania usunięcia. Serwer nie może bezpiecznie usunąć zapisanego lokalnie rekordu.

W obu przykładach jedynym rozwiązaniem, jakie mogę wymyślić, jest przytrzymanie jakiegoś rekordu zawierającego wszystko, co kiedykolwiek zostało usunięte, lub wymuszenie całej synchronizacji po określonej dacie/godzinie. Nie wydają się one trwałymi lub pełnymi gracji modelami. Jakie są zrównoważone metody rozwiązywania tego typu problemów?

Answer 1

Dlaczego nie wydaje się to zrównoważone? Wiele frameworków synchronizacji używa tego i nazywa się Tombstoning, afaik. Rekord jest usuwany lub oflagowany jako usunięty, aw innej tabeli (jeśli dotyczy baz danych), przechowywane jest odniesienie do usuniętego elementu. W ten sposób systemy są w stanie zsynchronizować rekordy, które zostały usunięte. W rzeczywistości nie chodzi tylko o usuwanie danych. Niektórzy mogą powiedzieć, że każda aktualizacja rekordu jest również usunięciem. Ponieważ starej wersji rekordu nigdy więcej nie można znaleźć. Dlatego zamiast wysyłać aktualizacje do magazynu danych, należy wysyłać tylko inserty, jeśli ważne jest przechowywanie "starych" danych.

W przypadku UDP i utraty pakietów, będziesz musiał zaprojektować swoje oprogramowanie wokół niego. Jeśli gra przesyła dane dla jakiegoś podmiotu, który został już usunięty, po prostu zignoruj ​​go lub odpowiedz na nie poprawnie. Tak wiele opcji tutaj.

Być może patrzysz również na źródło zdarzeń. Nie jest to święta księżniczka ani nic, ale działa inaczej niż zwykły CRUD. Zamiast tego używa CQRS do oddzielenia polecenia od strony zapytań, a pozyskiwanie zdarzeń jest używane do tworzenia strumienia zdarzeń. Przechowujesz tylko zdarzenia. Kiedy więc chcesz podać jakąś istotę, odtworzysz wszystkie wydarzenia. Prawdopodobnie zaczyna się zawsze od wstawienia, zerowej lub wielokrotnej aktualizacji, a następnie pewnej instrukcji usuwania. Będziesz miał wszystko, co musisz wiedzieć. Te zdarzenia są również wysyłane do innych komponentów, które tworzą modele odczytu najnowszego stanu. W ten sposób niektóre interfejsy użytkownika mogą odczytywać z modelu odczytu i szybko się palić, ale każda zmiana stanu przychodzi poprzez strumień zdarzeń, obsługując logikę biznesową dla każdego zdarzenia.

Jeśli jesteś tym zainteresowany, przeczytaj o CQRS i pozyskiwaniu wydarzeń od Grega Younga i wielu innych osób.