rPman

вместо условных 100 кликов людям засчитывало ~40

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

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

update set clicks=clicks+1, last_click_time=now() where last_click_time+:ALLOWED_CLICK_INTERVAL<now() and id=:current_id

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

Можно больше, но тогда понадобится разнести таблицу аналитики и таблицу событий, в таблицу событий записывают события, но она без индексов, а в аналитику зааливать данные из всех собранных событий, в цикле

Вам зачем нужна прослойка? Что бы заменить некрасивый синтаксис curl_xxx на свой некрасивый?

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

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

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

а почему бы не объединить эти обе библиотеки в одну?
зачем мельчить если они друг от друга зависят и так?

В общем случае технологии называются Interprocess communication.

Изначально предлагались (php/python) механизмы очереди сообщений, shared memory и semaphores, как минимум на их основе делают высокоуровневые библиотеки по работе с сообщениями (и используют именно их, а не низкоуровневые, но знать про них обязан каждый, чтобы понимать недостатки)

Второе и самое логичное, использовать socket-ы, как unix socket или pipes, так и tcp. Многие не заморачиваются, а поднимают полноценный асинхронный http сервер и организуют общение между приложениями по http или лучше websocket протоколу, так как это позволяет распределить приложения уже не в пределах одного сервера, а в сети, что дает очень высокую гибкость, но ценой значительных накладных расходов на сериализацию.

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

Например, проверяй, чтобы ссылка на видео содержала параметр, результат целочисленного деления текущего времени timestamp на количество секунд в требуемом сроке (24*3600*7).

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

if(@$_GET['hash']==md5(SECRET_SALT.(time()/(24*3600*7))))
{
  // разрешить доступ к видео
}

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

Путь к видео в этом случае будет выглядеть как: https://example.com/hash/filename.ext
для веб сервера hash это каталог, а скрипт должен просто создавать эту ссылку на диске на настоящее место размещения файла (в не публичном каталоге естественно).

С академической точки зрения, если это не в продакшен и только похвастаться, можно воспользоваться eval:

$myfunc = eval('return function($x) { return $x['.implode('][',array_map('json_encode',$path)).']; };');
echo json_encode($myfunc($ar)); // {"v":{"a":123,"b":321}}

Тут array_map('json_encode',$path)) экранирует всякие ковычки и слеши, преобразуя значения в код для их получения
Затем полученный массив с помощью implode('][',... превращается в последовательный вызов элементов этого многомерного массива.
А eval('return function($x) { return $x[...]]; };'); формирует строку функции для вызова этой конструкции и помещает ее в переменную.
Затем остается только вызвать это $myfunc($ar);

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

p.s. если структура $path неизменна для проекта, я бы рекомендовал генерацию кода перед запуском (т.е. прямо .php файлы генерировать) а не во время, это будет еще быстрее и эффективнее, да и поддерживать этот бред будет понятнее.

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

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

Код для этого дела - несколько строчек.

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

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

<Directory /var/www/html>
        Options +Indexes
        AllowOverride None
        Require all granted
    </Directory>

тут +Indexes делает именно это - генерацию html

p.s. если же нужно на php генерировать список файлов по своей логике то добавляешь поддержку php в apache (модуль mod_php или php-fpm) и index.php:

foreach (scandir('.') as $file)
{
    if ($file == '.' || $file == '..') continue;
    echo '<a href="' . htmlspecialchars($file) . '">' . htmlspecialchars($file) . '</a> - ' . filesize($file) . '<br>';
}

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

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

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

Отсюда архитектура - отдельно дубовые парсеры-загрузчики (их можно размещать буквально где угодно, они получают команду на загрузку и молотят, выдавая json-чики пакетами в виде результата), отдельно узлы-обработчики, которые на каждый пакет данных от загрузчиков делает нужные запросы в базу данных (или заранее кеширует в памяти, но тут нужно считать, что дешевле - апгрейдить сервер базы данных или держать на дисках кеш-дампы запросов и обновлять их параллельно БД, в этом случае кстати БД остается как конечное хранилище и аналитики). Ну и про базу данных, они на запись медленные только если там индексы распиханы по максимуму, хороший способ, если загрузка в базу редкая (например раз в сутки длится час) то можно отключить на это время индексы, провести загрузку, вернуть индексы - это кратно ускоряет процесс ЗАГРУЗКИ но не проверки целостности и поиск данных, т.е. подходит именно когда анализ проводится не в БД.

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

p.s. у меня крутился сервис, годами собирающий терабайты данных на скорости 4к-10к событий в секунду (time series), хранить это в классической базе я не стал, а организовал хранилище на файлах, поверх которых в базе данных собирается аггрегированная выжимка и индексы.

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

Отдает nextcloud, значит настройки его смотреть.

Попробуй в /var/www/nextcloud/config/config.php (путь может немного другим быть, например home, смотри настройки веб сервера) и там настройка
'tempdirectory' => '/tmp/nextcloudtemp',

Если объединить все твои последовательные if в непрерывную конструкцию
if () {} elseif () {} elseif.... else {}
то goto или return Rsa97 не понадобятся

excel таблица залитая на google docs

минимум 100 запросов в секунду

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

Если убрать из списка google, то можно самостоятельно хостить headless excel (майкрософтовский офис, приложение на чем угодно, работа с activex из того же .asp) либо libreoffice, вот пример на питоне но идею я надеюсь ты понял...

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

Мда, математику бы вам подучить.

Сумма чисел, отсутствующих в арифметической прогрессии (школа 9 класс кажется) можно посчитать по формуле - сумма чисел в полной последовательсности минус сумма чисел в имеющемся массиве.

$foo = [1, 2, 3, 6];

$n=end($foo);
$asum=((1+$n)*$n)/2;
echo $asum-array_sum($foo);