Тёмная пятница — сутки, с которого в Соединенных Штатах традиционно стартует сезон рождественских распродаж. После этого распродажи запускаются в вебмагазинах (так называемый киберпонедельник). В Российской Федерации тёмная пятница проводится с 6-го декабря 2013 года.
Приблизительно за 14 дней до той самой пятницы к нам пришел клиент. Ну другими словами не совсем вот так “пришел”, из ниоткуда, — мы занимались развитием его вебмагазина с 2012-го. Задача в этом случае была: подготовить магазин к распродажам, а это значит — к перегрузкам.
Данные
В начале подготовки к тёмной пятнице вебмагазин — это:
-
Ветхая версия Битрикса с изнасилованным ядром (досталась по наследству).
-
Три сервера: на одном крутится сам сайт, на втором — база данных MySQL, третий — до тех пор пока вольный.
-
Более 66 000 неповторимых пользователей в день. Более 350 000 обращений в сутки.
Задача
Отыскать ответ, которое бы разрешило вебмагазину “не падать” под напором пользователей (по сути, сделать high-load проект). Сделать скоро, поскольку распродажи уже беспощадно близко. Как окажется достигнуть цели — должно было стать ясно в тёмную пятницу.
По задумке, в случае если магазин выдержит такую “первую волну”, то в и новый год также неприятностей не будет.
Ответ
По сути, мы будем заниматься оптимизацией скорости работы сайта. Самое действенное ответ при таких условиях — переписать код. Но это для клиента через чур радикально, а так как на носу распродажи — по большому счету не приемлемо. Ок, выбираем репликацию баз данных MySQL.
Не лучшее решение, что многократно обсуждалось на форумах, но — посмотрим, как оно себя продемонстрирует.
Денис, ведущий разработчик: обычная задача применения репликации при работе с базами данных — распределение нагрузки и повышение отказоустойчивости при чтении данных. Архитектура такая (минимальная комплектация): берутся два сервера, один назначается Master, второй — Slave. На сайт заходит пользователь, оформляет заказ, отправляет его на сервер. В базе данных на Master e создается запись о его заказе, по окончании чего дублируется на Slave.
При отказа первого сервера, база данных постоянно остаётся на втором, на него возможно скоро переключиться. Так увеличивается отказоустойчивость. При обращении сайта к базе данных чтение может производиться как с первого, так и со второго сервера — так распределяется нагрузка.
Но отечественная задача заключалась в другом — в частности, нам необходимо было распределить нагрузку не только на чтение, но и на запись.
Итак, что делаем:
-
Создаем два Master-сервера.
-
Настраиваем репликацию. Созданная запись на одном из серверов дублируется на другой.
-
Модифицируем ядро Битрикса так, что конкретная запись создается с возможностью 0,5 на первом сервере и с такой же возможностью — на втором.
В новом Битриксе имеется модуль кластера. И в данной обстановке нам было бы весьма комфортно применять как раз его. Но Битрикс ветхий и таковой возможности у него нет.
Исходя из этого нам было нужно в поле собрать некое подобие данного модуля, пропатчив ядро Битрикса.
Предположительные пользы: нагрузка на любой сервер понижается в два раза, в то время, когда пользователи отправляют заявку с сайта, и кроме этого понижается в два раза, в то время, когда сайт обращается к созданным записям в базе данных. Это должно предохранить базу от “падений” во время громадного наплыва клиентов.
Но не всё так радужно. У нас имеется минимум три подводных камня.
Екатерина, менеджер проекта: Денис давал не самые оптимистичные прогнозы: неприятности имели возможность появиться из-за асинхронной передачи данных — а это, первым делом, дублированние записей. Кроме этого большое количество потенциальных неприятностей крылось и в ветхой, многократно кастомизированной 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м. по-шагам с нуля! Самостоятельно. Смотри!
Подборка похожих статей:
-
Интернет-магазин с человеческим лицом
Уж чем-чем, а качественным обслуживанием клиентов большая часть вебмагазинов похвастать неимеетвозможности. Отсутствие личного контакта ведет к…
-
Как открыть свой интернет-магазин в кризис. советы лидеров рынка e-commerce
Пару дней назад мы с сотрудниками, известными игроками рынка электронной коммерции, проводили онлайн-конференцию Как открыть собственный вебмагазин. Мы…
-
Эксперимент: как мы запустили свой интернет-магазин
От студий веб-дизайна и агентств довольно часто слышу: мы должны предлагать собственную экспертизу клиенту. Значительно чаще экспертиза ограничивается…
-
О чем молчат программисты, создавая интернет-магазин
Павел Устинов Менеджер интернет-проекта, Украина Вспоминая о расширении собственного бизнеса в онлайн, любой клиент грезит об интернет-магазине как у…