Хотелось бы дополнить. В некоторых базах данных еще и зависит от типа блокировки - таблица или запись. Но PK гарантированно будет разный. А по хорошему - автоинкремент зло лютое.
Вообще-то показывают обычно несколько последних (10-20) сообщений по времени, а на клиенте, в куках или webstorage (вообще офигительно!) хранят id последнего сообщения, обычно это unix timestamp (число). Если клиент не запростил ID последнего, то дают последние 10-20, по timestamp удобно выбирать из базы данных, или кафки :)
s, на фронте достаточно простого javascript/fetch, и может быть promises, если хотим асинхронности https://learn.javascript.ru/fetch (это и для SSE и для LongPool).
Для WS есть куча оберток, но можно и напрямую - https://learn.javascript.ru/websocket . В современном JS все достаточно удобно.
Касательно отличия опроса, от "длинного опроса". Опрос - это когда делаем постоянные запросы на сервер и тут-же получаем ответ. Это хреново, жрет кучу ресерсов и генерирует кучу трафика.
Long pooling - это когда подключились к серверу и сервер не дает ответа, до тех пор, пока у него что-то не перещелкнет (например не появится событие для конкретного клиента), тогда сервер генерирует ответ и закрывает соединение. Клиент заново подключается к серверу. На стороне сервера нужно просто иметь какой нибудь Hashtable для хранения открытых запросов - https://russianblogs.com/article/92601645700/
Для SSE - тоже нужен отдельный сервлет, но переподключаться к серверу не нужно, на стороне клиента можно использовать EventSource - https://learn.javascript.ru/server-sent-events (или тот-же fetch)
Я за SSE или LongPooling, но нужно обязательно на стороне сервера увеличить одновременное количество коннектов!, ибо каждый клиент будет держать открытое соединение).
Programist18946, смотрите про gstreamer. А примеры есть рядом в проекте.
Без знания gstreamer, увы, будет сложно. Но оно точно работает! И в линуксе, и в винде и на osx.
Сам его пользую в текущих проектах для потоковых аудио-видео.
dflbrhekbn, Да, весь трафик будет идти через прокси. И это, по хорошему, самый лучший, надежный, и контролируемый вариант.
Технически, можно делать http-редирект на instance1.mysite.com или instance2.mysite.com.
Но в этом случае все равно нельзя будет контролировать падение конкретного инстанса, ведь с него обратно нельзя будет переключиться, трафик уйдет непосредственно на упавший IP.
dflbrhekbn, Многие клауд-платформы это умеют. Из зарубежных точно - AWS и Cloudware. Из импортозаменителей, кажется точно есть такой функционал у mail.ru cloud (не знаю, как он теперь называется, что-то типа вконтактик в облаках :) )
С другой стороны, установить свой директор (reverse proxy) можно абсолютно на любой платформе, Вариантов я Вам назвал. Дел на час и 5-10 строчек конфига с вдумчивым чтением документации.
Если http/https, посмотрите на caddyserver!
Поддержу. Кидайте задачи в очереди и отдельными сервисами эти очереди разбирайте.
Если не нравится celery, то можно взять чего попроще, например https://python-rq.org/
Ну или самому написать простой обработчик с использованием очередей на redis, rabbitmq, kafka, apache pulsar ....
И проводочки подсоединил все? И процессор статикой не грохнул? И плату не перегнул? И дорожки не порвал? И контакты не загнул? И питание правильно вставлено?
И память с процессором спецификации соответствует?
Ну, если так - обязано работать!
Крутые предлагатели ответов.