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