Расскажите, пожалуйста, в двух словах, как вообще проектируются линейно масштабируемые (способные работать на нескольких узлах одновременно) веб-приложения с долгоживущими разделяемыми объектами типа диспетчеров (шин) сообщений? То есть, когда синхронизация не только на базу завязана, но и ещё на что-то. Выносить это что-то в отдельный процесс? Ок, усложним: а если необходимо синхронизировать обращения к БД и отправку сообщений?
что значит "синхронизировать отправку сообщений/обращения к БД"? Синхронизировать отправку сообщений нету смысла, они для каждой ноды свои. БД - реплекация либо она выносится на отдельный сервер. Сделать маршрутизацию сообщений в очередях на штуках типа rabbitmq не составляет особо проблем.
Намного интереснее организовывать процесс деплоя сей фигни.
Есть некий общий лог событий. Это могут быть сообщения в чате, например. Надо вновь подключившемуся клиенту сначала выдать лог предыдущих событий, после чего ожидать новых (хотя бы по WebSocket). Не должно быть пропусков и повторов. Я это решил, обрабатывая в специальном диспетчере в одном цикле сообщения и обращения к БД. Но как бы я стал это масштабировать, я не знаю.
Лоад балансер, ноды-воркеры, общаются между собой посредством amqp, кластеры баз данных общие.
Схематично это все выглядит не сложно, про "синхронизировать обращения к БД и отправку сообщений" не понял. А зачем вам еще отправку синхронизировать?
UPD Про чатик: вы загуглите современную архитектуру веб-чата, там все довольно просто без лишних синхронизаций, просто под это дело нужно будет отдельный бекенд, или несколько бекендов параллельных.
Я переформулирую, чтобы было менее сумбурно. Без синхронизации может произойти дублирование сообщений или пропажа (зависит от того, будет ли обработчик подключения выбирать историю из базы до или после подключения к диспетчеру сообщений).
Под историю - своя база, а для текущих сессий чата другая. Для текущих чатов можно даже использовать какое-то временное хранилище, а не отдельную базу.
Если между выборкой из базы и началом прослушивание придёт сообщение, оно будет потеряно. Если начинать слушать до, возможна обратная ситуация: сообщение, пришедшее между началом прослушивания и вычитыванием истории, будет прочитано дважды: из истории и из базы.
Ладно, не суть. Я просто хотел удостовериться, что нет какого-то отлаженного решения вроде базы данных с атомарными операциями типа «выборка состояния объекта + переход к ожиданию изменений объекта». А вопрос мне стоило на трезвую голову формулировать, конечно.
Схема такая: по приходу сообщения сначала пишем его в базу, затем рассылаем его остальным клиентам. По подключению нового клиента отправляем ему лог. И это в цикле.
