Pull to refresh

Comments 6

К вопросу архитектуры, думаю, нужно подходить изначально из требований. Например, обработка асинхронных (как и сихронных) сообщений накладывает свои ограничения, например, по скорости, памяти, менеджменту соединений и т.п. Нужно исходить из конкретных задач. Например, у нас на проекте изначально MQ (WebSphere) покрывала все требования (30'000 сообщений в час). Но с увеличением требований по скорости обработки сообщений 300'000 сообщений в час нужно уже пересматривать архитектуру: где-то еще распараллелить, а где-то убрать отслыку сообщения и работать напрямую; где-то использовать вместо MQ естественный общий ресурс — базу данных; отказаться от персистентности сообщений и т.д. Какую пропускную способность Вы предполагаете на игровом сервере? Насколько затратным будет выполнение одного сообщения?
Знаете, еще не прочитал Вашу вторую статью, но читал первую. Для решения задач с высокой нагрузкой, а именоо на это вы и нацеливаете сервис думаю Erlang для Вас наиболее оптимальный выбор.
да я тоже думаю, но тута еще стоит подумать, как я буду использовать функционал… может стоит на некоторые задачи выделить отдельные сервера… или вовсе обойтись… в общем пока это исследование различных архитектур. а Ерланг сильно уже иная технология для меня :)
На highload достаточно интересно рассказывали про PgQ (http://pgfoundry.org/projects/skytools/) ребята из скапа, как средство для масштабирования мне понравилось. Но я больше на мускуле специализируюсь поэтому реально в работе не применял.
единственное чего не умеет ezComponents Это хранить саму очередь а отправлять сообщения между серверами это помойму вполне легко сделать на базе ezComponents, сама очередь из себя будет представлять проосто последовательность хттп запросов к другому серверу если это межсерверное взаимодействие сделать можно по средствам RPC
да, вы правы. ну там не столько очередь же сообщений, сколько стек функций, поэтому там и не надо персистентности. Но я уже подумываю сделать подобную систему
Sign up to leave a comment.

Articles