Я создаю веб-приложение для сокращения URL-адресов и хотел бы узнать, какая архитектура лучше всего подойдет для его реализации, чтобы обеспечить быстрый и надежный сервис.
Я хотел бы иметь две отдельные услуги на разных машинах.
- На первой машине будет само приложение с Apache, Nginx, чем угодно.
- Второй будет содержать базу данных.
- Третий будет отвечать за обработку петиций с короткими URL-адресами.
ОБНОВЛЯТЬ:
Сервис вообще не является сокращателем URL. Просто так было проще объяснить.
Мне нужна только одна машина, которая получает один http-запрос и вставляет запись в базу данных. И мне нужна эта машина, чтобы выполнять эту простую задачу очень эффективным способом. Система будет работать на Linux (я пока не знаю дистрибутив), и я полностью открыт для любого языка или технологии. Я думал использовать Yaws, Tornado или Snap для этой службы, но я пока не знаю, и пришло время спланировать архитектуру для этой части. База данных будет построена на Hadoop.
Для третьей машины мне нужно просто принимать один вид http-петиции (GET www.domain.com/shorturl), но она должна делать это очень быстро и достаточно стабильно.
решение1
Вы действительно думаете, что нужен еще один сокращатель URL? Есть простоочень многоиз них вокруг... если только вам случайно не удалось получить очень короткое и подходящее доменное имя, я просто не думаю, что ваш сайт будет замечен кем-то. Просто мои два цента, конечно.
Ну, а теперь к технической части:
- На каком языке вы собираетесь писать заявление?
- На какой операционной системе вы планируете его запустить?
- Будете ли вы использовать бесплатное или коммерческое программное обеспечение?
Трудно ответить на ваш вопрос, даже не зная этого.
Единственный ответ, который может иметь здесь смысл, это "избегайте Java как чумы". Сервер приложений Java - это излишество для многих приложений, и он, несомненно, будет излишеством для такого простого.
Я бы здесь выбрал Linux/Apache/MySQL/PHP...еслиКонечно, я мог бы придумать любую вескую причину, чтобы начать этот проект.
Редактировать:
Хорошо, теперь это имеет немного больше смысла; но предложение начать как можно проще изатембеспокойство о масштабировании все еще актуально. Если ваше приложение действительно настолько простое, любая приличная комбинация веб-сервера/языка/базы данных должна быть способна обрабатыватьмногозапросов в секунду на современном оборудовании (но я все равно настоятельно рекомендую избегать Java).
Если производительность имеет первостепенное значение, я бы выбрал CGI-приложение, написанное на языке C;чтобудет самым быстрым возможным решением, на порядки быстрее, чем любой интерпретируемый или виртуальный язык; и выполнение им простых операций INSERT и SELECT в базе данных не должно быть проблемой.таксложно. Но я думаю, что LAMP более чем достаточно для ваших нужд... они на самом деле работаютФейсбукна нем, вы знаете?
решение2
Они просто записывают данные или также отправляют что-то интересное? Если они просто регистрируют, то просто используйте apache и передавайте логи apache в hadoop. Если они должны возвращать какие-то данные, то мне вообще не понятно, как они получают возвращаемые данные.
Тем не менее, Apache, настроенный на возврат статического файла по любому запросу, работает чертовски быстро.
решение3
Во-первых, я знаю, вы сказали, что это не URL-сокращенер, но если это что-то похожее, то СУРБД — ужасный способ хранения этих данных; поскольку между любыми двумя частями данных нет реальной связи, вам нужен плоский механизм хранения. Рассмотрите Mongo (или Couch, в зависимости от вашего фактического пространства решений).
Что касается вашего решения, будьте осторожныпреждевременная оптимизация. Есть много способов сойти с ума от этого; раз уж вы спросили, самое безумное, что я могу придумать навскидку, это запустить Varnish, написать все свои страницы в VCL и подключить его к memcache на бэкэнде для хранения и извлечения соответствующих данных. Но реалистично, эточушьбезумие, если только вы не находитесь под явно абсурдной нагрузкой.