Загрузка сервера и масштабируемость для массовой загрузки - PullRequest
3 голосов
/ 14 августа 2011

Я хочу загрузить миллионы аудиозаписей пользователями на мой сервер.Текущее приложение предназначено для передачи содержимого, его перекодировки и, наконец, отправки по FTP на серверы хранения.Я хочу знать:

  1. Может ли сервер приложений нести огромные задачи для пользователя, такие как комментирование, загрузка, транскодирование после масштабирования на большее количество серверов (чтобы нести нагрузку веб-приложения)?

  2. Если ответ на поставленный выше вопрос - «да», то является ли это правильным и наилучшим подходом?Поскольку хорошей архитектурой будет отправка транскодирования на серверы хранения, дождитесь завершения задания и отправки ответа на сервер приложений, но в то же время это будет более сложным и ненадежным.

  3. Что такоеобщий метод для веб-сайтов такого типа?

  4. Если я отправляю задание загрузки и перекодирования на серверы хранения, совместимо ли оно с технологиями корпоративного хранения в долгосрочной масштабируемости?

5 - Текущее приложение основано на PHP.Можно ли переместить папку tmp на другие серверы, чтобы преодолеть перегрузку при загрузке?

Спасибо за ответ, за вопрос № 5 к папке tmp. Я имею в виду папку tmp в Apache.Я знаю, что все загруженные файлы перед переходом к конечному месту хранения (например, серверы хранения или любое решение) хранятся в папке tmp apache.Мне было интересно, если это правило для Apache, и все загруженные файлы должны быть расположены в первую очередь на сервере приложений, так как я могу контролировать, масштабировать и перенаправлять эту огромную нагрузку на временное хранилище или сервер?Я имею в виду сервер или решение для хранения в качестве tmp-папки appche, чтобы просто быть гостем загруженных файлов перед отправкой в ​​последние места хранения.Я изучил и спроектировал все, что касается масштабирования базы данных, хранилищ, балансировки нагрузки, memcache и т. Д., Но это один из моих нерешенных вопросов.Где новые файлы, поступившие пользователями на главный сервер, будут размещены в масштабном архитекторе?И какое общее решение для этого?(В одном коробочном решении все файлы будут временными в каталоге tmp appche, но для большого количества содержимого и в масштабируемой системе?).Привет

Ответы [ 2 ]

4 голосов
/ 15 августа 2011

Возможно, вы захотите взглянуть на архитектуру Viddler: http://highscalability.com/blog/2011/5/10/viddler-architecture-7-million-embeds-a-day-and-1500-reqsec.html

4 голосов
/ 15 августа 2011

Поскольку я не чувствую, что могу ответить на этот вопрос (я хотел добавить комментарий, но мой текст был слишком длинным), некоторые мысли:

  1. Если вы создаете такую ​​большую систему (как это звучит), у вас должны быть некоторые тесты производительности, чтобы увидеть, сколько одновременных подключений / загрузок, ... независимо от того, что ваша архитектура может обрабатывать. Как я всегда говорю: если вы этого не знаете: «нет, не может».

  2. Я думаю, что лучший способ справиться с большой нагрузкой (это: много загрузок, требующих много заблокированных потоков от appserver (-> это означает, что я бы не использовал Appserver для обработки файловых загрузок) Выполните все ваши тяжелые операции (транскодирование) в асинхронном режиме (например, поставьте в очередь загруженные файлы, обработайте их впоследствии). В любом случае сервер Applicaiton не должен ждать ответа от системы транскодирования -> просто сообщить пользователю, что его файл будет обработан и отправит ему сообщение (или что-то еще), когда он закончится. Для этого вы можете использовать что-то вроде gearman.

  3. Я бы искал существующие архитектуры, которые также должны обрабатывать большое количество загрузок / преобразований (например, flickr), просто перейдите на слайдшер и найдите «flickr» или «масштабируемая веб-архитектура»

  4. Я не очень понимаю это - но я бы использовал Серверы на основе их задач (например, Сервер Приложений, Серверы баз данных, Транскондинговые серверы, Хранилище, ...) - каждый сервер должен делать то, что он умеет лучше всего .

  5. Боюсь, я не знаю, о чем вы говорите, когда говорите папку tmp.

Удачи

...