Комментарии 6
К вопросу архитектуры, думаю, нужно подходить изначально из требований. Например, обработка асинхронных (как и сихронных) сообщений накладывает свои ограничения, например, по скорости, памяти, менеджменту соединений и т.п. Нужно исходить из конкретных задач. Например, у нас на проекте изначально MQ (WebSphere) покрывала все требования (30'000 сообщений в час). Но с увеличением требований по скорости обработки сообщений 300'000 сообщений в час нужно уже пересматривать архитектуру: где-то еще распараллелить, а где-то убрать отслыку сообщения и работать напрямую; где-то использовать вместо MQ естественный общий ресурс — базу данных; отказаться от персистентности сообщений и т.д. Какую пропускную способность Вы предполагаете на игровом сервере? Насколько затратным будет выполнение одного сообщения?
+1
Знаете, еще не прочитал Вашу вторую статью, но читал первую. Для решения задач с высокой нагрузкой, а именоо на это вы и нацеливаете сервис думаю Erlang для Вас наиболее оптимальный выбор.
0
да я тоже думаю, но тута еще стоит подумать, как я буду использовать функционал… может стоит на некоторые задачи выделить отдельные сервера… или вовсе обойтись… в общем пока это исследование различных архитектур. а Ерланг сильно уже иная технология для меня :)
0
единственное чего не умеет ezComponents Это хранить саму очередь а отправлять сообщения между серверами это помойму вполне легко сделать на базе ezComponents, сама очередь из себя будет представлять проосто последовательность хттп запросов к другому серверу если это межсерверное взаимодействие сделать можно по средствам RPC
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Краткий обзор MQ (Messages queue) для применения в проектах на РНР. Часть 2