Решения Tencent для облачной шиповой архитектуры: как добиться миллионов одновременных заказов QPS без простоев для сайтов электронной коммерции?

Введение (анализ болевых точек)

Уважаемые архитекторы и разработчики электронной коммерции, когда “Double 11”, “618” и другие крупные промо-акции дуют в боевой горн, перед лицом цунами пользовательского трафика, вы когда-нибудь сталкивались со следующими проблемами?

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

Если вы ломаете голову над тем, как разработать спайк-систему, способную справиться с миллионами QPS, обеспечить согласованность данных и оптимизировать затраты, то это масштабное решение по спайк-архитектуре от Tencent Cloud, проверенное на практике, даст вам четкий и надежный ответ.

Диаграмма и обзор архитектуры решения

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

Решения Tencent для облачной шиповой архитектуры: как добиться миллионов одновременных заказов QPS без простоев для сайтов электронной коммерции? - LikaCloud

Основные идеи этой программы заключаются в следующем“Многоуровневый перехват, асинхронная обработка, в конечном итоге последовательная”.Рабочий процесс выглядит следующим образом:

1.Доступ и планирование трафика.Сначала запрос пользователя проходит черезГлобальное ускорение приложений (GAAP)возможноCDNБыстрый вход черезБалансировка нагрузки (CLB)Распределите равномерно.
2.Оптимизация запросов на чтение и контрольные суммы.Подавляющее большинство запросов (например, подробная информация о товарах, проверка запасов) направляется на высокопроизводительныйRedisКэш. В то же время можно создать новый кэш с помощью функцииОблачная функция (SCF)Реализуйте легкую проверку прав доступа (например, CAPTCHA) и перехват вредоносных запросов.
3.Обрезание и рассинхронизация запросов на запись.Основной запрос spike не выполняет прямых манипуляций с базой данных после передачи контрольной суммы, а сразу записывает вОчередь сообщений CKafkaВ середине очереди, и быстро вернуться к пользователю “очереди” статус. Это сглаживает мгновенные пики до равномерного потребления, значительно снижая нагрузку на внутреннюю систему.
4.Обработка заказов и сохранение данных.Внутренняя служба обработки заказов потребляет сообщения из CKafka с равномерной скоростью, чтобы заполнить базу данных (TencentDB для MySQL) транзакционное списание запасов и создание заказов, а также обновление кэша.
5.Уведомление о результатах.После завершения обработки пользователь получает уведомление о конечном результате заказа через WebSocket или длинный опрос.

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

Основные продукты и компоненты

название компонента	играть роль	Основные рекомендации по конфигурации/выбору	Почему стоит выбрать его
Облачная база данных Redis	Кэш-память и ядро счетчика. Считывание информации об инвентаре перед всплеском, предварительное вычитание инвентаря и функции счетчика во время всплеска, что значительно снижает нагрузку на базу данных.	-Выбор версии.Выберите версию с оперативной памятью для максимальной производительности. -Планирование мощностей.Зарезервируйте 30% или больше места в буфере на случай скачков. -Модель развертывания.Для обеспечения высокой доступности используйте версию master-slave или кластерную версию.	Чрезвычайно высокая производительность, поддерживающая сотни тысяч операций чтения и записи в секунду. Обеспечивает атомарные операции (например, DECR) для обеспечения точности инвентаризационных вычислений и является первым выбором для решения сценариев с одновременным чтением и счетчиками.
Очереди сообщений CKafka	Снижение пиковых нагрузок и разделение ядра. Принимает на себя все секундные запросы на запись, преобразуя внезапный, мгновенный трафик в асинхронный, равномерный поток сообщений, чтобы защитить систему обработки заказов, расположенную ниже по течению, от перегрузки.	-Оценка вместимости.Оцените количество разделов темы и объем диска, исходя из количества элементов всплеска и пикового QPS. -Стратегия удержания.Установите разумное время хранения сообщений, чтобы избежать записи на диск.	Высокая пропускная способность, низкая задержка, совместимость с протоколом Apache Kafka, может легко обрабатывать миллионы TPS. возможность укладки сообщений, чтобы гарантировать, что трафик намного больше, чем ожидалось, не потеряет запросы.
Эластичный стретч AS	Эластичность вычислительных ресурсов Ядро планирования. Автоматическое увеличение или уменьшение количества серверов обработки заказов на основе таких показателей, как количество сообщений, уложенных в CKafka, или загрузка процессора.	-Стратегии масштабирования.Настройка политик масштабирования оповещений на основе объема стека сообщений для быстрого расширения емкости. -Время действия.Установите разумное время охлаждения, чтобы избежать частого растягивания.	Использование вычислительных ресурсов по требованию, автоматическое наращивание мощностей для преодоления пика в начале всплеска и автоматическое сокращение мощностей для высвобождения ресурсов после окончания всплеска, что значительно оптимизирует расходы.
Облачные серверы CVM	Вычислительное ядро бизнес-логики. Используется для запуска служб обработки заказов, служб проверки бизнеса и т. д.	-Зеркальное производство.Готовые образы с бизнес-кодом для быстрого развертывания командой масштабирования. -Тип экземпляра.Выбирайте экземпляры, оптимизированные с точки зрения вычислений, чтобы обеспечить скорость обработки заказов.	Обеспечивает стабильную, надежную и отказоустойчивую вычислительную мощность, которая легко интегрируется с AS, CLB и другими продуктами и является основой для выполнения бизнес-кода.
Балансировка нагрузки CLB	Ядро распределения трафика. Равномерное распределение массивных пользовательских запросов между несколькими серверами внутренней системы, чтобы избежать перегрева в одной точке.	-Алгоритмы составления расписания.Используются такие алгоритмы, как взвешенный опрос (WRR). -Осмотр здоровья.Включите проверку работоспособности, чтобы автоматически отсеивать ненормальные бэкенды.	Повышение доступности и масштабируемости услуг - ключевой компонент обеспечения горизонтального масштабирования.
Облачная функция SCF	Легкое ядро логической обработки. Используется для выполнения легкой логики, такой как ограничение частоты, проверка соответствия пользователя требованиям (например, участвовал ли он уже) и проверка CAPTCHA.	-Тайм-аут.Установите разумный тайм-аут для выполнения функции. -Конфигурация памяти.Настройте соответствующую память в зависимости от сложности логики.	Бессерверная архитектура, не нужно управлять машинами, оплата производится по фактическому количеству операций, идеально подходит для мгновенных пиков, очень низкая стоимость.

Краткое описание преимуществ программы

⚡ Экстремальная производительность при миллионном параллелизме.Кэш Redis + асинхронная обработка CKafka, легко поддерживающая миллионы запросов на чтение и запись на уровне QPS, обеспечивают плавность и стабильность системы.
? Оптимизация затрат при гибком масштабировании.Стратегия автоматического масштабирования, основанная на объеме накопленных сообщений, обеспечивает точное выделение вычислительных ресурсов и автоматическое освобождение после пика, снижая затраты более чем на 50%.
? ️ Данные согласованы и исключают перепродажу.Использование атомарных операций Redis и транзакций базы данных обеспечивает абсолютную точность вычисления инвентаризации в сценариях с высоким уровнем параллелизма, полностью решая проблему перепродажи.
? Высокая доступность для спокойного ведения бизнеса.Основные компоненты (Redis, CKafka, CLB) обеспечивают архитектуру высокой доступности с автоматическим обходом отказа, чтобы гарантировать непрерывную работу без перерывов во время промо-акции.
? Быстрое развертывание, простое обслуживание и ремонт.Построенная на базе зрелых продуктов Tencent Cloud, не требующая создания сложного промежуточного ПО, "из коробки", значительно снижающая сложность разработки, эксплуатации и обслуживания.

Сценарии применения и применимые клиенты

Это решение идеально подходит для следующих бизнес-сценариев и клиентов:

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