1. Вихідні дані
2. завдання
3. Рішення
4. Про колізії та вирішення
5. Тепер про цікаве.
6. Разом

Чорна п'ятниця - день, з якого в США традиційно стартує сезон різдвяних розпродажів. Потім розпродажі запускаються в інтернет-магазинах (так званий кіберпонеділок). У Росії чорна п'ятниця проводиться з 6-го грудня 2013 року.

Приблизно за два тижні до тієї самої п'ятниці до нас прийшов клієнт. Ну тобто не зовсім ось так "прийшов", з нізвідки, - ми займалися розвитком його інтернет-магазину з 2012-го. Завдання на цей раз була: підготувати магазин до розпродажів, а це значить - до перевантажень.

Вихідні дані

На момент початку підготовки до чорної п'ятниці інтернет-магазин - це:

• Стара версія Бітрікс з згвалтованим ядром (дісталася у спадок).

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

• Більше 66 000 унікальних користувачів на добу. Більше 350 000 звернень в день.

завдання

Знайти рішення, яке б дозволило інтернет-магазину "не падати" під напором користувачів (по суті, зробити high-load проект). Зробити швидко, так як розпродажу вже нещадно близько. Наскільки вдасться досягти мети - мало стати зрозуміло в чорну п'ятницю. За задумом, якщо магазин витримає таку "першу хвилю", то в і новий рік теж проблем не буде.

Рішення

По суті, ми будемо займатися оптимізацією швидкості роботи сайту. Найдієвіший рішення в такому випадку - переписати код. Але це для замовника занадто радикально, а так як на носі розпродажі - взагалі не прийнятно. Ок, вибираємо реплікацію баз даних MySQL. Чи не саме ідеальне рішення, що багаторазово обговорювалося на форумах , Але - подивимося, як воно себе покаже.

Денис, провідний розробник: типова задача застосування реплікації при роботі з базами даних - підвищення відмовостійкості і розподіл навантаження при читанні даних. Архітектура така (мінімальна комплектація): беруться два сервера, один призначається Master, другий - Slave. На сайт заходить користувач, оформляє замовлення, відправляє його на сервер. У базі даних на Master'e створюється запис про його замовленні, після чого дублюється на Slave. У разі відмови першого сервера, база даних завжди залишається на другому, на нього можна швидко перемкнутися. Так підвищується відмовостійкість. При зверненні сайту до бази даних читання може здійснюватися як з першого, так і з другого сервера - так розподіляється навантаження. Але наше завдання полягала в іншому - а саме, нам потрібно було розподілити навантаження не тільки на читання, але і на запис.

Отже, що робимо:

1. Створюємо два Master-сервера.

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

3. Модифікуємо ядро ​​Бітрікс таким чином, що конкретний запис створюється з ймовірністю 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 години на добу моніторити стабільність роботи. Чи не саме автоматизоване рішення, але як засіб витримати атаку тисяч і тисяч клієнтів - цілком робочий.

Володимир Завертайло, CEO & Founder: До чорної п'ятниці магазин ми готували за пару тижнів. З спірних рішень була реплікація майстер-майстер, яка на MySQL може доставити багато болю. Ну і старий Бітрікс, який сам по собі - біль. Але мені складно уявити який-небудь офлайновий бутик подарунків, в якому в кожен момент часу знаходиться півтори тисячі чоловік. І ще повно місця. Всім highload, пацани!

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