Как реализовать контроль частоты рекламных всплывающих окон?
Сегодня мы поговорим о проблеме, возникшей в практической работе:
Продукты, представленные на нашей домашней странице продуктасделать всплывающую рекламу, но я не хочу, чтобы у пользователей открывалось окно каждый раз, когда они заходят.Каждый пользователь заходит и играет только один раз в день.
Как это достигается?
Способ 1 (грубая сила)
Может быть, некоторые люди думают, что это очень просто. Разве эта проблема не абстрагируется для записи поведения пользователя? Это сохраняет каждое поведение пользователя в Redis или базе данных и проверяет базу данных или Redis каждый раз, когда вы к ней обращаетесь. У вас есть.
В качестве примера возьмем Redis, если пользователь зашел сегодня один раз, установите ключ с пользователем в качестве измерения в Redis.
Это действительно круто, это так просто, а потом мы играли в свое удовольствие.Вдруг, в один прекрасный день, эксплуатация и обслуживание нашли вас и сказали, что сервис Redis переполнен и памяти не хватает. Что за черт? Вы подняли голову и подумали про себя, ваши пользователи100 миллионов пользователей.
Планируется, что пользователь занимает 14 байт, 14Б*100000000/1024/1024=1335МБ, пойду, такая маленькая функция будет занимать минимум 1Г памяти.
Способ 2 (структура данных Bitmap)
Для достижения такого небольшого эффекта тратится 1G драгоценного места в памяти Redis, что явно того не стоит. Есть ли способ или структура данных для достижения того, чего я хочу достичьЭффект всплывающего окна раз в день, и можетМинимальное использование памяти.
В это время вы внезапно думаете об уникальном идентификаторе пользователя (uid), который представляет собой целое число, увеличивающееся от 0 до 1 миллиарда.всплывающее окно раз в деньСоответствует двоичному значению 01. Можете ли вы выделить большой массив? Значение массива является логическим значением. В это время вы внезапно думаете о структуре данных Bitmap Redis.
Глядя и вычисляя, пользовательский идентификатор пользователя составляет 1 бит, 100 миллионов пользователей, примерно: 100000000b/8/1024/1024 = 11 МБ. На данный момент функции, требующие 1 ГБ памяти, теперь могут храниться всего в 11 МБ.
Способ 3 (фильтр Блума)
Вы думаете, что все кончено, пока вы не используете растровое изображение для решения проблемы? Что, если теперь есть более одного бомбардировщика, скажем, 1000? Или уникальный идентификатор пользователя не является автоматически увеличивающимся целым числом. Как с этим бороться в это время?
Если мы готовы пожертвовать меньшей точностью ради большего объема хранилища, вы можете рассмотреть фильтр Блума.
На основе выделения большого битового массива в схеме 2 сохраняемый uid или ключ преобразуется в разные биты с помощью нескольких хеш-функций.
Одним из преимуществ этой схемы является то, что десятки МБ памяти могут хранить миллиарды данных для дедупликации суждений. Недостатком, конечно, является то, что в жертву приносится небольшая точность.
Вариант 4 (переднее хранилище)
На основе приведенных выше трех схем мы обнаружим, что если мы подумаем об этих методах управления памятью, мы думаем, что старые клетки будут много умирать. Есть ли простой и эффективный способ?
Если продукт не требует, чтобы пользователь играл только один раз в день, можно ли передать эту задачу управления интерфейсу, например, сохранить его в файле cookie или локальном хранилище? Таким образом, не нужно беспокоиться о проблеме. памяти хранения.
Но у этого есть тот недостаток, что если пользователь откроет его в другом клиенте (H5 или APP), это будет много раз в день, и управление может быть не таким точным.
Не существует идеального технического решения, есть только наиболее подходящее техническое решение.
На этом этапе вводится метод управления частотой. Надеюсь, это поможет вам.
Смотрите все здесь, обратите внимание на общедоступный номер