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

Следите за разработчиками Tencent Cloud и заранее получайте техническую информацию из первых рук👇

01. Общая информация

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

02. Что такое система купонов?

Вот несколько страниц, посвященных купонам, на нескольких платформах электронной коммерции:

По порядку это Dongdong, Moubao и Tencent Cloud. MALL ,Вот соответствующая система, лежащая в основе различных купонов.,В совокупности может называться Купонсистема. Проще говоря, Купонсистема — это очень большая система.,Давайте кратко изложим это здесь и поговорим о четырех основных ключевых компетенциях.：Создавайте, распространяйте, используйте и собирайте статистику.

2.1 Архитектура системы

В этой статье в основном рассказывается о том, как платформа создает и распределяет купоны в пакете купонов учетной записи пользователя.,То есть среди четырех основных компетенций, упомянутых вышеСоздавать и распространять.

03. Создание купона

3.1 Основные понятия

Во-первых, давайте кратко разберемся в двух понятиях: пакеты купонов и купоны.

1. Пакет купонов: пакет шаблонов генерации одинаковых купонов.
2. Купон: создается на основе информации о партии. Соответствующая связь между купонами и партиями равна N:1.

3.2 Основные поля таблицы партии

1. пакетный_ид;
2. Название купона;
3. Тип купона;
4. Количество инвентаря;
5. Правила скидок, такие как: полная скидка, полная скидка и т. д.;
6. Правила эффективности: фиксированное время действия, время действия после сбора и т. д.;
7. Правила получения: Дневной лимит для пакетов, дневной лимит для пользователей, общий лимит для пользователей и т.д.;
8. Правила использования: назначенные продавцы, определенные продукты, определенные категории, определенные сценарии и т. д.

3.3 Основные поля таблицы купонов

1. Купон ID：Распределенный идентификатор глобально уникален.；
2. Идентификатор пакета;
3. ID пользователя;
4. Купонсостояние；
5. Контекстная информация.

Записью данных в пакетную таблицу в основном управляет фоновое управление стороны B, поэтому я не буду здесь вдаваться в подробности.

Купон Табличные данные в основном проходят черезПишите после того, как действие отправки связано с пользователем,Это будет представлено позже.

3.4 Эффект конфигурации стороны B

04. Распространение купонов

4.1 Две основные проблемы

1. Управление запасами: как предотвратить перевыпуск и обеспечить сохранность запасов.
2. Сцена сложная, как поддержать High параллелизм и мгновенные сцены глюков с высокой посещаемостью.

Индикация дорожных сбоев:

4.2 Демонтаж основного процесса

1. инвентаризационные отчисления;
2. генерировать Купон。

4.2.1 Инвентарные вычеты

1. Использовать базу напрямую данных занимается управлением запасами и сталкивается с проблемами: Высокий параллелизмпривести кбаза сбои данных и очевидные узкие места в производительности.
2. Кэш для управления запасами: несогласованность данных, проникновение, поломка, лавина и другие проблемы.

Окончательный план:

Добавление асинхронной сегментации инвентаря Redis+Lua+:

1. Redis+Lua：поддерживать Высокий параллелизм Инвентарные вычеты。
2. Дополнение к асинхронной сегментации инвентаря: поддержка High Гибкое распределение запасов на основе параллелизма.

Диаграмма сценария Lua (код диаграммы предназначен только для ознакомления):

--партияизHashKey
local stockKey = KEYS[1];

--Argv параметр
local stockId = ARGV[1];
local couponId = ARGV[2];
local uid = ARGV[3];
--Максимальная сумма распределения партии в день
local maxByDay = ARGV[4];
-- Лимит на человека
local maxByUser = ARGV[5];
--Текущее время ул
local crtDateStr = ARGV[6];
-- Лимит на человека в день
local dailyMaxByUser = ARGV[7];

stockId = tonumber(stockId);
maxByUser = tonumber(maxByUser);
maxByDay = tonumber(maxByDay);
dailyMaxByUser = tonumber(dailyMaxByUser);

--StockKey nil
if not stockKey then
    return '-4'
end
--Argv nil
if not stockId or not couponId or not uid or not maxByUser or not maxByDay or not crtDateStr or not dailyMaxByUser then
    return '-5'
end

local leftAmountField = 'left_amount';
local res = redis.call("HMGET", stockKey, leftAmountField, crtDateStr);
local leftAmount = tonumber(res[1]);
local crtDispatchAmount = tonumber(res[2]);
local couponIdSetKey = stockKey .. ':coupon:zset';

--Выделен ли Купон ИД инвентарь
local score = redis.call("ZSCORE", couponIdSetKey, couponId);
-- couponId уже существует
if score then
    return '-6';
end

-- Недостаточный запас
if not leftAmount or leftAmount <= 0 then
    return '-3';
end

--Достигнут максимальный лимит распределения за день.
if crtDispatchAmount and crtDispatchAmount >= maxByDay then
    return '-1';
end

-- Общее количество HashKeys, полученных на человека в день
local dailyUserAcquireNumKey = stockKey .. ":user:acquire:" .. crtDateStr;
if dailyMaxByUser > 0 then
  local dailyUserAcquireNum = redis.call("HGET", dailyUserAcquireNumKey, uid);
  dailyUserAcquireNum = tonumber(dailyUserAcquireNum);
  -- Достигнут дневной лимит на человека
  if dailyUserAcquireNum and dailyUserAcquireNum >= dailyMaxByUser then
      return '-7'
  end
end

--Партияпользователь получает количество HashKey
local userAcquireNumKey = stockKey .. ":user:acquire";
local usrAcquireNum = redis.call("HGET", userAcquireNumKey, uid);
usrAcquireNum = tonumber(usrAcquireNum);

--Достигнут максимальный лимит сбора данных пользователем
if usrAcquireNum and usrAcquireNum >= maxByUser then
    return '-2'
end

--Вычет инвентаря-1
local leftAmountAfterOp = redis.call("HINCRBY", stockKey, leftAmountField, -1);
--Сумма, распределенная в день +1
local crtDispatchAmountAfterOp = redis.call("HINCRBY", stockKey, crtDateStr, 1);
--Текущая сумма распределения пользователя+1
local usrAcquireNumAfterOp = redis.call("HINCRBY", userAcquireNumKey, uid, 1);
-- Текущий объём раздачи пользователей за день +1.
local dailyUserAcquireNumAfterOp = redis.call("HINCRBY", dailyUserAcquireNumKey, uid, 1);

redis.call("ZADD", couponIdSetKey, uid, couponId);

--Возврат в контекст после операции, оставшаяся сумма в кеше, сумма выданная за день, сумма полученная пользователем, сумма полученная пользователем в день
return '0|' .. leftAmountAfterOp .. '|' .. crtDispatchAmountAfterOp .. '|' .. usrAcquireNumAfterOp .. '|' .. dailyUserAcquireNumAfterOp

Инструкции по добавлению разделов:

представлять:

Всякий раз, когда оставшийся инвентарь Redis меньше M, N инвентаря асинхронно добавляется из базы данных в Redis, чтобы гарантировать, что количество инвентаря Redis всегда меньше или равно количеству ресурсов в базе данных.

1. Блокируйте трафик и направляйте его напрямую на базу данных,Уменьшите нагрузку на базу данных.
2. Redis+база контроля данных, двойная гарантия не переизбытка.
3. Инвентарь добавлен M и N Гибкое развертывание в соответствии с реальными потребностями бизнеса.。
   1. Под M можно понимать самую низкую ставку выпуска бизнес-купонов. Например: быстрая доставка, медленная доставка, подсказка об отсутствии на складе и т. д.
   2. N Его можно понимать как максимальное количество инвентаря, которое можно потерять в чрезвычайных обстоятельствах.

Основной процесс показан на рисунке:

4.2.2 Генерация купонов

1. Списанный инвентарь успешно и синхронно генерируется и информация Купона записывается в базу. данных,Вы также столкнетесь с проблемой, заключающейся в том, что высокий параллелизм приводит к сбою базы данных.,Узкое место в системе явно нежелательно.
2. Если сюда добавить кеширование, то решение проблемы кеширования усложнит бизнес в сочетании со второй основной проблемой: мгновенными сбоями при высоком трафике.

Окончательный план:

1. Инвентарные После успеха вычетов Купон генерируется асинхронно для достижения общей поддержки процесса High. параллелизм,и может решить проблемы с трафикомизвопрос。PS：Проблема распределенных транзакций.
2. В сочетании с собственными бизнес-сценариями,Сравните и взвесьте различные решения для распределенных транзакций,Окончательный выборТаблица локальных транзакций + уведомление о наилучших возможностяхрешить Проблема распределенных транзакций.

представлять:

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

Основной процесс показан на рисунке:

Ссылка на данные:

1. В сочетании с реальными целями стресс-тестирования среды бизнес-тестирования 1W/TPS сигнал（системаобщийподдерживать Горизонтальное расширение еще больше повышает производительность）。

Указывать:

05. Последующая оптимизация

5.1 Горячие вопросы

Просмотрите общий план,Горячие проблемы по-прежнему существуют в одной и той же серии сценариев.,Здесь можно провести некоторую оптимизацию, чтобы улучшить производительность системы.,нравиться：Группа ресурсов,Совокупные вычеты,Горячие обновления Технология и т. д.。Как решить острые вопросы?Ниже приводится сравнительное представление нескольких вариантов, основанных на сценарии выпуска купонов.,Доступно для справки.

Точка доступа Указывать:

5.1.1 Распределение ресурсов

Введение:тот же самыйпартияиз Инвентарь разделен на несколько частей,Повысьте производительность за счет децентрализации запросов на вычет запасов.

Преимущества:Сильная возможность горизонтального расширения。

Сосредоточиться на:

1. Проблема перекоса маршрутизации ключей. В идеальной ситуации все ключи одинаково соответствуют сегментам.
2. Проблема неравномерности запасов и компромисса между производительностью между сегментами. Идеальная ситуация заключается в том, что уровень потребления во всех сегментах одинаков.

5.1.2 Агрегационные вычеты

Введение:Агрегация та же самаяпартияиз Запросить фиксированный вычет,Улучшите общую производительность сервиса за счет агрегирования объема запросов.

Преимущества:Предварительное агрегирование запросов помогает повысить стабильность сервиса.。

Сосредоточиться на:

1. Разработка стратегии агрегирования требует компромисса между стабильностью и производительностью.
2. Вопрос о том, как адаптировать критически важные запасы к стратегиям агрегирования.

5.1.3 Обновление точки доступа

Введение:Горячие Подробное описание технологии обновления см. в документации Tencent Cloud:

https://cloud.tencent.com/document/product/237/13402

Преимущества:Применимыйбаза оптимизация точки доступа данных на уровне блокировки.

Сосредоточиться на:

1. Применимый сценарий использования баз данных относительно единственен.

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

-End-

Автор оригинала｜Гуань Чжэньпань