Возьмите красные конверты в отработке сцен с пиками

Практикуйте пик, захватите сцену с красным конвертом, обычное решение

Адрес статьи:blog.Park Ruiqing.com/2019/09/01/…

предисловие

Сцены Seckill можно увидеть почти везде в жизни, будь то товарный ажиотаж, захват билетов на Весенний фестиваль или красный конверт, который можно увидеть повсюду, это будет включать сцену seckill. стать популярной темой для интервьюеров и кандидатов Jinjin Happy Road.

Далее в этой статье будет представлена ​​схема реализации захвата красных конвертов в сценарии seckill, включая общие схемы реализации, узкие места и оптимизация бизнеса красных конвертов.

анализировать

Сцены

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

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

бизнес

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

Технологии

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

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

• Больше читайте и меньше пишите: кеш.

• Конкуренция за ресурсы: Атомарные операции, уровни кеша или базы данных можно контролировать, например, используя сценарии Lua для сокращения операций инвентаризации.

Вариант 1 - Предварительное распределение

Применимая сцена

красный конвертКоличество относительно разумных, оченьМеньше излишков запасовВ случае небольшого количества пользователей.

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

Короткое описание

Предварительное распределение — это когда красные конверты распределяются, по общему количеству и количеству красных конвертов, по установленному алгоритму, и все записи о раздаче красных конвертов создаются заранее, при получении обновляются только записи о раздаче красных конвертов.

Больше подходит для красных конвертов, выдаваемых системой (для всех групп пользователей определенного ярлыка в основном будут получены выданные красные конверты), не подходит для красных конвертов группы пользователей (количество красных конвертов не контролируется, когда количество красных конвертов намного больше, чем количество групп, существует много неверных данных, например, выдача красных конвертов с количеством 1000 в группе из 10).

детали реализации

Процесс

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

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

• Ядром операции получения является обновление записи о раздаче красных конвертов:

  -- 此处划重点 (￣▽￣)"
  UPDATE IGNORE record SET user_id = {userId}, gmt_receive = UNIX_TIMESTAMP() WHERE red_envelop_id = 1 AND user_id < 0 LIMIT 1;
  -- red_envelop_id + user_id 有唯一约束
  

Запись о раздаче красных конвертов

Запись о распределении красных пакетов

unique: 红包ID+领取用户ID

Примечание

• UPDATE IGNORE ... LIMIT 1: Решена проблема конкуренции за ресурсы и обеспечена корректность данных, получаемых красными конвертами при одновременных запросах.
• red_envelop_id + user_id: Создайте индекс и уникальные ограничения, чтобы гарантировать, что один и тот же красный конверт может быть востребован только один раз одним и тем же пользователем.
• предварительно распределенныйuser_idОтрицательное значение: потому чтоred_envelop_id + user_idимеет единственное ограничение.
• Для небольших действий с общим трафиком этот метод прост в реализации и недорог, и он может в основном обрабатывать только один MySQL без использования кэша.

Решение 2 — распространение в реальном времени

Применимая сцена

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

детали реализации

Процесс

• Загрузите информацию о красном конверте в кеш перед запуском игры, время первой загрузки может быть больше
• Возьмите красный конверт: прочитайте из кэша (если не загружены), атомично обновите кэш после выделения красного конверта (если оно было выпущено, он вернется непосредственно к неудаче)
• Запись в БД после обновления кеша (проверка корректности данных)

Запись о раздаче красных конвертов

Запись о распределении красных пакетов

unique: 红包ID+领取用户ID

Примечание

• Время первой загрузки кеша немного больше: может быть большой всплеск трафика при первой раздаче красного конверта, а загружать кеш из БД в это время нецелесообразно.
• Кэш не должен быть строго согласован с базой данных: правильность данных поддерживается базой данных.Например, кеш вычел сумму красного конверта, но при обновлении базы данных возникает исключение.В это время кеш не нужно откатывать, и его можно перезагрузить после того, как кеш станет недействительным.. (поэтому время кеша может быть несколько секунд, не слишком долго)
• При обновлении кеша можно рассмотреть возможность использования сценариев Lua для обеспечения атомарности.
• Распространение красных пакетов в режиме реального времени не приведет к недопустимым записям, что подходит для большинства сценариев, но реализация намного сложнее, чем предварительное распределение.

Детали и оптимизация

• Контроль частоты кликов клиента может в определенной степени снизить трафик.

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

• Уровень шлюза выполняет ограничение тока.

Эпилог

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

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

Если эта статья была вам полезна, ставьте лайк (￣▽￣)"

Рекомендуемое чтение:

• Практика открытия шлюза API (1) — проектирование шлюза API
• Практика Open API Gateway (2) — Повтор атаки и защита
• Практика Open API Gateway (3) — Текущее ограничение

Добро пожаловать в публичный аккаунт (код как поэзия):