Как гарантировать списание денег с баланса?

Question

[# a r t u r #]

Здравствуйте!

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

Есть 2 способа:

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

Что касается CRONа, мы тут обсуждали, и сразу вопросы: а что если сервер упадет, а что если крон выполнится несколько раз и т.д., я понимаю, что можно мутить с историей списание (она полюбому нужна), и при списании сверяться, но это не дает гарантии от параллельного списания.

Хочется услышать мнение тех, кто уже проходил это, интересует сама логика и инструменты. Спасибо!

Comments

[alex-1917]

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

[# a r t u r #]

У меня с кодом проблем нет, проблема с логикой, перед тем как писать код нужно заранее понимать как он будет работать.

Answer 1

[Павел Новиков]

Вам нужен Cron для такого чего-то.

что если крон выполнится несколько раз

- это говорит о том, что вы не до конца понимаете, как работает крон, вам нужно почитать доки. Крон - это серверный демон, он выполняется сугубо по определенным датам/времени, вернее он вызываает команду, которая должна исполняться. нет возможности, чтобы крон выполнился 2 раза за день, если сконфигугрирован выполняться 1 раз в день.

а что если сервер упадет

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

Comments

[# a r t u r #]

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

1. Берем юзера и сумму для списания
2. Проверяем было ли списание сегодня или нет
3. Если списания не было, то списываем
4. Заносим данные о списании в лог
следующий...

Сразу начинает парить шаг 2 - какая дата списания должна быть чтобы скрипт понял, что деньги списывались за последние 24 часа? Получается в лог нужно записывать данные со смещением в 30 минут в прошлое? а крон настроить на запуск скажем в 00:10 ежедневно, скрипт будет проверять были ли списания за последние 24 часа - я так понимаю?

[Павел Новиков]

# a r t u r #,

меня беспокоит, что крон не отработает всех юзеров по каким-то причинам, а при повторном запуске начнет все сначала

- вы же понимаете, что крон - это всего лишь демон, который запускает указанный вами скрипт в указанное время и на этом его работа заканчивается. Никакой бизнес-логики он не содержит в себе, равно как и не отвечает за то, как именно будут списаны или не списаны средства - это все зависит от того, как вы напишете код.
По поводу запросов к БД - все упирается в то, какая структура у вашей бд, используете ли вы кеширование базы, как вы оптимизируете запросы.
Что касается вашего конкретного случая, то достаточно сконфигурировать крон на запуск каждый день в полночь, при запуске скрипта создавать новый объект класса \DateTime(), который записывать в переменную $currentTime (допустим, вы пишете в ПХП). В таблицу пользователей или где там вы храните данные о списании я бы добавил поле lastChargeFee, допустим, которое бы апдейтил при каждом списании:
допустим вы настроили таск крона так чтобы он запускался в полночь каждый день, тогда дата списания в базе будет для первого списания 01.07.18. Когда крон запускает скрипт на след день, он доложен сравнить по базе текущую дату (2.07.18) с теми, которые есть в поле списания у каждого пользователя и если даты не равны - списать и обновить дату. Если даты равны - ничего не делать. Никаких смещений в прошлое не нужно. В логи стоит писать все действия чтобы потом было легко отследить, что было списано, когда и у кого.
Ну это если очень кратко попытаться донести вам свою мысль )

[# a r t u r #]

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

Answer 2

[Олег]

Они Вам нужны 30(31) * число клиентов записей списаний.

Дано :
Баланс на начало месяца.
Получено в этом месяце.
Услуга 1 АКТИВНА: 300 рублей / месяц
Услуга 2 АКТИВНА : 100 рублей / месяц
Услуга 3 ЗАКОНЧЕНА (5 числа) : 100 рублей / месяц
Услуга 4 ПОДКЛЮЧЕНА ( 20 числа): 300 рублей / месяц

Прошло дней с начала месяца
Дней в месяце

Баланс = Баланс на начало месяца + Получено в этом месяце
- 300 / Дней в месяце * Прошло дней с начала месяца
- 100 / Дней в месяце * Прошло дней с начала месяца
- 100 / Дней в месяце * min ( день завершения, Прошло дней с начала месяца)
- 300 / Дней в месяце * max(0, ( Прошло дней с начала месяца - число подключения ))

в результате нужно будет только раз в месяц обработку базы делать

Comments

[# a r t u r #]

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

[Олег]

баланс на 7 дней вперед = Прошло дней с начала месяца + 7

А как Вы будете считать его при вашем подходе ?
текущий < меньший средне потолочное ?
или для каждого сравнивать с прогнозом на оплату услуг за 7 дней ?

[# a r t u r #]

Олег Муравейко, ну тут уже второй скрипт должен запускаться на уведомления, который вероятно будет брать балансы юзеров и общую сумму их ежедневных платежей, делить одно на другое, если меньше 7, то слать уведомление - я так это вижу... м?

[Олег]

Делайте как считаете нужными.
Чтобы списание не прошло дважды.
Заносите его в таблицу с уникальным составным ключом.
Контроль за тем, что скрипт списания отработал возложите на "сторожевую собаку"
скрипт который запускается позже .
Например в 1:00 стартует списание. Отработает оно за 45 минут. И пишет, что все хорошо или были ошибки
"сторожевая собака" запускается в 2:00 и если нет успеха - уведомляет саппорт.

[# a r t u r #]

Олег Муравейко, "с уникальным составным ключом" - можно пример?

[Олег]

ключ по полям типа уникал
когда(Date) клиент(Int) услуга(int)
в результате с клиента можно списать плату за услугу только один раз в день

Answer 3

[Максим Федоров]

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

Comments

[# a r t u r #]

В случае с транзакциями скрипт просто отбросит операцию и деньги не спишутся... я так понимаю?

Answer 4

[Максим Тимофеев]

1. CRON

а что если сервер упадет

Другие решения при упавшем сервере по Вашему будут отлично работать?

а что если крон выполнится несколько раз

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

что можно мутить с историей списание (она полюбому нужна), и при списании сверяться, но это не дает гарантии от параллельного списания

Почему это не дает гарантии? Если есть запись о списании в этом месяце - не списываем. Как это может не работать? Вижу только вариант с коллапсом вселенной или временной отменой "1+1=2".

интересует сама логика и инструменты

Инструменты: cron + php
Логика: запустились, выбрали из базы кого списывать, списали, записали в БД что списали и сменили статус на оплачено. Опционально, ведем отдельный лог в txt файле, что когда и как.

Answer 5

[Александр Аксентьев]

а что если

так до бесконечности можно, нужно просто сесть и начать делать.

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

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