Возник такой вопрос, а где что можно почитать про масштабируемость, в плане того, как писать приложение, чтобы в случае если нагрузка станет невыносимой, можно было просто подключить ещё один сервер, и получить повышение быстродействия? И так каждый раз, когда нагрузка опять станет большой. Я понимаю что для начала можно разнести БД и приложение, но дальше ведь придётся и количество серверов БД и количество серверов приложения увеличивать. Имеется в виду не случай JEE, там то вроде бы проблем с этим нет. Вот например "Счастливый фермер" вконтакте, там же дохренища пользователей, как сервера справляются? Я кое-что читал на эту тему, но конкретных решений пока не видел, не считая полукорявого Project Darkstar от Sun, который Oracle прикрыл после покупки Sun'а, и он теперь развивается независимо, как Red Dwarf server, из чего я делаю вывод, что он никогда уже не будет в стадии релиза.

У меня есть разве что одна идея. Почитать Таненбаума "Распределенные системы", поизучать работу с сетью например на Java, а там уже и вопросы отпадут я думаю. Опять же в случае нереалтайм миров, как WoW например, а казуалок, можно сильно не заморачиваться, и сделать приложение, которое при обращении клиента, будет указывать ему наименее загруженный из серверов, с которым он и будет потом работать.

Relic HunterXDiaBLo,

В каком плане интересуемя? Прикладном, теоретическом?

В прикладном, все выглядит довольно не сложно: Виртуальный Сервер, он-же раутер (софтверный иил хардварный) (один, лучше два) распределитель нагрузки и фейл-овер, пул ресурсов - физических серверов (много), разделяемое хранилище данных (БД) или кластер его представлюящий в трех-слойном варианте.

Вообще говоря к программированию это имеет мало отношения. Больше - к администрированию. У каждого вендора свой велосипед. Например, Redhat читать LVS (Linux Virtual Server Pirahnia) Administration.
Ну как же мало? Я как раз и интересуюсь как сделать приложение хорошо масштабируемым. Что для этого нужно сделать с точки зрения программиста. Хотя конечно до кучи не мешает и точка зрения админа. Вообще, спасибо конечно, примерно так я и представлял, хотя я так понял есть много разных вариантов масштабирования.

ZyK_BotaNСтиль написания важен. Например модель акторов можно изучить. Для этого хорошо подойдет Erlang. Баловаться с масштабируемостю можно запуская ноды на единственной машине.
Ерланг? Гляну обязательно. Спасибо.

schwaГде-то в рунете ходила статья о применении cloud computing в mmo.
Если не изменяет память, то кто-то доклад по этому поводу на КРИ делал в этом году (и статья эта от автора/ов доклада). На она dtf.ru вроде есть.
Может быть подтолкнет к мыслям каким.
Можно еще полистать топики на gamedev.net/gamedev.ru в соответствующих разделах.
Да, что-то я давно на эти сайты не заглядывал, посмотрю, спасибо.

ZyK_BotaNRelic HunterXDiaBLo,

В каком плане интересуемя? Прикладном, теоретическом?

В прикладном, все выглядит довольно не сложно: Виртуальный Сервер, он-же раутер (софтверный иил хардварный) (один, лучше два) распределитель нагрузки и фейл-овер, пул ресурсов - физических серверов (много), разделяемое хранилище данных (БД) или кластер его представлюящий в трех-слойном варианте.

Вообще говоря к программированию это имеет мало отношения. Больше - к администрированию. У каждого вендора свой велосипед. Например, Redhat читать LVS (Linux Virtual Server Pirahnia) Administration.

от самой программы, которую нужно развернуть ничего не зависит?
Если бы было так, я бы вопросов не задавал :) Я тоже удивился этому утверждению :)