rPman

Очень важный вопрос, зачем нужны, а точнее как будут использоваться эти цены клиентами и самим сайтом?
Ответ на этот вопрос даст требования к источнику данных и соответственно их выбор.

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

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

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

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

Какого фига вы рекомендуете человеку удалять гланды через задницу. Какой вебсокет в mysql вы что? Какие тригеры.

Бакэнд является единственным, кто должен менять критичнуюинформацию в базе, вот пусть он и рассылает в вебсокет нужную информацию клиентам.

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

Когда клиент дает цену товару, бакэнд смотрит, какие клиенты его покупают и шлет им сообщение. Возможно придется держать в памяти массив - какой клиент в базе = клиент вебсокет, но с вероятностью 99.(9)% это уже сделано (как минимум имя отображать и авторизация)

Я рекомендую не изобретать велосипед, а написать компилятор, который из того что в интерфейсе пользователь накликал, будет генерировать код (на том же php), само собой на серверной стороне,чтобы исключить махинации, а затем этот код запускать с помощью eval. Тогда и скобки красиво отработаете и работать будет быстро, если к примеру это решение где то будет использоваться не только как дать только один раз результат.

По поводу кучи switch или if, они будут по одному case на каждый тип операции, разве их много?

Чтобы обратиться к переменной, имя которой в другой переменной, нужно использовать двойной $

$var1=1;
$var2=2;
foreach(['var1','var2'] as $name) echo $$name;

после 5.6 версии php можно использовать variadic functions

function test(...$params){var_dump($params);}
test(1,2,3);

работает для всех мест использования - функций, методов, замыканий.

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

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

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

Необходимо в документ добавить макросы, которые будут запрашивать необходимую информацию и обновлять документ.

Если надо для каждого файла какие то условия проверять и glob с масками * и ? не подходит то используйте pathinfo, разбирает путь в виде строки и возвращает полезную информацию:
print_r(pathinfo('/path/file.ext.jpg'));

Array
(
    [dirname] => /path
    [basename] => file.ext.jpg
    [extension] => jpg
    [filename] => file.ext
)

С точки зрения нейминга пакетов в OS, php бывает php-cli и просто php. Первый - для запуска из коммандной строки или службы, т.е. просто как скриптовый язык (кстати жутко удобный, имхо удобнее bash, и самый быстрый из существующих в принципе, рядом с ним идет node js но он не такой удобный), второй - для работы web бакэнда.

По факту это один и тот же бинарник но когда запускаешь приложение из командной строки, настройки php.ini берутся из другого каталога (смотреть /etc/php/...).

Можно внутри php файла не указывать <?php но в начале указать по стандарту #!/usr/bin/php и тогда скрипт будет запускаться как любое другое приложение (нужен флаг x на файле) либо использовать <?php и запускать
php файл.php
Второй вариант мне нравится больше, потому что редакторы ide для php чаще ожидают второй вариант а при первом не включают подсветку синтаксиса.

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

Т.е. вам нужны механизмы запуска вашего скрипта в виде службы (или хотя бы пока просто скриптом вручную, я видел примеры когда запускали автоматически внутри screen чтобы можно было мониторить активность простым подключением по ssh), плюс механизмы организации задач в виде списков (самое простое в базе данных) и инструменты нотификации об изменении статуса каждой (окончание или ошибка), например нужно же клиенту сообщить о том что работа завершена (при правильной реализации для этого пользуются websocket)

В терминах базы данных это называется sequence, в каких то это специальный объект с этим именем, значение которого можно запросить и получить следующее, в каких то используется стратегия autoincrement, когда это значение вычисляется автоматически при добавлении в таблицу (например primary key) в каких то, а значит следующее значение можно получить только добавив запись, ну а в совсем уж слабых, пользователи заводят специальную таблицу, где одна запись - сиквенс, значение которого можно прочитать и увеличить на нужное число простым update (и использовать блокировки).

Самое главное, в базах данных за многопользовательский доступ (а значит конфликты, что делать если два пользователя одновременно затребуют следующее значение), отвечает механизм транзакций.

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

p.s. Внимательно подумайте, вам нужен счетчик или нужно уникальное значение? Можно чтобы каждое следующее значение было ровно на единицы больше? может быть оно меньше предыдущего?

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

Самый простой алгоритм - который по правде говоря не дает гарантий, но значительно понижает вероятность коллизий - взять текущее время, в милли-/микро-/пико-секундах, при наличии кучи машин - добавить номер этой машины, можно добавить еще случайное число (чем больше его разрядность тем ниже вероятность коллизий)
sprintf("%u",microtime(true)*1000000);
еще есть метод uniqid, он делает примерно то же самое но возвращает hex строку.

p.s. время на машинах должно быть синхронизировано с точным, чтобы не было такого что в какой то момент оно откатится назад на достаточное значение чтобы метод дал сбой

Хотя бы для отладки вывел что возвращает тебе ftp_mlsd, 100% все проблемы бы решились сразу.

Пальцем в небо - в linux каждый каталог содержит два элемента '.' и '..', соответственно текущий и предыдущий каталог, вдруг ftp их возвращает а ты их в файлы записываешь? но тип по уму у них должен быть dir, плюс зациклилось бы все.

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

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

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

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

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

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

Очень сложный вопрос м в конце концов упирается в объем ресурсов, которые вы готовы в это вложить.

2 основных подхода к реализации отката:
1. вместо вычислений, на каждом шаге просто добавляете или удаляете описание операций (иногда подойдут обычные замыкания) в специальный массив, реальные вычисления проводите в момент когда запрашивается результат
2. каждый шаг вычислений сохраняет предыдущее значение в специальном массиве, соответственно откат - это получение этого значения и удаление последнего элемента в масссиве (если не нужен redo)

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

Так же возможно сочетание обоих подходов, для оптимизации ресурсов.