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

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

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

Примерно за две недели до той самой пятницы к нам пришел клиент. Ну то есть не совсем вот так “пришел”, из ниоткуда, — мы занимались развитием его интернет-магазина с 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 для данных таблиц, “выбрасывает” Бивиса (или Баттхеда) из статистики, но притом все последующие посетители учитываются в полной мере — и записываются в таблицу. При посещаемости в шестьдесят тысяч уников в день — жертва не самая большая.

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

Проблема 2

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

Решение 2

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

Проблема 3

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

Решение 3

Аналогичное решение: 1С работает только с одним, назначенным нами сервером.

Итого

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

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

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

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


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


Автор: Владимир Завертайлов, CEO & Founder sibirix.ru

Компании и сервисы: 1С-Битрикс
Автор: Игорь Назаров

Подписаться на новости

Читайте также

15 ноября / Комментарии

Возможно ли «коробочное» решение в B2B? 11 ключевых отличий розничного интернет-магазина от B2B-портала

Когда  пишешь о различиях B2B и B2C сфер, то сами собой всплывают слова Льва Николаевича «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». Так же и в бизнесе: все розничные интернет-магазины похожи друг на друга, но каждый B2B-портал индивидуален.
Разница не очевидна на первый взгляд, поэтому многие компании соглашаются на «коробочное» решение. Почему готовая CMS подходит для розницы, но не подходит для B2B?

далее →

14 ноября / Комментарии

«Джентльменский набор»: что нельзя забыть при запуске интернет-магазина?

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

далее →

24 октября / Комментарии

Заказ интернет-магазина: на чем можно сэкономить?

Утверждение «время – деньги», пожалуй, одно из самых ключевых для любого бизнеса. В том числе оно актуально и при первичном запуске торговой онлайн-площадки. Однако в случае ограниченного бюджета или горящих сроков владельцам и управляющим интернет-магазинов приходится принимать решения о том, на что необходимо направить свои ресурсы в первую очередь, а чем можно повременить. Вот об этом сегодня и пойдет речь.

далее →

18 октября / Комментарии

Создание интернет-магазина без лишних вложений: онлайн-конструктор + профессиональная CMS в одной «коробке»

Как правильно выбрать движок интернет-магазина — так, чтобы через год-другой не пришлось менять его на другой, а потом на третий и так далее? Если рассуждать логически, то такой движок должен быть простым в освоении — чтобы с ним мог справиться любой начинающий пользователь — и в то же время настолько мощным и гибким, чтобы со временем можно было создать профессиональную торговую площадку в интернете со всеми современными возможностями.

далее →

17 октября / Комментарии

CMS и SaaS для интернет-магазинов: в какую сторону все идет?

Цель данного материала – начать продуктивный полилог между несколькими сторонами: различными разработчиками CMS/SaaS, разработчиками сайтов/потребителями SaaS и владельцами интернет-магазинов. И главное его условие – все участники должны руководствоваться не только собственными интересами, но и интересами четвертой стороны – собственно, самих онлайн-покупателей.

далее →

X
Нажмите «Нравится»,
чтобы читать Shopolog.ru в Facebook