Как делать линейно масштабируемые веб-приложения?

Question

[e_asphyx]

Расскажите, пожалуйста, в двух словах, как вообще проектируются линейно масштабируемые (способные работать на нескольких узлах одновременно) веб-приложения с долгоживущими разделяемыми объектами типа диспетчеров (шин) сообщений? То есть, когда синхронизация не только на базу завязана, но и ещё на что-то. Выносить это что-то в отдельный процесс? Ок, усложним: а если необходимо синхронизировать обращения к БД и отправку сообщений?

Answer 1

[Сергей Протько]

что значит "синхронизировать отправку сообщений/обращения к БД"? Синхронизировать отправку сообщений нету смысла, они для каждой ноды свои. БД - реплекация либо она выносится на отдельный сервер. Сделать маршрутизацию сообщений в очередях на штуках типа rabbitmq не составляет особо проблем.

Намного интереснее организовывать процесс деплоя сей фигни.

Comments

[e_asphyx]

Есть некий общий лог событий. Это могут быть сообщения в чате, например. Надо вновь подключившемуся клиенту сначала выдать лог предыдущих событий, после чего ожидать новых (хотя бы по WebSocket). Не должно быть пропусков и повторов. Я это решил, обрабатывая в специальном диспетчере в одном цикле сообщения и обращения к БД. Но как бы я стал это масштабировать, я не знаю.

Answer 2

[s1dney]

Лоад балансер, ноды-воркеры, общаются между собой посредством amqp, кластеры баз данных общие.
Схематично это все выглядит не сложно, про "синхронизировать обращения к БД и отправку сообщений" не понял. А зачем вам еще отправку синхронизировать?

UPD Про чатик: вы загуглите современную архитектуру веб-чата, там все довольно просто без лишних синхронизаций, просто под это дело нужно будет отдельный бекенд, или несколько бекендов параллельных.

Comments

[e_asphyx]

Я переформулирую, чтобы было менее сумбурно. Без синхронизации может произойти дублирование сообщений или пропажа (зависит от того, будет ли обработчик подключения выбирать историю из базы до или после подключения к диспетчеру сообщений).

[e_asphyx]

То есть альтернатива только отказ от брокера сообщений в пользу средств БД по нотификации об изменениях.

[s1dney]

Да с чего вы взяли, что может?) Вот подключается клиент, вы ему синхронно выдаете сначала историю, потом он начинает слушать очередь.

[s1dney]

Под историю - своя база, а для текущих сессий чата другая. Для текущих чатов можно даже использовать какое-то временное хранилище, а не отдельную базу.

[e_asphyx]

Если между выборкой из базы и началом прослушивание придёт сообщение, оно будет потеряно. Если начинать слушать до, возможна обратная ситуация: сообщение, пришедшее между началом прослушивания и вычитыванием истории, будет прочитано дважды: из истории и из базы.

[s1dney]

Лог истории, сообщение активному юзеру и недоставленное сообщение это же разные сущности. Не надо складывать все в 1 столбик.

[e_asphyx]

Ладно, не суть. Я просто хотел удостовериться, что нет какого-то отлаженного решения вроде базы данных с атомарными операциями типа «выборка состояния объекта + переход к ожиданию изменений объекта». А вопрос мне стоило на трезвую голову формулировать, конечно.

Answer 3

[e_asphyx]

Схема такая: по приходу сообщения сначала пишем его в базу, затем рассылаем его остальным клиентам. По подключению нового клиента отправляем ему лог. И это в цикле.