1. Предыстория бизнеса

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

• СоздайтеОтносится к созданию купонов, включая настройку различных правил купонов и порогов использования.

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

• использоватьОтносится к использованию купонов, включая возврат купонов после форвардной покупки товаров и обратное возмещение.

• считатьОтносится к статистике купонов, включая сводку о количестве выпущенных купонов, количестве использованных купонов и использованных продуктах.

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

Ниже приведено отображение некоторых сцен купонов торговых центров vivo:

2. Архитектура системы и изменения

Купоны были впервые связаны с торговым центром в системе. С непрерывным развитием торгового центра vivo, увеличением маркетинговой активности и увеличением количества сценариев использования купонов система купонов постепенно стала «бессильной», обнажив множество проблем:

• Выпуск массивных купонов стал узким местом хранения отдельных купонов и хранения одной таблицы.

• Высокая связь с системой торгового центра напрямую влияет на производительность интерфейса всего сайта торгового центра.

• Итеративное обновление купонов ограничено графиком версий торгового центра.

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

Чтобы решить вышеуказанные проблемы, 19-летняя купонная система была независима от системы предоставления общих купонных услуг.Архитектура системы после обретения независимости выглядит следующим образом:

Система купонов Независимое решение для миграции

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

Мы используем решение для непрерывной миграции:

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

Статические данные: данные, сгенерированные на фоне купона, не имеют ничего общего с пользователем.

Динамические данные: данные о купонах, относящиеся к пользователям, включая купоны, полученные пользователями, данные о взаимосвязи между купонами и заказами и т. д.

• Настройте текущий переключатель базы данных только для записи, то есть запишите данные купона в библиотеку торгового центра (старая библиотека).

• Система купонов работает онлайн, а статические данные переносятся с помощью скриптов. После переноса проверьте точность переноса статических данных.

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

• Перенос данных в движении. После завершения миграции проверьте точность динамической миграции данных.

• При переключении источника данных источник данных, предоставляемый сервисом, переключается на новую библиотеку. Убедитесь, что служба работает правильно, и в случае возникновения проблемы переключитесь обратно на источник данных хранилища.

• Отключите двойную запись, и миграция системы купонов завершена.

Топология запроса купонной системы после миграции выглядит следующим образом:

3. Дизайн системы

3.1 Подтаблица подбазы данных купонов

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

Ключевые слова: выбор технологии, фактор подтаблицы подбиблиотеки.

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

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

Предполагая, что всего имеется N баз данных и M таблиц, стратегия маршрутизации для подбаз данных и подтаблиц будет следующей:

Суффикс библиотеки databaseSuffix = hash(userId) / M %N

Суффикс таблицы tableSuffix = hash(userId) % M

3.2 Схема метода распределения купонов

Чтобы удовлетворить требования к выпуску купонов в различных сценариях, система купонов предусматривает три метода выпуска купонов:Единый интерфейс сбора купонов,Выпуск купонов за кулисами,Обмен кода купона.

3.2.1 Единый интерфейс сбора купонов

Гарантия точности проверки купона

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

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

Чтобы решить эту проблему, купоны используют схему распределенной блокировки, а реализация распределенных блокировок зависит от Redis. Перед проверкой количества купонов, полученных пользователем, попробуйте получить распределенную блокировку и снимите блокировку после успешной выдачи купона, чтобы гарантировать, что пользователь не будет предъявлять чрезмерные требования при получении того же купона. В приведенном выше сценарии после того, как пользователь впервые успешно получит распределенную блокировку, пока первый запрос не освободит полученную распределенную блокировку или не истечет время ожидания, в противном случае пользователь не сможет получить распределенную блокировку для второго запроса, что гарантирует что пользователь получит только один успешно.

Инвентаризационный вычет

Для купонов требуется вычет запасов.Существуют две распространенные схемы вычета запасов:

Вариант первый: База данных отчислений.

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

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

недостатокТакже очевидно, что есть два основных момента:

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

2) Частые запросы к базе данных отнимают много времени и занимают много ресурсов подключения к базе данных.

Вариант 2: операция вычета запасов на основе Redis.

Поместите инвентарь в кеш и используйте функцию incrby Redis, чтобы вычесть инвентарь.

программыпреимуществоЭто прорвать узкое место базы данных с высокой скоростью и высокой производительностью.

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

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

После того, как инвентарный номер будет обновлен, инвентарь будет равномерно разделен на M частей, и первоначальное обновление будет выполнено в таблице инвентарных записей. Пользователь получает купон, случайным образом выбирает назначенное поле инвентаризации (общее количество M) в таблице записей инвентаризации для обновления, и, если обновление прошло успешно, вычет инвентаря считается успешным. При этом запланированная задача будет периодически синхронизировать количество подобранных акций. По сравнению со схемой 1, эта схема преодолевает узкое место блокировки одной строки в базе данных, а реализация проста, без учета проблем потери данных и несогласованности.

Получите несколько купонов одним кликом

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

1) Как обеспечить производительность

Для получения нескольких купонов, если каждый купон проверяется, вычитается из инвентаря и хранится отдельно, узким местом производительности интерфейса является количество купонов.Чем больше купонов, тем ниже производительность. Итак, в случае большого количества купонов, как обеспечить высокую производительность? Принимаются две основные меры:

a. Массовые операции.

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

b. Ограничьте количество купонов, используемых за один раз.

Установите порог и вернитесь сразу после превышения числа, чтобы убедиться, что система находится в безопасном диапазоне.

2) В случае высокого параллелизма пользователей не обгонят

Если пользователь инициирует запрос в торговом центре, один щелчок, чтобы получить четыре купона A/B/C/D, и активная система одновременно выдает пользователю купон A, эти два запроса купона выполняются одновременно. Среди них купон A ограничивает получение каждым пользователем только одного купона. В соответствии с упомянутым выше использованием распределенных блокировок для обеспечения точности проверки ключами двух запрошенных распределенных блокировок являются:

ID пользователя+A_id+B_id+C_id+D_id

идентификатор пользователя+A_id

В этом случае запрошенная дважды распределенная блокировка не сработает, потому что ключи блокировки разные, и все равно есть вероятность ошибки при проверке количества. Чтобы избежать чрезмерного сбора пользователей в процессе сбора купонов партии, получение блокировок распределения было изменено в процессе сбора купонов партии. В приведенном выше примере, чтобы получить четыре купона A/B/C/D с помощью одного ключа, вам необходимо получить 4 распределенных замка в пакетах.Ключ блокировки:

идентификатор пользователя+A_id

идентификатор пользователя+B_id

идентификатор пользователя+C_id

идентификатор пользователя+D_id

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

Идемпотентность интерфейса

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

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

ТакПервый вопрос, который следует рассмотреть: в какую таблицу добавить уникальный индекс?

Вариантов не более двух: существующая таблица или новая таблица.

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

• Метод создания новой таблицы не обязательно должен быть совместим с историческими данными, но недостатки также очевидны.Добавление слоя ассоциации таблиц сильно влияет на производительность и существующую логику. Учитывая всесторонне, мы решили добавить уникальное поле в существующую таблицу, что в большей степени способствует обеспечению производительности и последующей ремонтопригодности.

Второе соображение: как быть совместимым с историческими данными и деловыми сторонами? К историческим данным добавляются уникальные поля, а уникальные значения нужно заполнять, иначе нельзя добавить уникальный индекс. Мы используем скрипт для обновления данных, чтобы построить уникальные значения и обновить их в каждой строке исторических данных. Деловая сторона, к которой был подключен купон, не вводит уникальный код.В этом случае сторона купона генерирует уникальный код в качестве замены для обеспечения совместимости.

3.2.2 Адресная выдача

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

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

Целевая выдача купонов отличается от пользователей, активно получающих купоны, и сумма направленных купонов обычно велика (100 миллионов). Для поддержки крупномасштабной эмиссии направленных купонов были внесены некоторые оптимизации для направленной эмиссии купонов:

1) удалить транзакцию. Логика транзакций слишком тяжелая и не нужна для направленной эмиссии. Если выдача купонов не удалась, запишите неудачные купоны, чтобы убедиться, что ошибка может быть повторена.

2) Облегченная проверка. Направленная выдача купонов ограничивает типы купонов, а конфигурация, требующая строгой проверки атрибутов, избегается путем ограничения конфигурации. В отличие от длительной логики проверки активного купона пользователем, проверка целевой выдачи купонов очень проста, что значительно повышает производительность выдачи купонов.

3) Объемная вставка. Пакетная вставка купонов сокращает время ввода-вывода в базу данных, устраняет узкие места в базе данных и повышает скорость выдачи купонов. Целевая выдача купонов предназначена для разных пользователей.Купоны пользователей разделены на базы данных и таблицы.Для достижения пакетной вставки необходимо сначала вычислить суффиксы таблицы базы данных, соответствующие разным пользователям в памяти, а затем пакетно вставить данные после сбора, и вставить не более M раз, M — общее количество таблиц библиотеки.

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

3.2.3 Активация кода купона

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

3.3 Усовершенствованный дизайн маркетинговых возможностей

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

Точный доступ к купонам:

3.4 Связь между купонами и товарами

Использование купонов должно быть связано с товарами, которые могут быть связаны со всеми товарами или некоторыми товарами. Чтобы гибко соответствовать конфигурации товаров, связанных с купонами, система купонов имеет два способа ассоциации:

А. Черный список.

Доступные элементы = Все элементы - Элементы из черного списка.

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

б. Белый список.

Доступные элементы = элементы из белого списка.

Белый список подходит для ситуации, когда ассортимент используемых продуктов купона относительно невелик, а используемые продукты купона настраиваются напрямую.

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

3.5 Гарантия высокой производительности

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

многоуровневый кэш

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

Разделение чтения и записи базы данных

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

Использование изоляции внешнего интерфейса и предохранителя

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

Избыточность поля купона пользовательского параметра

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

4. Резюме и перспективы

Наконец, краткое изложение системы купонов:

• Непрерывная миграция, плавный переход. Он стабильно работает уже 2 года с момента обретения независимости, и его производительности достаточно для поддержки бурного развития vivo mall в ближайшие 3-5 лет.

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

• Для деловых проблем принцип заключается в выборе подходящего и практичного решения.

• Обладают идеальными возможностями купонного бизнеса.

Перспективы: в настоящее время система купонов в основном обслуживает торговые центры vivo.В будущем мы надеемся открыть возможности купонов и предоставить общую и интегрированную купонную платформу для других внутренних деловых сторон.

Автор: команда интернет-разработчиков vivo - Ян Чао