Вступ (аналіз проблем)​

Шановні архітектори та розробники електронної комерції, коли лунають сигнали про початок таких масштабних акцій, як “Double Eleven” або “618”, і ви стикаєтеся з потоком користувачів, як у разі цунамі, чи замислювалися ви коли-небудь над наступними питаннями?

  • Система миттєво вийшла з ладу:У момент початку розпродажу мільйони користувачів натискають на кнопку одночасно, і це призводить до миттєвого перевантаження бази даних, внаслідок чого система зламується, сторінки не відкриваються, а компанія зазнає величезних збитків від неукладених угод.
  • Проблема надлишкових запасів:При паралельних запитах традиційні бази даних стикаються з проблемою низької продуктивності блокування читання/запису, що легко призводить до помилок при зменшенні запасів, виникненню “перепродажу” та, як наслідок, до значних фінансових втрат і скарг клієнтів.
  • Відповідь надзвичайно повільна:Навіть якщо система не вийшла з ладу повністю, але основні транзакційні процеси відбуваються дуже повільно, користувачам доводиться чекати декілька десятків секунд, щоб розмістити замовлення, а це дуже поганий досвід, через що відсоток відмов при замовленні різко зростає.
  • Проблема витрат на ресурси та їхньої еластичності:Велика кількість машин, придбаних для задоволення пікових потреб, після закінчення розпродажів негайно стають непотрібними, при цьому рівень використання ресурсів є дуже низьким, а витрати — високими. Ручне масштабування є неефективним і не дозволяє реагувати на миттєві коливання трафіку.

Якщо ви задаєтеся питанням, як розробити систему блискавичних продажів, яка може обробляти мільйони запитів на секунду, забезпечувати узгодженість даних і при цьому бути економічно ефективною, тоді рішення для архітектури блискавичних продажів від Tencent Cloud, перевірене в масштабах великого бізнесу, надасть вам чітку і надійну відповідь.

Архітектурна схема рішення та його опис

На наступному малюнку показано основну архітектуру та процес обміну даними рішення Tencent Cloud для блискавичних продажів:

Архітектурне рішення Tencent Cloud для розпродажів: як електронна комерція може забезпечити безперервну роботу при мільйонах запитів на секунду (QPS) і одночасних замовленнях? - LikaCloud

Основна ідея дизайну цієї програми полягає в тому, що...​“Багаторівневе блокування, асинхронна обробка, кінцева консистентність”​його робочий процес (Workflow) виглядає наступним чином:

  1. 1.Доступ до трафіку та розподіл:Користувач спочатку запитує про те, щоб його запит пройшов черезГлобальне прискорення додатків (GAAP)абоCDNШвидко дістатися до входу, пройшовши черезБалансування навантаження (CLB)Рівномірний розподіл.
  2. 2.Оптимізація та перевірка запитів на читання:Більшість запитів (наприклад, детальна інформація про товар, перевірка наявності товару на складі) направляються безпосередньо до високопродуктивних серверів.RedisКешування. Водночас, за допомогоюХмарні функції (SCF)Здійснюйте легку перевірку прав доступу (наприклад, за допомогою коду підтвердження) і блокуйте шкідливі запити.
  3. 3.Напишіть запит про згладжування піків і асинхронну обробку:Після перевірки основний запит на розпродаж не працює безпосередньо з базою даних, а відразу записує інформацію в неї.Стекова система повідомлень KafkaЦе дозволить швидко повернути користувачів у стан “у черзі”. Таким чином, ми розподілимо пікові навантаження на більш рівномірну кількість запитів і значно знизимо навантаження на серверну частину.
  4. 4.Обробка замовлень і збереження даних:Задня частина обробляє замовлення, споживаючи повідомлення з CKafka з постійною швидкістю і завершуючи операції з базою даних.ТенцентДБ для МysqlЗдійснюйте вирахування запасів і створення замовлень, а також оновлюйте кеш.
  5. 5.Повідомлення про результат: ​Після завершення обробки користувачеві повідомляють про результат його замовлення за допомогою WebSocket або довгого опитування.

Цінність цієї архітектури полягає в тому, що:Він забезпечує абсолютне зниження пікових навантажень за допомогою черги повідомлень (CKafka), приймає більшу частину навантаження на читання за допомогою кешування (Redis), а також гнучко реагує на обчислювальні потреби за допомогою еластичної масштабованості (AS), захищаючи тим самим уразливі реляційні бази даних і забезпечуючи стабільність і високу ефективність усієї системи при високому рівні паралелізму.

Детальний опис основних продуктів і компонентів.

Назва компонентаІграти у рольКлючові рекомендації щодо конфігурації/вибору.Чому ви обрали його?
Хмарна база даних Redis.Кеш і лічильник ядраВін відповідає за зчитування інформації про запаси перед розпродажем, зарезервування запасу під час розпродажу та функцію лічильника, що значно знижує навантаження на базу даних.- ​Вибір версії:Виберіть версію з більшим об'ємом пам'яті для найвищої продуктивності.
- ​Планування потужності:Залишіть буферний простір не менше ніж 301 ТП4Т, щоб впоратися з піковими навантаженнями.
- ​Режим розгортання:Використовуйте версію з головним і підпорядкованими серверами або кластерну версію, щоб забезпечити високу доступність.
Він має високу продуктивність і підтримує сотні тисяч операцій читання та запису на секунду. Забезпечує атомарні операції (такі як DECR), що гарантує точність зменшення запасів, і є кращим вибором для вирішення проблем із високою паралельністю читання та лічильниками.
Стеж за новинами про CKafka у нашому Telegram-каналі.Основні принципи зниження пікових навантажень і розв'язання проблем із затримкамиПриймати всі запити на участь у розпродажах, перетворювати несподівано високий трафік на асинхронний, рівномірний потік повідомлень, захищаючи систему обробки замовлень від перевантаження.- ​Оцінка потужності: ​Згідно з кількістю товарів, що продаються за зниженими цінами, та піковою продуктивністю на одну секунду, оцініть кількість тематичних розділів і об'єм дискового простору.
- ​Стратегія збереження: ​Встановіть розумний час зберігання повідомлень, щоб уникнути переповнення диска.
Висока пропускна здатність, низька затримка, сумісність з протоколом Apache Kafka, що дозволяє легко обробляти мільйони запитів на секунду. Висока здатність накопичення повідомлень гарантує, що запити не будуть втрачені навіть у випадку значно вищого трафіку, ніж очікувалось.
Elastic Scale ASЯдро еластичної диспетчеризації обчислювальних ресурсівАвтоматично збільшувати або зменшувати кількість серверів обробки замовлень на основі таких показників, як кількість накопичених повідомлень у Kafka або навантаження на процесор.- ​Стратегія розширення:Налаштуйте стратегію масштабування з оповіщеннями на основі кількості повідомлень, щоб швидко збільшити потужність.
- ​Час охолодження:Встановіть розумний час охолодження, щоб уникнути частого розширення та згортання.
Реалізація “використання обчислювальних ресурсів за потреби”, автоматичне розширення для задоволення пікового попиту на початку розпродажу та автоматичне згортання для звільнення ресурсів після його завершення значно оптимізують витрати.
Хмарний сервер CVMЦентр обробки бізнес-логіки. Використовується для запуску служби обробки замовлень, служби перевірки бізнесу тощо.- ​Створення дзеркальної копії:Заздалегідь підготовлені образи, що містять бізнес-код, полегшують швидке розгортання масштабованих груп.
- ​Тип прикладу: ​Виберіть обчислювальні оптимізовані екземпляри, щоб гарантувати швидку обробку замовлень.
Він забезпечує стабільні, надійні та гнучкі обчислювальні можливості, а також безперешкодну інтеграцію з такими продуктами, як AS і CLB, і є основою для виконання бізнес-коду.
Балансування навантаження CLBЦентральний елемент розподілу трафіку..Рівномірно розподіляйте величезну кількість запитів користувачів між декількома серверами бізнес-послуг на задньому плані, щоб уникнути перевантаження одного сервера.- ​Алгоритм диспетчера: ​Використовуються такі алгоритми, як вагове опитування (WRR).
- ​Медичний огляд:Включіть перевірку стану здоров'я, щоб автоматично видаляти несправні бекенди.
Підвищення доступності та масштабованості послуг є ключовими компонентами горизонтального масштабування.
Хмарні функції SCFЛегковесне ядро для обробки логіки.Відображає список доступних мов. Цей код використовується для реалізації таких легких логічних операцій, як обмеження частоти, перевірка прав користувача (наприклад, чи брав він участь раніше), перевірка коду підтвердження тощо.- ​Час перерви:Встановіть розумний час очікування виконання функції.
- ​Конфігурація пам'яті:Згідно зі ступенем логічної складності, налаштуйте відповідний об'єм пам'яті.
Архітектура без серверів, відсутність необхідності адмініструвати машини, оплата за фактичну кількість виконаних операцій, ідеальне рішення для випадкових піків навантаження та дуже низькі витрати.

Зведення переваг плану.

  • ⚡ Максимальна продуктивність, мільйони одночасних підключень: ​Кешування в Redis та асинхронна обробка в Kafka легко підтримують мільйони запитів на читання та запис на рівні QPS, забезпечуючи безперебійну та стабільну роботу системи.
  • Оптимізація витрат, еластична масштабованість:Автоматична стратегія масштабування на основі обсягу повідомлень забезпечує точне забезпечення обчислювальних ресурсів, автоматичне звільнення ресурсів після пікових навантажень і зниження витрат більш ніж на 501 ТП4Т.
  • ?️ Відповідність даних, запобігання перепродажу: ​Використовуючи атомарні операції Redis та транзакції бази даних, ми забезпечуємо абсолютну точність зменшення запасів у разі високої інтенсивності роботи та повністю вирішуємо проблему перепродажу.
  • Висока доступність і безперешкодний бізнес:Всі основні компоненти (Redis, Kafka, CLB) забезпечують високу доступність архітектури та автоматичне перемикання на резервний вузол, гарантуючи безперервну роботу бізнесу під час масових акцій.
  • ? Швидке розгортання, просте адміністрування та технічне обслуговування:Вона створена на базі продуктів Tencent Cloud і не вимагає розробки складних проміжних програмних засобів. Вона готова до використання відразу після установки, що значно спрощує процес розробки та експлуатації.

Сценарії застосування та відповідні клієнти

Цей план ідеально підходить для наступних бізнес-ситуацій та клієнтів:

  • Сценарій застосування:
    • Електронна комерція: блискавичні розпродажі:Наприклад, обмежені часові пропозиції, обмежені акції, випуск популярних товарів тощо.
    • Періодичні розпродажі:Наприклад, купівля купонів, залізничних квитків, квитків на концерти тощо.
    • Великі рекламні акції:Такі заходи, як Double 11 і 618, мають обсяг трафіку, який у десятки разів перевищує звичайний щоденний трафік.
  • Для кого це підходить:
    • Всі електронні комерційні платформи та онлайн-системи транзакцій, які стикаються з викликами високої пропускної здатності.
    • Продавці, які планують проводити масштабні рекламні акції, побоюються, що їхні системи не зможуть витримати навантаження.
    • Технічні команди, які хочуть перейти від створення складних архітектур до хмарних хостингових послуг, щоб знизити витрати на експлуатацію та обслуговування.

Стосовні посилання