Как спроектировать real-time списывание денег со счета пользователя?

Question

[psylosss]

Добрый вечер, коллеги!


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

Есть некий сервис, назовем его «платное размещение объявления». Стоимость размещения фиксирована (скажем, 100 рублей в сутки). Пользователи пополняют баланс и включают-отключают свои объявления. Причем помимо ручного включения-отключения существует еще масса критериев, по которым объявления могут включиться или отключиться.

Задача состоит в том, чтобы показывать объявления пользователя только тогда, когда на его счете есть деньги. Как только деньги закончатся, в ту же секунду объявления должны перестать отображаться на сайте. Как только счет будет пополнен, отображение должно мгновенно возобновиться.


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

Плохие решения.


1. Запуск по CRON'у ежесекундно пересчета остатков на счетах всех пользователей. Не подходит — слишком ресурсоемко.


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


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


Сайт написан на РНР (symfony 1).

Answer 1

[strib]

Прямо посекундная тарификация?
Если не секрет, то расскажите, пожалуйста, что за сервис.
Аналог из отрасли где это все стандартизировано и отработано.
В связи существует 2 метода оплаты: postpaid и prepaid. Postpaid — это грубо говоря счет, который может уходить в минус, в данном случае мимо.
Prepaid. Это тот способ который берет деньги до начала услуги, поэтому при приблежении к 0 отключает сервис. К примеру в ряде стран законодательно запрещено уводить препейдного абонента в минус, но это лирика.
Так вот, prepaid бывает двух типов (основных, на самом деле есть еще)
IEC — Immediate Event Charging и ECUR — Event Charging with Unit Reservation.
В первом случае, при возникновении события, происходит запрос к счету, счет проверяется и от него отпиливаетя стоимость услуги, после чего возвращается положительный ответ и событие продолжается. Проблема, завязка на единицу тарификации, если выбрать маленькую (секунду) — то очень ресурсоемко получается, а если квоту увеличить (до минуты) — то при отказе от услуги на 35й секунде средства за 25 секунд пропадут. Знакомая ситуация наверное…
Второй метод интереснее.
Выбирается 2 параметра. Размер квоты и единица тарификации, допустим 1 минута и 5 секунд. Событие инициируется, происходит запрос к счету, на счете блокируется сумма, и возвращаеся ответ, который содержит объем доступный для услуги (в примере время, а могут быть байты, клики, слоны...) И услуга начинает предоставляться. Как только заканчиваются ресурсы, к счету опять происходит обращение, в котором говорится о том, что ресурсы израсходованы, и хочу еще (ну или не хочу), в этом случае со счета списывается разервированная сумма, и резервитуется следующая квота. Если услуга прекращается до исчерпания квоты, то время округляется ввепх до единицы тарификации (с 32 секунл до 35) и списываются деньги только за 35 секунд, за 25 возвращаются.
Это как организуется работа со счетом.
Совсем подробно можно почитать вот тут www.3gpp.org/ftp/Specs/archive/32_series/32.299/32299-700.zip Пункт 6.3.2, пугаться не надо, картинки понятные.

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

Comments

[strib]

И абсолютно пофиг на каком языке это написано. Хотя php и посекундная тарификация — несколько несовместимо…

[psylosss]

Да, прямо посекундная тарификация. Prepaid с элементами postpaid (сейчас не говорю об этом, чтобы не загромождать объяснения, но сути это не меняет). Вот вся проблема как раз в «счет проверяется». Как узнать текущий остаток пользователя в данную секунду?

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

[strib]

Ответ растянется на хорошую книгу.
Кратко. Счет — это сложный объект. Состоит из основной суммы и открытых транзакций, в случае с ECUR. Транзакции резервируют средства. Могу дать ссылки на литературу, но надо будет переделывать и отказываться от PHP, т.к. добиться от него предсказуемого времени ответа будет очень сложно.
И не бывает простых решений с посекундной тарификацией и четким пониманием остатка. Даже операторы с их ресурсами не все могут себе такие решения позволить.
Без нормального описания ничего не смогу описать подробнее.

[psylosss]

Я уже готов отказаться от всего что используется сейчас :) и от РНР, и от всего. Я осознаю всю сложность каши, которую заварил, но решение все-таки требуется. Ирония в том, что сейчас посекундная тарификация работает и стабильно. Единственное что мне не нравится — это чрезмерная сложность (логическая) получившейся системы

Answer 2

[lesha_penguin]

> Стоимость размещения фиксирована (скажем, 100 рублей в сутки).

Тогда в чем проблема?

Сколько времени минимум должно провисеть данное обьявление всегда известно!

Этот параметр меняется в меньшую строну при размещении еще одного обьявления тем же юзером.
Этот параметр меняется в большую сторону при «пополнении баланса» и при снятии других обьявлений.

Так что событийная модель обработки данных вполне решит вашу проблему.

Comments

[psylosss]

В том-то и дело, что это время не известно. Сейчас оно одно, а через час — другое (т.к. пользователь включил еще 10 объявлений).

[edogs]

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

[lesha_penguin]

У обьявления добавляете аттрибут «дата до которого оно размещено». Во-первых, для самого пользователя это добавит элемент прозрачности и управляемости, что всяко гут. А во-вторых, с вас снимет Кучу гемороя. В третьих, в этом ключе даст возможность правильного взаимодействия.

[lesha_penguin]

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

[psylosss]

Именно таким образом и решено сейчас: у объявления есть параметр «дата окончания срока действия», который пересчитывается при любом внешнем воздействии на состояние счета пользователя. Это как раз п.2 из «плохих вариантов».

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

[psylosss]

Сейчас реализована посекундная тарификация. Это действительно необходимо. Реализована она как раз на событийной модели. Но все усложняется тем, что есть такие события, которые также не предсказуемы. Например, включение объявлений по расписанию, которое задается (и изменяется) пользователями. Все это сделано, но поддерживать такую конструкцию весьма тяжело. Отсюда и сабж…

[lesha_penguin]

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

[psylosss]

Пользователям нравится текущая система. Но ее сложно развивать. От погоды на марсе время не зависит. Но пользователем может быть составлено расписание включения-отключения. А эти вещи уже в событийную модель не очень вписываются. Приходится делать так, как предложил edogs: пересчитывать предполагаемую дату окончания размещения (время когда на счете пользователя останется 0 рублей) каждый раз, когда что-то меняется. Но опять-таки, учитывая расписание включения-отключения это становится адской конструкцией.

[lesha_penguin]

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

[psylosss]

Во время срабатывания «времени запуска» объявления не происходит никакого события. Поэтому не вписывается.

[Tramvai]

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

[psylosss]

Tramvai, триггер вешается на событие. В случае включения объявления по расписанию никакого события не происходит

[lesha_penguin]

У вас какой квант «запуска по расписанию»? Если например, минута или тем более час, то сделать наступление момента времени «событием».

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

[Алексей Сундуков]

>Во время срабатывания «времени запуска» объявления не происходит никакого события.
Поддержу lesha_penguin. В том, что при запуске объявления не происходит ни какого события и есть архитектурный просчет из-за которого систему сложно поддерживать. Должно быть событие «запустить объявление в показ». Запуск можно делать через крон (минутных интервалов для объявлений должно более чем хватить, посекундная тарификация при показе объявлений на сайте выглядит бредом).

[psylosss]

Насколько я понял, суть вашего решения сводится к изменению требований. К сожалению это недопустимо.

Answer 3

[Sekira]

Предлагаю такой вариант:
Нужно не объявления включать/отключать, а баланс пользователя проверять, если <=0, то не показывать.
А объявления выбирать для показа, где баланс >0 и объявление включено пользователем + критерии.
То есть поле включено/отключено должен менять только пользователь, а не масса критериев.
Критерии должны быть прописаны в самом объявлении.

Comments

[psylosss]

Отличный вариант! Осталось только узнать сколько денег в данную секунду на счете пользователя ;)

[Sekira]

Это делается элементарно, например MySQL:

SELECT `ads`.*, `users`.`balance` FROM `ads` JOIN `users` ON `ads`.`user_id`=`users`.`user_id` WHERE ...ваши условия...

Answer 4

[KawaiDesu]

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

Comments

[psylosss]

Да, нужно чтобы сервис в любую секунду знал текущий баланс

Answer 5

[Сергей Соколов]

Только «события»: старт, стоп, ручной пуск нового оъявления, пополнение счёта — всё, что изменяет прогноз по деньгам, запускает событие, по которому обновляется дата-время окончания денег на счете, по которой сервер выключит показ.

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

Включение, из состояния «выкл.», возможно только по событию пополнения счёта.

Comments

[psylosss]

Есть еще «события» включения и отключения по расписанию. В них основная проблема событийной модели

[Сергей Соколов]

Не понимаю, в чем с ними проблема. Как реализовано включение по расписанию?

[psylosss]

Не существует такого события как «запуск показа объявления по расписанию». Например, пользователь записал включение объявления на 12:00 завтрашнего дня. Завтра в 12-00 не запускается никакой скрипт, никакое событие не вызывается

[strib]

А как оно тогда раотает? Хоть что-то же должно происходить?

[psylosss]

Ничего не происходит в 12-00. Просто при выборке объявлений к показу учитывается расписание и даты предполагаемого окончания средств на счетах пользователей. Это работает, но это сложно.

[Сергей Соколов]

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

[psylosss]

Да, именно такой вариант и был предложен выше. Сейчас как раз прорабатываю его детали. Только вот этот скрипт придется запускать слишком часто — 1 раз в секунду. Также здесь есть еще один подводный камень: снижается стабильность системы. Что произойдет, если по каким-то причинам скрипт не будет запущен? Ну, скажем, сервер перезагружался.

[Сергей Соколов]

Какое бы «real-time» решение ни было, оно всегда квантизируется по времени: минимальный шаг минута, секунда или одна миллиардная для гигагерцового процессора. И в любом случае работает модель событий или состояний, на том или ином уровне: приложения, ос, процессора.

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

Чтобы облегчить систему от избыточного повторения действий, стоит где-то под рукой держать состояния её отдельных частей: будь то представление каждого из объявлений, текущее состояние счёта. Те могут обновляться своими «часами», может, реже, может, чаще.

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

Answer 6

[ComodoHacker]

Одно из решений — пересмотреть модель биллинга. Ввести понятие резервирования средств. Пользователь, добавляя объявление, сам указывает, на какой срок его включить, например на 1 сутки. И соответствующая сумма резервируется, если она есть на счету и не зарезервирована, еще до показа объявления. Таким образом, мы заранее знаем момент, когда показ объявления нужно отключить. А необходимость проверять баланс каждую секунду отпадает.

Comments

[psylosss]

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

[ComodoHacker]

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

[ComodoHacker]

Если же такой негарантированный показ «если есть деньги» пользователей устаривает, то его можно раелизовать так. Периодически (раз в час например) запускается «планировщик» и производит распределение имеющихся ресурсов (денег) по задачам (активным объявлениям) на ближайший час. Алгоритм выбирайте сами. Например, первыми получают показы объявления, поданные раньше. Или еще как-то.

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