Živá upozornění jsou místo, kde se Websockets daří a poskytují obrovskou výhodu oproti AJAX.
Jak víte, bylo to již probráno před oběma při debatě o úloze AJAX (skvělé pro CRUD, ne tolik při hlasování) a při porovnávání Výkon webového soketu vs. výkon AJAX (Websockety jsou vždy rychlejší, pokud jde o živé aktualizace).
Ano... přidáním on_update můžete ušetřit zdroje a zlepšit výkon (stejně jako budoucí problémy s údržbou kódu) "háčky" k přístupovému bodu databáze.
Myšlenka je jednoduchá:kdykoli volání funkce aktualizuje databázi MySQL, požadavek na aktualizaci je také odeslán zpětnému volání. Toto zpětné volání má na starosti publikování aktualizace na správný kanál.
Tímto způsobem neprovádíte dotazování databáze MySQL.
Některé databáze nabízejí zpětná volání aktualizace a jiné ne. Myslím, že MySQL ano. Vyhýbám se však těmto zpětným voláním spojeným s databází, protože jsou specifické pro databázi. Je lepší (IMHO) přidat zpětné volání k přístupovému bodu databáze v aplikaci, takže nahrazení databáze neovlivní základnu kódu.
Nemyslím si, že AJAX je dobrý přístup.
HTTP/2 pomáhá zmírnit nedostatky AJAX, ale neřeší je všechny.
Nevím, kolik klientů očekáváte, že bude současně připojeno, ale donutit klienta, aby každou sekundu nebo dvě odeslal požadavek, je velmi blízko útoku DoS, který si sám způsobí.
Zvažte toto:pokud klient odešle požadavek AJAX každé dvě sekundy, než u 2 000 souběžných klientů bude muset váš server odpovědět na 1 000 požadavků/s – mezi ně patří autentizace, databázové dotazy a vše ostatní.
Na druhou stranu při použití Websockets s 2 000 připojenými klienty máte 2 000 trvalých připojení, které nic nedělají, dokud nepřijde zpráva. Nevyžaduje žádný CPU ani práci, pouze paměť připojení. Na serveru není žádný stres, dokud nejsou odeslána skutečná data.
Ano, jejich implementace je složitější, ale jakmile začnete, nejsou tak těžké. Existuje také mnoho knihoven a pomocných nástrojů, které vám vezmou většinu práce z vašich ramen.
Mezi běžné problémy související s přístupem Websocket patří zpracování horizontálního škálování (často přidáním pub/sub databáze nebo služby, jako je Redis), řazení zpráv (které je lepší ignorovat, pokud je to možné) a problémy s šířením dat (kdy označíme data jako „viděná“? zasíláme celá data, nebo jen upozornění, že jsou data dostupná? kolik kanálů používáme a jak rozdělujeme předplatné?).
Obvykle jsou odpovědi specifické pro aplikaci a závisí na funkci, kterou se pokoušíte rozvinout, a také na očekávané velikosti vaší datové sady (pokud by každá odpověď, kterou jsem dal na SO, byla kanálem, bylo by nereálné ji udržovat).
Každopádně... Hodně štěstí!