Известията на живо са мястото, където Websockets процъфтяват и осигуряват огромно предимство пред AJAX.
Както знаете, това вече беше обсъждано и преди, когато се обсъждаше ролята на AJAX (страхотно за CRUD, не толкова при анкетиране) и при сравняване Ефективност на уеб сокет спрямо производителност на AJAX (Websockets винаги са по-бързи, когато става въпрос за актуализации на живо).
Да... бихте могли да спестите ресурси и да подобрите производителността (както и бъдещи проблеми с поддръжката на кода), като добавите on_update "куки" към точката за достъп до базата данни.
Идеята е проста:всеки път, когато извикване на функция актуализира базата данни MySQL, заявката за актуализиране също се изпраща на обратно извикване. Това обратно извикване отговаря за публикуването на актуализацията в правилния канал.
По този начин няма да анкетирате MySQL базата данни.
Някои бази данни предлагат обратни извиквания за актуализиране, а други не. Мисля, че MySQL го прави. Въпреки това избягвам тези обратни извиквания, свързани с база данни, защото са специфични за базата данни. По-добре (IMHO) е да добавите обратното извикване към точката за достъп до базата данни в приложението, така че подмяната на база данни да не повлияе на кодовата база.
Не мисля, че AJAX е добър подход.
HTTP/2 помага за смекчаване на недостатъците на AJAX, но не решава всички тях.
Не знам колко клиенти очаквате да бъдат свързани едновременно, но принуждаването на клиент да изпраща заявка на всеки секунда-две е много близко до самопричинена DoS атака.
Помислете за това:ако клиент изпраща AJAX заявка на всеки две секунди, отколкото при 2000 едновременни клиенти, вашият сървър ще трябва да отговори на 1000 req/sec – това включва удостоверяване, заявки за база данни и всичко това.
От друга страна, като използвате Websockets, с 2000 свързани клиента, имате 2000 постоянни връзки, които не правят нищо, докато не пристигне съобщение. Не се изисква процесор или работа, само паметта на връзката. Няма напрежение върху сървъра, докато действителните данни не бъдат изпратени.
Да, те са по-сложни за изпълнение, но не са толкова трудни, след като започнете. Освен това има много библиотеки и помощни инструменти, които отнемат голяма част от работата от плещите ви.
Често срещаните проблеми, свързани с подхода Websocket, включват обработката на хоризонталното мащабиране (често чрез добавяне на база данни на pub/sub или услуга, като Redis), подреждане на съобщения (което е по-добре игнорирано, когато е възможно) и опасения за разпространение на данни (кога маркираме данни като "виждани"? изпращаме ли всички данни или само известие, че данните са налични? колко канала използваме и как разделяме абонаментите?).
Обикновено отговорите са специфични за приложението и зависят от функцията, която се опитвате да развиете, както и от очаквания размер на вашия набор от данни (ако всеки отговор, който дадох на SO, беше канал, би било нереалистично да се поддържа).
Както и да е... Успех!
