Архитектура Интернет магазина

[seva2]

Архитектура Интернет магазина

Такой вопрос, задумался по покупке резервного сервера БД, но как организовывать лучше

а) Просто Кластер
б) Репликацию и разделение процесов на уровне кода

Реально ли сделать репликацию определных таблиц в направлении
БД1->Бд2
А других в обратном
БД2->БД1

То есть например морда сайта будет крутить на БД1, а заказы писаться и обрабатыватсья на БД2.

Поясню почему так хочу:
а) Предположим досят морду сайта, падает mysql, падает работа и менеджеров и сайта (А если бы БД были разделены, то работали хотя бы менеджеры)

Вообще, хотелось бы услышать мнение кто за какое разделение.

Сам сервер текущий с нагрузкой спарвляется без проблем.
Но если как то нагруз, дос начинается, то все, работа встает вся.

 

[tz-lom]

если хотите держать резервный сервер БД на случай падения основного то настраиваете master->slave (смотря что за данные можно и асинхронную) реплику и организуете переключение на slave при падении мастера
но это не спасёт от возросшей нагрузки т.к. от перегрузки сначала падёт мастер,потом реплика

если же пользоваться репликой правильно,то от ДОСа будут падать оба сервера,просто набо будет сильнее ДОСить

репликацию в 2х направлениях наверное возможно,но я не знаю как,вообще такая схема весьма странная

на вашем месте я бы предпочёл шардинг,но прийдётся немного менять код

 

[Dovg]

>а) Предположим досят морду сайта
Есть мнение, что от доса морды сайта база не должна падать. Морда же может почти целиком в кеше оседать.

 

[seva2]

GEOIP
По ним берутсья адреса офисов и телефонов.

-~{}~ 20.07.10 16:34:

У нас два фронт сервера
front1
front2

Между ними нагрузка распределяется на уровне nginx тут как таковых
проблем нет. у падает работает другой

А вот БД сервер у нас один. И если он падает, падает работа всего

Сайта основного
CRM системы и всех менеджеров


Пришла идея, создать master-> slave репликацию

Сайт работает на slave
CRM на master

Но возникает проблема, что предположим master упал. Сайт то будет
работать, но запись заказов идти не будет.
И как решить данную проблему, пока не представляем


Вот последний абзац, как решить не ясно

 

[dimagolov]

непонятно, почему должна падать БД. она ведь изолирована от внешнего мира несколькими уровнями. если серверу БД не хватает производительности на фоне нормального функционирования сервера приложения/веб сервера, то, возможно, нужно или оптимизировать БД и работу с ней или масштабировать железо, на котором живет БД, или повышать изоляцию БД (чтобы простые запросы к веб-серверу не создавали избыточную нагрузку на БД, но это как часть оптимизации)

-~{}~ 20.07.10 10:16:

Но если как то нагруз, дос начинается, то все, работа встает вся.

борьба с DoS никакого отношения к БД не имеет. начните с того, что физически отделите потенциально "опускаемые" элементы от жизненно важной инфраструктуры. решений может быть множество, банально, сервер веб-морды может быть подключен к серверу БД или через фаервол, который будет ограничивать пропускную способность (шейпить трафик) или тупо через 10-мегабитный хаб в полудуплексе, что ограничит пропускную способность на уровне 5-7Мбит/с

 

[fixxxer]

MySQL просто так не может падать

Если не справляется с нагрузкой, довольно надолго (для интернет магазина - очень надолго, если у вас там конечно не амазон) хватит классического master -> slaves, где чтения идут со слейвов. При этом запись логов, статистики и прочий OLAP конечно надо вынести вообще на отдельный инстанс. И при написании кода не забывать читать с мастера сразу после записи на него - классическая проблема недошедшей реплики.

Вопрос резервирования (ухода от Single Point Of Failure) мало связан с масштабированием, но подход здесь в принципе тот же, просто в случае если навернулся мастер (например, отказ оборудования) слейв превращается... превращается... превращается в мастер. Это настолько редкая ситуация что я бы даже не стал запариваться с ее автоматизацией - тут риск сбоя автоматизации выше. Мониторинг и ручками.

Помимо прочего, данные по товарам (которые меняются, очевидно, не каждые три секунды) я бы вообще кэшировал на фронтах. Даже не в memcached, а в акселератор/shared memory/статику. В идеале надо добиваться ситуации когда для просмотра каталога товаров и поиска по ним (короче - для всего, что пользователь делает пока не начал собственно что-то покупать) все данные с вероятностью в процентов 90 закэшированны на фронте.

А от ДДОСа надо отбиваться на ином уровне. Если магаз доходный, я бы просто воспользовался услугами соответствующих компаний (правда, в России не знаю кто это делает качественно; американскими staminus в принципе доволен, хоть и панелька у них кривовата). Ну, точнее, скажем так, фронты должны выдерживать раздачу сотки мегабит, а дальше уже проблема так или иначе на этом уровне нерешаема %)

 

[seva2]

Решили делать так

master -> slave

Доводы
а) Расширяемость легкая (если делать master-master то в кольце при выпадении одного выворот кишков)
б) Проблему с insert решаем и ищем систему автоматизации:
Если падает master, система выбирает любьбой slave делает его master все слейвы перенастраивает на подключение к нему
в) select приложение какое то рулит, в зхависимости от нагрузки или по коэффициентам рапсределния запросов


По поводу пункта б и в, есть рекомендации какие использовать приложения? Mysql proxy? Mysql mmm ? можно что то платное

 

[Активист]

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

Я как-то несколько раз организовывал HA класстеры, ибо железо подводило (в плане выхода из строя оборудования, а не баланса нагрузки), а нужно было добиться 100% аптайма.

А главное...
Смысл Master -> Master в классическом интернет магазине для балансировки нагрузки? "Защиты от DDOS", ибо в классической схеме работы интернет магазина (если архитектура приложения, конечно верная) - 99.9% - запросы типа SELECT, 0.1% - UPDATE + INSERT - статистика + счетчики и работа контенщиков .

> Если падает master, система выбирает любьбой slave делает
> его master все слейвы перенастраивает на подключение к нему
> в) select приложение какое то рулит, в зхависимости
> от нагрузки или по коэффициентам рапсределния запросов
Это какой-то костыль, есть встроенный в MySQL режим работы - кластер, вот его и нужно использовать, имхо.