По сути, диспетчер действительно просто объединяет в себе все части кроме веб-интерфейса.
Плюс делает какие-то доп.вещи, например, пишет логи ответов от платежных систем в едином формате.
В качестве аналогии приведу пример: есть наковальня, есть молот, есть изделие. Диспетчер — это кузнец. Или кузнецы, в зависимости от нагрузки.
С какой целью?
В описанную схему ОСМП не вписывается, в качестве моментальной системы оплаты — тоже.
Всё равно придется переться куда-то еще.
Про осмп написано в полной версии статьи, где и первый способ взаимодействия описан.
В очереди, например, char(2). Почти 1300 статусов хватит за глаза.
Пары символов достаточно, чтобы примерно понять статус заявки, если приспичит сделать прямой SELECT.
Быдлокодинг — это программирование без включения головы.
Для данных, которые статичны 99% времени жизни проекта, Вы предлагаете плодить сущности в базе. Причем получать эти данные будете исключительно в веб-интерфейс и устанавливать из него же или из диспетчера. Что мешает завести конфиг (функцию, хэш, константы, что угодно), в котором хранить описание статусов и их коды?
Надо запихать статус в базу — взяли из конфига, запихали.
Надо вывести из базы, вывели построчно, в каждой строке заменили на текстовое представление если нужно.
Тем более, этих статусов по пальцам: «новая», «доставлена в ПС», «можно платить», «какая-то ошибка» (2-3 кода за глаза, дальше все равно в логи диспетчера лезть), «отказ платить», «отмена администратором», «устарела», «оплачена», «услуга оказана». Все остальные статусы — уже излишества. Итого 9-11 кодов максимум. И ради этого городить огород с таблицами, джойнами?
А историю статусов хранить не нужно?
Я считаю, что нет.
Там цепочка простая и часто однозначная: новая → в ожидании → ошибка
или новая → в ожидании → готово → изменился статус → выполнили услугу.
Вот логи диспетчера нужны обязательно.
Включая тексты ответов платежной системы.
Вы не знали, как внедрить карты, а кто-то не знает, как правильно спроектировать подобную систему и в итоге для каждой новой платежной системы Магазин пишет свой костыль. Никто не знает всего, правда?
Тут дело не в том, выпускают ли они карты.
А в том как ими пользуются люди.
Для многих если карта и есть, то, как правило, — это способ получить зарплату и обналичить в банкомате.
У меня, к сожалению, нет данных в каких регионах люди платят картами лучше или хуже.
За такой статистикой нужно к платежным системам обращаться или к тому же Киберплату, Хронопэю или Ассисту.
ОСМП работает по первому методу — с сообщением результатов операции на сайт Магазина.
Я не описывал этот метод, по сути он сводится к еще одной функции веб-интерфейса: определение какой терминал сообщает об оплате, вызове библиотеки, которая обработает этот вызов и вернет номер заявки в нашей системе (если мы опять организовали очередь). Далее библиотека работы с заявками поменяет статус. Фсё.
Но в целом, конечно, хорошо уметь принимать и пластик.
Чем больше методов (я не беру всякую экзотику), тем легче «окучить» пользователя и побудить его оплатить что-либо.
У самого пробег порядка 20 тыс км, т.е. имею некоторый опыт по теме.
Мсье мастер спорта по легкой атлетике?
20 тысяч для вашего возраста — это интенсивность 400–500 км/в месяц в течение последних 2-3 лет.
Более чем достаточно, чтобы стать мастером спорта.
200 км/месяц — норма среднего перво-второразрядника с беге на средние дистанции.
Нет, если постоянно контролировать ритм дыхания.
В этом плане полезно дышать не равномерно, а например, так:
два коротких вдоха, выдох, длинный вдох, выдох.
Можно частично заменить бегом с ускорениями, из круга на стадионе 100-200 с ускоряемся, затем 300-200 метров «отдыха» с обычной скоростью
Тут разные подходы есть.
Я б рекомендовал сериями 100-200-300-400-300-200-100.
И ровно такие же промежутки после каждого этапа ускорения, но не «обычной скоростью», а трусцой 4-5 км/ч.
Или еще вариант — «минута через минуту» 3-4 раза в серии.
Но не в коем случае не чаще 1-2 раз в неделю.
2-3 раза мы бегали при интенсивности 10 двухчасовых тренировок в неделю.
Правда, все это подразумевает нагрузки сверх описанного + желательно стадион.
Мой вам совет:
1. Уберите каунт — лучше обойтись экзистом или вообще вывалиться по no_data_found
2. Откажитесь от явного объявления курсоров.
3. Коммиты скидывайте пачками
4. Вместо установки флагов, лучше пользовать exception
Плюс делает какие-то доп.вещи, например, пишет логи ответов от платежных систем в едином формате.
В качестве аналогии приведу пример: есть наковальня, есть молот, есть изделие. Диспетчер — это кузнец. Или кузнецы, в зависимости от нагрузки.
В описанную схему ОСМП не вписывается, в качестве моментальной системы оплаты — тоже.
Всё равно придется переться куда-то еще.
Про осмп написано в полной версии статьи, где и первый способ взаимодействия описан.
В очереди, например, char(2). Почти 1300 статусов хватит за глаза.
Пары символов достаточно, чтобы примерно понять статус заявки, если приспичит сделать прямой SELECT.
Нет, в коде писать
print $status_list->{ $status } || 'Неизвестный статус';Быдлокодинг — это программирование без включения головы.
Для данных, которые статичны 99% времени жизни проекта, Вы предлагаете плодить сущности в базе. Причем получать эти данные будете исключительно в веб-интерфейс и устанавливать из него же или из диспетчера. Что мешает завести конфиг (функцию, хэш, константы, что угодно), в котором хранить описание статусов и их коды?
Надо запихать статус в базу — взяли из конфига, запихали.
Надо вывести из базы, вывели построчно, в каждой строке заменили на текстовое представление если нужно.
Тем более, этих статусов по пальцам: «новая», «доставлена в ПС», «можно платить», «какая-то ошибка» (2-3 кода за глаза, дальше все равно в логи диспетчера лезть), «отказ платить», «отмена администратором», «устарела», «оплачена», «услуга оказана». Все остальные статусы — уже излишества. Итого 9-11 кодов максимум. И ради этого городить огород с таблицами, джойнами?
Я считаю, что нет.
Там цепочка простая и часто однозначная:
новая → в ожидании → ошибка
или
новая → в ожидании → готово → изменился статус → выполнили услугу.
Вот логи диспетчера нужны обязательно.
Включая тексты ответов платежной системы.
Именно это я и понимаю под «первым методом» — когда обмен информацией начинается с платежной системы.
А в том как ими пользуются люди.
Для многих если карта и есть, то, как правило, — это способ получить зарплату и обналичить в банкомате.
У меня, к сожалению, нет данных в каких регионах люди платят картами лучше или хуже.
За такой статистикой нужно к платежным системам обращаться или к тому же Киберплату, Хронопэю или Ассисту.
Впрочем, статья-то не об этом, правда?
Я не описывал этот метод, по сути он сводится к еще одной функции веб-интерфейса: определение какой терминал сообщает об оплате, вызове библиотеки, которая обработает этот вызов и вернет номер заявки в нашей системе (если мы опять организовали очередь). Далее библиотека работы с заявками поменяет статус. Фсё.
Описанные методы взаимодействия с ПС и организация обработки характерны не столько для Магазинов, сколько для агрегаторов вроде Robox'а.
Чем больше методов (я не беру всякую экзотику), тем легче «окучить» пользователя и побудить его оплатить что-либо.
Мсье мастер спорта по легкой атлетике?
20 тысяч для вашего возраста — это интенсивность 400–500 км/в месяц в течение последних 2-3 лет.
Более чем достаточно, чтобы стать мастером спорта.
200 км/месяц — норма среднего перво-второразрядника с беге на средние дистанции.
Урежьте-то цифру.
Нет, если постоянно контролировать ритм дыхания.
В этом плане полезно дышать не равномерно, а например, так:
два коротких вдоха, выдох, длинный вдох, выдох.
Если добровольно — таки да, привыкание гарантировано.
Я уже 6 лет как ушел из спорта, а подсознание помнит… Сны показывает :)
Видимо, только в школе и были.
Подготовка спринтера обязательно включает в себя кроссы несколько раз в неделю.
Тут разные подходы есть.
Я б рекомендовал сериями 100-200-300-400-300-200-100.
И ровно такие же промежутки после каждого этапа ускорения, но не «обычной скоростью», а трусцой 4-5 км/ч.
Или еще вариант — «минута через минуту» 3-4 раза в серии.
Но не в коем случае не чаще 1-2 раз в неделю.
2-3 раза мы бегали при интенсивности 10 двухчасовых тренировок в неделю.
Правда, все это подразумевает нагрузки сверх описанного + желательно стадион.
1. Уберите каунт — лучше обойтись экзистом или вообще вывалиться по no_data_found
2. Откажитесь от явного объявления курсоров.
3. Коммиты скидывайте пачками
4. Вместо установки флагов, лучше пользовать exception
официально
на Хабре