Highload: как подготовить интернет-магазин к перегрузкам

Тёмная пятница — сутки, с которого в Соединенных Штатах традиционно стартует сезон рождественских распродаж. После этого распродажи запускаются в вебмагазинах (так называемый киберпонедельник). В Российской Федерации тёмная пятница проводится с 6-го декабря 2013 года.

Приблизительно за 14 дней до той самой пятницы к нам пришел клиент. Ну другими словами не совсем вот так “пришел”, из ниоткуда, — мы занимались развитием его вебмагазина с 2012-го. Задача в этом случае была: подготовить магазин к распродажам, а это значит — к перегрузкам.

Данные

В начале подготовки к тёмной пятнице вебмагазин — это:

  • Ветхая версия Битрикса с изнасилованным ядром (досталась по наследству).

  • Три сервера: на одном крутится сам сайт, на втором — база данных MySQL, третий — до тех пор пока вольный.

  • Более 66 000 неповторимых пользователей в день. Более 350 000 обращений в сутки.

Задача

Отыскать ответ, которое бы разрешило вебмагазину “не падать” под напором пользователей (по сути, сделать high-load проект). Сделать скоро, поскольку распродажи уже беспощадно близко. Как окажется достигнуть цели — должно было стать ясно в тёмную пятницу.

По задумке, в случае если магазин выдержит такую “первую волну”, то в и новый год также неприятностей не будет.

Ответ

По сути, мы будем заниматься оптимизацией скорости работы сайта. Самое действенное ответ при таких условиях — переписать код. Но это для клиента через чур радикально, а так как на носу распродажи — по большому счету не приемлемо. Ок, выбираем репликацию баз данных MySQL.

Не лучшее решение, что многократно обсуждалось на форумах, но — посмотрим, как оно себя продемонстрирует.

Денис, ведущий разработчик: обычная задача применения репликации при работе с базами данных — распределение нагрузки и повышение отказоустойчивости при чтении данных. Архитектура такая (минимальная комплектация): берутся два сервера, один назначается Master, второй — Slave. На сайт заходит пользователь, оформляет заказ, отправляет его на сервер. В базе данных на Master e создается запись о его заказе, по окончании чего дублируется на Slave.

При отказа первого сервера, база данных постоянно остаётся на втором, на него возможно скоро переключиться. Так увеличивается отказоустойчивость. При обращении сайта к базе данных чтение может производиться как с первого, так и со второго сервера — так распределяется нагрузка.

Но отечественная задача заключалась в другом — в частности, нам необходимо было распределить нагрузку не только на чтение, но и на запись.

Итак, что делаем:

  1. Создаем два Master-сервера.

  2. Настраиваем репликацию. Созданная запись на одном из серверов дублируется на другой.

  3. Модифицируем ядро Битрикса так, что конкретная запись создается с возможностью 0,5 на первом сервере и с такой же возможностью — на втором.

Highload: как подготовить интернет-магазин к перегрузкам

В новом Битриксе имеется модуль кластера. И в данной обстановке нам было бы весьма комфортно применять как раз его. Но Битрикс ветхий и таковой возможности у него нет.

Исходя из этого нам было нужно в поле собрать некое подобие данного модуля, пропатчив ядро Битрикса.

Предположительные пользы: нагрузка на любой сервер понижается в два раза, в то время, когда пользователи отправляют заявку с сайта, и кроме этого понижается в два раза, в то время, когда сайт обращается к созданным записям в базе данных. Это должно предохранить базу от “падений” во время громадного наплыва клиентов.

Но не всё так радужно. У нас имеется минимум три подводных камня.

Екатерина, менеджер проекта: Денис давал не самые оптимистичные прогнозы: неприятности имели возможность появиться из-за асинхронной передачи данных — а это, первым делом, дублированние записей. Кроме этого большое количество потенциальных неприятностей крылось и в ветхой, многократно кастомизированной CMS Битрикса. И, наконец, сайт нештатно интегрирован с 1С (к примеру, кастомизирован компонент, несущий ответственность за скидки), что также накладывало пара изюминок на настройки и архитектуру серверов.

Про решения и коллизии

О стандартных процедурах. У нас два сервера, любой из которых вычисляет себя “главным”. Дабы информацию о заказе равномерно распределялись на тот и второй сервер, каждой записи присваивается собственный ID и, скажем, все записи с четными ID попадают на первый сервер, все с нечетными — на второй.

По окончании чего синхронизируются между собой. Без таковой настройки архитектура Master-Master не работает совсем.

Сейчас об увлекательном.

Неприятность 1

Битрикс ведет статистику по визитёрам, создавая для нее таблицы. В качестве Primary Key (ключа для неповторимой идентификации данных таблицы) употребляется дата. Сейчас о том, чем это угрожает. К примеру, на сайт в один момент заходят два первых визитёра, Бивис и Баттхед, 1-го января 2014 года. Если они наряду с этим попадают на различные серверы — то на них создаются две записи с одним Primary Key. По окончании чего эти пробуют реплицироваться.

Но ключ неимеетвозможности повторяться — и база при таких условиях выдаст неточность. Совокупность репликации остановится.

Ответ 1

Мы решили что возможно пожертвовать 1 человеком из таблицы статистики и настроили особый параметр в конфигурации серверов, что игнорирует неточность о дубликации Primary Key для данных таблиц, “выбрасывает” Бивиса (либо Баттхеда) из статистики, но притом все последующие визитёры учитываются полностью — и записываются в таблицу. При посещаемости в шестьдесят тысяч уников в сутки — жертва не самая громадная.

Неприятность 2

Двойная отправка писем. Так как сайт посещаемый, то по окончании того, как заказ оформлен и послан пользователем, админу приходит письмо-уведомление. Но приходит не сходу, а по окончании того, как таких писем накопится достаточное количество, они запишутся в базу и когда сервер прекратит трудиться с пользователем, “включится” агент, что заберёт организованную таблицу с письмами и пошлёт на админскую почту.

По причине того, что эти забираются агентом не сходу, они успевают за это время продублироваться на второй сервер — в итоге может оказаться, что агенты будут запущены для двух серверов, и для рассылки писем будут использованы две однообразные базы. Итог — дубли писем.

Ответ 2

Простое ответ: сделали так, что агент при работе применяет лишь один MySQL-сервер.

Неприятность 3

Сайт интегрирован с 1С. Общение между 1С и сайтом происходит не мгновенно, а за пара операций. Грубо говоря: 1С отправляет запрос в Битрикс, Битрикс формирует таблицу на сервере MySQL и сохраняет в нее информацию о заказах, 1С забирает эти, 1С “говорит” Битриксу, что всё готово и таблицу возможно удалить.

Так как у нас чередуются два сервера для понижения нагрузки, получается, что таблица создается на одном сервере, а 1С на следующих шагах может обратиться к второму, где таблица еще не успела реплицироваться. И это еще не всё: в случае если на шаге удаления таблицы Битрикс обратится к серверу, на котором таблица еще не создана, то таблица практически не будет удалена. Последующие попытки создать новую таблицу о заказах будут приводить к неточности.

Заказы не будут выгружены в 1С.

Ответ 3

Подобное ответ: 1С трудится лишь с одним, назначенным нами сервером.

Итого

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

По нагрузке: тёмная пятница — полет обычный.

На новый год и рождество клиент нанимает особую компанию, которая будет 24 часа в день мониторить стабильность работы. Не самое автоматизированное ответ, но как средство выдержать атаку тысяч и тысяч клиентов — в полной мере рабочее.

Владимир Завертайлов, CEOFounder: К тёмной пятнице магазин мы готовили за несколько недель. Из спорных ответов была репликация мастер-мастер, которая на MySQL может доставить большое количество боли. Ну и ветхий Битрикс, что сам по себе — боль. Но мне сложно представить какой-нибудь офлайновый бутик подарков, в котором в любой момент времени находится полторы тысячи человек. И еще полно места.

Всем highload, мальчики!

Создатель: Владимир Завертайлов, CEOFounder sibirix.на данный момент

Случайные статьи:

КАК СОЗДАТЬ ИНТЕРНЕТ-МАГАЗИН. За 2ч. 15м. по-шагам с нуля! Самостоятельно. Смотри!


Подборка похожих статей:

admin