Как избежать превращения веб-сервера в узкое место с кассандрой?

Question

Как избежать превращения веб-сервера в узкое место с кассандрой?

1

Я новичок в Кассандре, так что медведь со мной.

Итак, я строю поисковую систему, используя Cassandra как db. Я взаимодействую с ним через Пикасса.

Теперь я хочу вывести ответ Cassandra на веб-страницу, и пользователь отправил запрос.

Я знаю такие инструменты, как django, fastCGI, SCGI и т.д., Чтобы позволить python взаимодействовать с Интернетом. Однако как запустить сценарий python на веб-сервере, не превращая этот сервер в единую точку сбоя (т.е. Если этот сервер умирает, чем система недоступна для пользователя) - и поэтому отрицает одну цель Cassandra?

rikAtee 21 авг. 2011, в 22:16

Источник

0

Вы действительно имеете в виду узкое место здесь? «Если этот сервер делает, то система не доступна» описывает одну точку отказа
D.Shawley 21 авг. 2011, в 20:03

Теги:

python

web-applications

2 ответа

0

Масштабируемые интернет-архитектуры Theo Schlossnagle охватывают балансировку нагрузки и многое другое. Настоятельно рекомендуется.

jbellis 22 авг. 2011, в 12:18

Ещё вопросы

Вы действительно имеете в виду узкое место здесь? «Если этот сервер делает, то система не доступна» описывает одну точку отказа

tom.wilkie · Accepted Answer · 2011-08-21T19-18-00.000Z

Я видел эту проблему раньше - иногда людям требуется гораздо больше мощности процессора и пропускной способности для генерации и обслуживания некоторых генерируемых сервером HTML и изображений, чем для фактического запроса в Cassandra. Для одного клиента это было в 10 раз больше серверов, обслуживающих переднюю часть веб-сайта, чем в их кластере Cassandra.

Вам нужно будет как-то балансировать баланс между этими серверами переднего плана - исследовать запуск haproxy на нескольких специализированных машинах. Его быстро и легко настраивать, а также легко переконфигурировать при изменении настроек (в отличие от DNS, который может занять несколько дней для распространения изменений). Я думаю, вы также можете настроить nginx на то же самое. Если вы сохраняете информацию о сеансе на своих серверах переднего конца, каждому клиенту необходимо будет перейти на один и тот же сервер для каждого запроса - это называется "постоянством сеанса" и может быть достигнуто путем хэширования IP-адреса клиента переднего сервера. Haproxy сделает это за вас.

Однако этот подход снова создаст SPOF в вашей конфигурации (сервер haproxy) - вы должны запустить более одного и потенциально иметь горячий режим ожидания. Наконец, вам нужно будет как-то балансировать нагрузку между вашими гапроксиями - мы обычно используем для этого круглый robin DNS, поскольку узлы, работающие с haproxy, редко меняются.

Преимущество этой системы заключается в том, что вы можете легко увеличить (и уменьшить) количество интерфейсных серверов без изменения вашего DNS. Вы можете немного узнать о настройке, о которой я говорю, по адресу: http://www.acunu.com/blogs/andy-ormsby/using-cassandra-acunu-power-britains-got-talent/

Благодарю. Я посмотрю то, что ты сказал.