Powiadomienia na żywo to miejsce, w którym gniazda sieciowe rozwijają się i zapewniają ogromną przewagę nad AJAX.
Jak wiecie, zostało to już omówione wcześniej podczas debaty o roli AJAX (świetne dla CRUD, nie tak bardzo podczas odpytywania) i przy porównywaniu Wydajność gniazda sieciowego a wydajność AJAX (Websockets są zawsze szybsze w przypadku aktualizacji na żywo).
Tak... możesz zaoszczędzić zasoby i poprawić wydajność (jak również przyszłe problemy z obsługą kodu), dodając on_update "haczy" punkt dostępu do bazy danych.
Pomysł jest prosty:za każdym razem, gdy wywołanie funkcji aktualizuje bazę danych MySQL, żądanie aktualizacji jest również wysyłane do wywołania zwrotnego. To wywołanie zwrotne odpowiada za opublikowanie aktualizacji na odpowiednim kanale.
W ten sposób nie przeszukujesz bazy danych MySQL.
Niektóre bazy danych oferują wywołania zwrotne aktualizacji, a inne nie. Myślę, że MySQL tak. Jednak unikam tych wywołań zwrotnych połączonych z bazą danych, ponieważ są one specyficzne dla bazy danych. Lepiej (IMHO) dodać wywołanie zwrotne do punktu dostępu do bazy danych w aplikacji, więc zastąpienie bazy danych nie ma wpływu na bazę kodu.
Nie sądzę, że AJAX jest dobrym podejściem.
HTTP/2 pomaga złagodzić niedociągnięcia AJAX, ale nie rozwiązuje ich wszystkich.
Nie wiem, ilu klientów spodziewasz się być jednocześnie połączonych, ale zmuszanie klienta do wysyłania żądania co sekundę lub dwie jest bardzo bliskie samoistnemu atakowi DoS.
Rozważ to:jeśli klient wysyła żądanie AJAX co dwie sekundy, niż przy 2000 jednoczesnych klientów, twój serwer będzie musiał odpowiedzieć na 1000 żądań/s – obejmuje to uwierzytelnianie, zapytania do bazy danych i całą resztę.
Z drugiej strony, używając Websockets, z 2000 połączonych klientów, masz 2000 stałych połączeń, które nic nie robią, dopóki nie nadejdzie wiadomość. Nie wymaga procesora ani pracy, tylko pamięć połączenia. Serwer nie jest obciążony, dopóki nie zostaną przesłane rzeczywiste dane.
Tak, są one bardziej skomplikowane do wdrożenia, ale nie są już takie trudne, gdy już zaczniesz. Ponadto istnieje wiele bibliotek i narzędzi pomocniczych, które zdejmują większość pracy z twoich barków.
Typowe problemy związane z podejściem Websocket obejmują obsługę skalowania poziomego (często przez dodanie bazy danych pub/sub lub usługi, takiej jak Redis), porządkowanie komunikatów (co lepiej ignorować, gdy to możliwe) oraz problemy z propagacją danych (kiedy zaznaczamy dane jako „widziane”? czy wysyłamy całe dane, czy tylko powiadomienie z informacją, że dane są dostępne? z ilu kanałów korzystamy i jak dzielimy subskrypcje?).
Zwykle odpowiedzi są specyficzne dla aplikacji i zależą od funkcji, którą próbujesz rozwinąć, a także od oczekiwanego rozmiaru zestawu danych (jeśli każda odpowiedź, której udzieliłem w SO, była kanałem, utrzymywanie byłoby nierealistyczne).
W każdym razie... Powodzenia!
