Работаю с Liberty API и могу сказать, что обработку платёжки на бирже явно писали идиоты.
Это вообще касается работы с любой платёжной системой — намалюют абы как (или поставят стандартный скрипт-пример от самой платёжки) и потом удивляются.
Для того, что бы такого не происходило, желательно по возможности заюзать следующие советы (некоторые системы не поддерживают определённый функционал, либо наоборот имеют дополнительные средства — в любом случае стоит их использовать по максимуму):
Использовать HTTPS
Устанавливать ссылку на обработчик нотификаций в настройках мерчанта и никогда не ставить его в виде параметра в форме (не для всех платёжек такое возможно, но их слава богу мало).
Не держать обработчик нотификаций на том же домене и с очевидным адресом. Сделайте пару неговорящих ни о чем поддоменов и используйте один из них, либо зарегистрировать вообще отдельный домен под это дело. Путь к скрипту обработки не должен угадываться на раз, все попытки неправильных запросов отфутболивать как 404.
Внимательно проверять статусы транзакций, соотвествие валют, соотвествие суммы записаной в транзакции и той, что пришла в нотификации.
Обязательно вести лог действий над транзакцией, любые несоотвествия нещадно и подробно логировать. Потом спасибо сами себе скажите.
Ограничить доступ по IP, что-бы доступ имел только сервер платёжной системы. Но нужно учитывать, что иногда IP меняются, так что нужно обязательно нотифицировать себя при несовпадении и подробно логировать то, что пришло, что бы обработать транзакции в ручную если нужно (и хотя обычно платёжки повторяют запрос через некоторое время, надеятся на это не стоит).
У большинства платёжек можно задавать свои кастомные поля — используйте их. Впихните туда 1-2 хеша посложнее (только не MD5, а что-нить типа SHA256 или покруче) с параметрами, о которых знает только ваша система и они нигде публично не фигурируют, да и алгоритм составления этого хеша узнают только если вас капитально сломают и утянут код — эти хеши очень сильно повышают надёжность транзакций, т.к. если хоть один параметр не совпадёт — хеш валидацию не пройдёт.
Статусы транзакций должны быть реализованы таким способом, что бы если нотификация пришла и была успешно обработана и получила финальный статус success/failed — то сменить скажем failed на success уже нельзя было бы через нотификацию, если кто-то всё же сумеет подделать запрос. Само собой нужно учитывать особенности самой системы — бывают и chargeback, и всякие pending и тому подобное. Так же бывает что failed реально может смениться на success — в таких случаях саппорт должен быть нотифицирован и транзакция должна проверяться в ручную.
В некоторых платёжках доступен API для работы с историей операция — юзайте! Это весьма надёжный способ проверить, а был ли мальчик
То что он для WEB, не мешает на нём отлично писать консольные скрипты и приложения, т.к. с PHP 5.3 допилили менеджер памяти, добавили сборку мусора и вообще довели CLI до состояния, когда оно особо то и не отличается от того же голого python или ruby. Другое дело что наработок и библиотек практически нету, но это не вина самого языка. Да и нету такой большой необходимости этим заниматься вне WEB проектов. А когда у вас WEB проект, да на Zend/Symphony/Yii, то там есть консольные компоненты и утилиты для запуска таких процессов в контексте проекта (насчёт Zend не уверен, Symphony насколько я знаю такое имеет, а с Yii сам работаю и у него есть 2 вида компонент: CConsoleCommand и CConsoleApplication). Они просты и большее от них редко требуется. А мне вот потребовалось и я быстро и легко допилил себе консольный демон с форками, сигналами и прочей лабудой — пиши тока логику и не парься — ничего сложного там нету. Нужно просто знать и понимать как нужно писать приложения такого рода.
Код у автора статьи далеко не лучший пример — это скорее показать что можно, но дальше нужно думать самому. Да и без фреймворка будет уныло.
Боже, пошли заказчика, который после таких писателей в отчаении обратится и заплатит и так не дешовый рейт * 3, лишь бы исправить проблемы и вернуть проект к жизни.
Я даже не хочу пояснять в чем тут проблема, ибо ответы очевидны — дам лишь намёк: у вас поток в 2-3 тысячи запросов в секунду и тут кеш протухает…
Погонял сегодня, советую присмотреться. Только учтите, это Альфа, так что глюки и баги не просто возможны — они обязаны быть. Но к чести разработчиков — играется без проблем, если не тыкать лишние опции и кнопки. Ездит отлично, стреляет отлично, в режиме артилерии пуляет на ура. Для альфы очень хорошо, но до беты там ещё работать и работать. Оптимизаций ещё море сделать предстоит.
Они вообще хотят поменять лексер на более современный, ибо тот что сейчас не способен справится с новыми веяниями, у него нету контекста — отсюда и проблемы с тем, что некоторые вещи очень проблемно реализовать.
Если мне память не изменяет, то хотят на lemon parser пересесть и какая-то работа за кулисами там шла, но инфы почти нету.
Про нервы и деньги это в точку.
Я почти не делаю сторонних заказов именно по той причине, что мне мои нервы мне важнее. Иногда попадаются неплохие заказы — и работа интересная, и мой начальный ценник людей не смущает (а беру я минимум ~400$, даже если работы на 2-3 часа) — такие просто знают, что им нужно и не доставляют никакой головной боли — чёткая задача + качественная реализация = все довольны. Бывает что ещё и сверху накинут прилично если работа понравилась.
В данном примере при создании модели она будет обращаться в базу за своей структурой. Кеш её считывание и разборку уберёт, позволив быстро создать нужные внутренние объекты.
Так да, но зато у них ограничение в 150KB :( Мне вот помешало это пару картинок оптимизировать сейчас когда тестировал.
Я просто брал заливал по 20 картинок за заход на tinypng.org. Ограничение кстати касается только единовременной заливки, а если обработалось 20 штук и залить ещё 20 без обновления страницы — всё отлично пашет. Минус только один — нельзя скачать архивом всё сразу.
Учитывая реалии сегодняшнего дня, в вашем тесте есть пара фундаментальных недоработок:
PHP 5.4 — нужно использовать его, т.к. в нём весьма прилично оптимизировали объекты. Как по CPU, так и по памяти. Разница достаточно сильная.
ActiveRecord читает метаданные таблиц по умолчанию из базы на каждый экземпляр объекта. schemaCachingDuration вам в помощь, поскольку без него и так понятно, что всё будет мрачно.
Потеря удобства разработки, причём это может сказаться на времени исполнения крайне негативно.
Ну и в реальности никто не будет перебирать такие объёмы через AR если есть требования к скорости выполнения, а так же скушает слишком много памяти.
Всё, punypng по сравнению с этим фигня, но они только оптимизировали. А эти перегоняют в более лёгкий формат — все картинки что протестил ужались минимум на 64%, среднее 70% экономии для 24 битных PNG.
Очень зря. Даже тогда, лет 5 назад, он нас очень сильно удивил и позволил не заниматься разработкой собственных кеширующих сервисов, как это происходит почти с любой социалкой, которая вырастает в прибыльный проект. Начальное тестирование на живую показало возможности масштабирования во всей красе — было у нас там пару тяжелых мест, которые обычный MySQL (InnoDB, 2 x 4 Quad Core, 16 GB RAM при базе в 5 гигов, основательно отюнингованный под проект) мог обслужить в районе 50-60 rps на конкретной странице (мерили через JMeter и грузили живую систему, поэтому там по статистике SQL обслуживал порядка 3к запросов в секунду). Перенос нескольких критичных мест на NDB (ествественно с переделанными запросами, но логика кода 1 в 1 осталась — поменялся только SQL) за несколько минут дало разогнаться JMeter до 400 rps и росло по мере прогрева кластера.
Так что если вам приходится иметь дело с большими нагрузками на базу — очень стоит тестировать. И ведь он не только чтение масштабирует, но и запись. Если у вас поток данных входящий больше чем способна записать физическая машина — репликация вообще не поможет. Или read/write может быть таким, что репликация будет работать на пределе своих возможностей и грузить записью все ноды так, что сильно скажется на скорости чтения.
Я вот лично жалею что мне не приходится работать с NDB Cluster больше — нету таких проектов у меня, где применить. А хочется :)
Да неплохие машинки вообще, я на своём на XP просидел наверно лет 5-6 пока не купил уже новый компъютер. Изначально там было 128 метров, расширил до 387 MB память, шину поставилc 100 на 133 (получил 433 MHz процессор). А самое класное в нём было то, что там стоит Creative Sound Blaster Live! 1024 — зверь карточка :)
Так же в оригинале была Riva TNT 2 :)
Насчёт редких кейсов я бы поспорил, он довольно много куда пойдёт. Проблема там скорее в другом — кластер это 5 и более машин, а такие мощности не так уж часто нужны, вот и применяют его редко. Но если проект приличных масштабов, то определённо есть смысл его использовать.
Про MySQL NDB Cluster враки. Мы его в боевых условиях для социальной сети 5 лет назад уже использовали. Конечно, тупо перекинуть таблицы ALTER TABLE `bla` ENGINE=NDB и ожидать чуда не получится (однако с тех пор судя по анонсам проблемы с JOIN и многие другие успешно решили). Но если применить здравый смысл, понимать что у вас сетевой кластер (смотрите коммент под спойлером), хорошо проверить свои запросы — то отличная штука, которая позволяет перемолоть очень большой поток запросов.
Конечно не каждый запрос можно легко перенести, некоторые вообще не переносятся, но учитывая что NDB это просто движок, то в одной базе могут сосуществовать как InnoDB таблицы, так и NDB таблицы. Они даже неплохо используются одновременно в пределах одного запроса, т.е. в приложениях не нужно специально что-то наворачивать. Всё что нужно, это использовать кластер там где надо (т.е. обращаться к NDB нодам), а где не надо — обращаться к обычному MySQL.
коммент про сетевой кластер и джоины
Запрос с десятком сложных джоинов (хватает и 1-2 джоинов, просто на массивные таблицы) по определению не может быстро работать в сетевой среде, ибо temporary таблицы — а значит данные нужно подтянуть с нод. Зато фокус с derived table, т.е. вложенными запросами, отлично сработал и позволил ускорить часть запросов даже по сравнению с InnoDB
Это вообще касается работы с любой платёжной системой — намалюют абы как (или поставят стандартный скрипт-пример от самой платёжки) и потом удивляются.
Для того, что бы такого не происходило, желательно по возможности заюзать следующие советы (некоторые системы не поддерживают определённый функционал, либо наоборот имеют дополнительные средства — в любом случае стоит их использовать по максимуму):
Код у автора статьи далеко не лучший пример — это скорее показать что можно, но дальше нужно думать самому. Да и без фреймворка будет уныло.
З.Ы. А ещё есть phpDaemon
Я даже не хочу пояснять в чем тут проблема, ибо ответы очевидны — дам лишь намёк: у вас поток в 2-3 тысячи запросов в секунду и тут кеш протухает…
Если мне память не изменяет, то хотят на lemon parser пересесть и какая-то работа за кулисами там шла, но инфы почти нету.
Я почти не делаю сторонних заказов именно по той причине, что мне мои нервы мне важнее. Иногда попадаются неплохие заказы — и работа интересная, и мой начальный ценник людей не смущает (а беру я минимум ~400$, даже если работы на 2-3 часа) — такие просто знают, что им нужно и не доставляют никакой головной боли — чёткая задача + качественная реализация = все довольны. Бывает что ещё и сверху накинут прилично если работа понравилась.
Я просто брал заливал по 20 картинок за заход на tinypng.org. Ограничение кстати касается только единовременной заливки, а если обработалось 20 штук и залить ещё 20 без обновления страницы — всё отлично пашет. Минус только один — нельзя скачать архивом всё сразу.
Так что если вам приходится иметь дело с большими нагрузками на базу — очень стоит тестировать. И ведь он не только чтение масштабирует, но и запись. Если у вас поток данных входящий больше чем способна записать физическая машина — репликация вообще не поможет. Или read/write может быть таким, что репликация будет работать на пределе своих возможностей и грузить записью все ноды так, что сильно скажется на скорости чтения.
Я вот лично жалею что мне не приходится работать с NDB Cluster больше — нету таких проектов у меня, где применить. А хочется :)
Так же в оригинале была Riva TNT 2 :)
Конечно не каждый запрос можно легко перенести, некоторые вообще не переносятся, но учитывая что NDB это просто движок, то в одной базе могут сосуществовать как InnoDB таблицы, так и NDB таблицы. Они даже неплохо используются одновременно в пределах одного запроса, т.е. в приложениях не нужно специально что-то наворачивать. Всё что нужно, это использовать кластер там где надо (т.е. обращаться к NDB нодам), а где не надо — обращаться к обычному MySQL.