Прежде чем озвучить вопрос хочу попросить: пожалуйста, отписывайтесь только те, кто шарит в PHP+MYSQL+Nginx и имеет представление о том каким должен быть высоконагруженный сервис. Просто чтобы было меньше лишних споров. Собственно вопрос довольно размытый: я недавно совершал попытки сделать файлообменник, получилось симпатично и даже работало, но чувствую что моих дилетантских знаний крайне мало для того чтобы построить по-настоящему серьезный сервис. Собственно, я даже не представляю объем материала, который мне следует изучить, чтобы не натолкнуться хотя бы на самые банальные подводные камни. Пожалуйста, кто имеет опыт, нарисуйте (в буквальном смысле) пожалуйста схему, по которой стоит строить РЕАЛЬНО_СЕРЬЕЗНЫЙ файлообменник. Вводные данные: 1. обязательно буду делать возможность масштабирования, будут серверы разбросаны по миру или находиться в одном ДЦ - еще не знаю (подскажите кстати кто ЗА и ПРОТИВ) 2. собираюсь делать загрузку файлов через сервер-балансировщик. Но совершенно не понимаю, каким образом он должен раскидывать файлы по серверам-storage. Ведь если человек сначала загрузил файл на балансировщик и получит ссылку, то ему придется ждать пока этот файл с балансера перекачается на storage-сервер? Или можно делать это на лету? 3. самое стремное: база данных. Можно ли для ФО хранить базу данных (с инфой о всех файлах/пользователях) на одном сервере или придется ее как-то крамсать на куски? Просто мне один знакомый с пеной у рта втирал что нужно делать "расслоение бд". 4. Nginx - стыдно сказать, но для меня это еще не паханое поле. Его можно будет повесить поверх апача, или при таких нагрузках (как я слышал) лучше обходиться вообще без апача а с чем-то другим делать связку? Я сам слабо понимаю что щас сказал, пожалуйста введите меня в курс) 5. Не смейтесь над моей наивностью, но все это я планирую делать в расчете на посещаемость ~150-200к уников в сутки. 6. и вдогонку: меня весьма опечалил факт закрытия megaupload. Насколько я слышал, у них и домен в зоне COM и сервера в нидерландах были -> как же до них добрались-таки? Надеюсь, данная тема (если получит достойное развитие) будет полезна всем ачатовцам, если решусь взяться за дело - буду сюда выкладывать этапы развития и делиться приобретенным опытом.
Это называется кластер. Однозначно да. Пусть балансировщик при запросе резервирует на главном хосте адресное пространство, в случае если успешно загружено - выдает зарезервированную сылку, в случае фейла - пусть удаляет резерв. Здесь нужен спец в другой области, но могу сказать, что распределять мускуль ( вы же будете пользоваться мускулем?) придется по кластеру - база юзверей в одном месте, база хранилища а в другом, хранилища б в третьем. Ну или по типу данных. Как промежуточный прокси. Как кэширующий сервер. Как веб-сервер. При любом раскладе работает на высоте, но конфигурация требует определенных интеллектуальных ресурсов. Если будете позиционироваться как "новый мегааплод" посещаемость будет х100. Значит есть лазейки в законодательстве США/Нидерландов, позволяющие спец-службам закрывать гигантов. А вообще мне кажется основатель решил кинуть своих вышестоящих покровителей.
2. -------------------------------------------------------------------------------------------------- Пусть балансировщик при запросе резервирует на главном хосте адресное пространство, в случае если успешно загружено - выдает зарезервированную сылку, в случае фейла - пусть удаляет резерв. -------------------------------------------------------------------------------------------------- На главном хосте...адресное пространство...или я дурак или вы неправильно поняли вопрос. Меня интересует следующее: юзер загружает файл и сразу получает ссылку. Файл загружается я так понимаю сначала на балансер, а затем копируется на storage? Получается пока файл не перекопируется, то ссылка юзверя работать не будет? Или есть какая-то возможность залить файл сразу на storage "на лету", чтобы балансер работал как что-то вроде прокси грубо говоря? В любом случае я понятия не имею даже по какому протоколу лучше пересылать файл между серверами. 3. -------------------------------------------------------------------------------------------------- Здесь нужен спец в другой области, но могу сказать, что распределять мускуль ( вы же будете пользоваться мускулем?) придется по кластеру - база юзверей в одном месте, база хранилища а в другом, хранилища б в третьем. Ну или по типу данных. -------------------------------------------------------------------------------------------------- тогда все равно придется сделать одну огроменную таблицу, в которой для каждого файла будет указано, на каком хосте инфу о нем искать по типам файлов разделять на серверы не хочется, ибо будет неравномерная нагрузка, хочу чтоб на всех серверах одинаковая "каша" хранилась) тем более если сервер для "видео" например закончится, придется добавлять еще один сервер конкретно для видео. со своими параметрами. движок мудреный получится уж. Движок-то я написать смогу допустим, но сам потом в нем не разберусь))) А уж если делать поиск по файлам, тогда уж совсем попа получается. Это надо будет как-то соединяться к разным БД с разных хостов, объединять результаты и как-то их еще сортировать... я чето в осадок выпадаю, бред какой-то. Если взять посещаемость 200к в сутки, и прикинуть что каждый 5й юзер чето загружает, а файл будет в среднем храниться 1 месяц то получается что среднее кол-во файлов на серверах будет примерно равно 200000/5 * 30 = 1 200 000. Неужели мускул не справится с лямом не слишком сложных записей? ЗЫ если у кого еще будут предложения/комментарии - буду рад слышать Кстати, что там с memcached? У меня один знакомый во все горло орет что без него никуда, а второй фыркает что файлообменнику такая штука как козе баян.
Apeckou вообще говоря - все зависит от таких критериев как доступность, время простоя, время реакции, целевая аудитория 1) Подробнее распишу во 2 пункте. Вообще - все яйца в одну корзину класть всяко не стоит. ДЦ имеют свойство гореть вместе со всеми серверами внутри, отключаться от интернетов и прочее. Для построения высокодоступного сервиса необходимо иметь сервера (как сторадж, так и веб) в разных ДЦ/странах 2) Бывают разные способы балансировки. Простейшие начиная сверху: a) ДНС балансировщик, который выдает разный набор IP-адресов веб-морд, на которые может зайти пользователь б) пользователь получив IP адрес подключается к front-end веб-серверу (лучше - nginx, средне - lighttpd) дальше этот веб-сервер отправляет запрос на бек-енд сервер (spawn-fcgi, php-fpm, php-fcgi, apache+тоже самое, либо apache+mod_php - это совсем плохо, но бывает, к сожалению, необходимо), либо на кеширующий сервер (memcached). Причем - бекенд может быть расположен там же где фронтенд - средне, либо в локальной сети с фронтендом на отдельном физическом сервере. Наконец пользователь получает веб-морду г) На веб морде расположена всякая статистика + форма загрузки. В форме загрузки тоже можно балансировать - пункт А + выбор сторадж сервера исходя из данных в БД (например оцениваем нагрузку на каждый сторадж, плюс расстояние от пользователя до стораджа и выдаем форму на загрузку к нужному серверу). Хорошо - отправлять данные на сторадж и он уже уведомит БД о загрузке. Средне - отправлять файл на фронт-енд балансировщик, который отправит куда нужно, но это уже удвоенный траф и нагрузка на балансировочный сервер д) веб-сервер хранит данные не у себя, а в NAS или даже SAN хранилищах 3) Опять таки - смотря какая цель. По хорошему - база должна быть реплицирована (google:репликация mysql) для каждого фронт-енд сервера (почему не для каждого бек-енд - это слишком хорошо и слишком дорого, а одной реплики на фронтенд - должно хватать, в случае падения БД - просто отправляем пользователя на другой фронт-енд). Каждая такая реплика может представлять собой кластер БД (google: mysql cluster) с балансировкой как у веб-сервера. Но в любом случае строго - один ДЦ как минимум одна реплика БД рядом. 4) nginx - классный, этим бы стоило закончить, но продолжу. Nginx - быстрый, современный, стабильный. Как фронт-сервер - прекрасен. Умеет работать по разным протоколам с бек-ендами, кеш-серверами и прочим. Гибок. Плюс см. пункт 2 На 80 порт лучше всего ставить его. Далее проксировать запросы на бекенды/дергать данные из memcached. Apache как бек-енд пригодится только за свои модули. Типа mod_rewrite, mod_security и прочих. Если вы настроите nginx правильно - то апач вам не нужен. Он слишком тяжел, неповоротлив и любит кушать память. 5) без коментариев, но технически это не нагрузка 6) смиритесь: если нужно - вас найдут и покарают. Официально - в очень большом количестве стран. Неофициально - везде. Вопрос только в том, насколько вы станете нужны. Страны EU и USSR в этом плане наиболее вредны. В EU - ловят, в USSR - надо делиться. миллион - копейки. Для хранения - точно. Для поиска по ним - нужна правильная индексация и профилирование запросов. Насчет memcached - он однозначно нужен для веб-морд (возможно не сразу), для файлов - почти бесполезен. ПХП - очень медленный, даже с ухищрениями типа eAccelerator и Hip-Hop. Чтобы выдержать большую нагрузку - нужно хранить сгенерированные страницы в кэше. Плюс загуглите собственно про eAccelerator и Hip-Hop. Подумайте над правильной организацией БД и, возможно, использование noSql движков. Либо не тривиальный MySql, а например PostgreSql за функциональность, либо больших братьев - Oracle, IBM DB2, MSSQL.
Гугли Amazon S3. Всю работу по кластеризации данных Amazon берет на себя. Не думаю что БД файлообменника будет таких масштабов, что на одном сервере не разместить. Как известно сервер под управлением Apache не является оптимальным решением для создания высокопосещаемых проектов. Поэтому при оптимизации серверного ПО очень часто прибегают к установке связки из легкого кеширующего сервера Nginx как фронтсервера и Apache как бэксервера. Данная связка позволяет существенно сократить расход памяти и увеличить быстродействие работы сервера. Однако существует еще более производительное решение, и это установка сервера Nginx как единственного сервера, при этом Apache полностью убирается из системы. Могу дать бесплатный мастер-класс по монетизации без рефссылок
