rPman

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

тебе нужна key-value база данных, если данных мало и они влезают в память массивом $index[$hash]=true то тогда храни в файле в сериализованном виде var_export/serialize/json_encode или даже по 1 строке на запись - читать array_flip(file('имя файла'))

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

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

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

class Main
{
  public $db; // само собой можно геттеры сеттеры делать или сами методы по работе с базой тут определить
}
class Work
{
  function __construct($main)
  {
    $this->main=$main;
  }
  function do()
  {
    $this->main->db->connect(...)
  }
}

curl_setopt($ch, CURLOPT_POSTFIELDS,['contacts'=>'[{"type":"phone","code":"+972","phone":"44255424"}]');

https://www.php.net/manual/ru/function.curl-setopt.php

Все данные, передаваемые в HTTP POST-запросе. Этот параметр может быть передан как в качестве url-закодированной строки, наподобие 'para1=val1&para2=val2&...', так и в виде массива, ключами которого будут имена полей, а значениями - их содержимое. Если value является массивом, заголовок Content-Type будет установлен в значение multipart/form-data. Файлы можно отправлять с использованием CURLFile, в этом случае value должен быть массивом.

метод file (тоже умеет http) вернет массив из строк в указанном файле, проходишь по нему в цикле, как найдешь стартовую строку, начинай все строки сохранять в результирующий файл, заведи переменную статус - true - сохраняем, false - пропускаем, как найдешь строку окончание - устаналивай ее в false.

Боюсь у вас все как то переусложнено.

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

Соответственно виртуальных методов нет, точнее они работают так автоматически, т.е. можно считать все методы виртуальными.

И да, все что касается методов и их наследования скорее всего сделано однократно, в момент компиляции, а в момент создания экземпляра объекта в него копируются методы и переменные из этого сохраненного.

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

php имеет штатный инструмент работы с файлами по ссылкам http/ftp во всех своих методах типа fopen или file_get_contents

Протоколов много, можно регистрировать собственные

Расширения для php пишут на c и с++, вы конечно можете извратиться и писать на любом другом языке, главное чтобы он был компилируемый, но работа эта бессмысленно сложная

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

100 запросов в секунду - зачем такой нетипичной задачей грузить базу данных?

Задайся вопросом, сколько у тебя записей? миллионы? миллиарды? может эффективнее будет держать список id на бакэнде массивом и выбирать от туда?
* Запили миниатюрный сервис с сокетами, в который бакэнд при удалении или добавлении записи будет присылать id, а при перезапуске будет загружать весь список id... памяти это занимать будет порядка 16х от количества записей умножить на логарифм (зависит от того какие списки поддерживает бакэнд, нужно хранить упорядочный num -> id, причем это просто массива, при добавлении id добавляется в конец, а при удалении - на место удаленного ставится элемент с конца, к сожалению тогда для быстрого удаления нужен map: id->num).
* Списков таких должно быть несколько - свой по каждому значению веса (считается что вес - целочисленный и вариантов значений значительно меньше общего количества записей), соответственно каждый id попадает в свой список.
* Каждый раз, как идет запрос на случайный id, считаешь два случайных числа:
- первое на интервале [0..максимальное значение веса) - выбираешь какой вес сейчас сработает
это нужно делать с учетом вероятности, которое соответствует каждому весу, т.е. для каждого веса свой интервал значений случайного числа, для 1 это будет попадание между [0..1), для 2 - [1..3), для 3 - [3..6), для 4 - [6..10),.. макс значение интервала равно сумма арифметической прогрессии 1....N где N максимальное значение веса. Левое значение интервала для n считать по формуле суммы арифметической прогрессии а правое + значение веса для него.
- второе, [0..максимальное значение num в соответствующем списке)
второе число даст искомый номер в массиве, а значит и id.
* Для значений весов которые не используются (пустые списки id) нужно будет исключать такое число из списка доступных значений весов, делать новый список с меньшим количеством и давать соответствие значений их этого нового списка с меньшим количеством весов и общим, чтобы такие неиспользуемые веса не попадались.
К примеру из весов 1..10 используются только 1,4 и 10, тогда делаем получаем новый список из 3 элементов, но в формуле расчета интервала для вычисления правой границы использовать значение веса, т.е.:
[0..1), [1,5),[5..15) - общий интервал [0..15)

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

Трудоемкость алгоритма О(1) с очень маленькой константой, но требует память O(n)= n*log(n) с процессором O(n) log(n) на любые модификации.

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

Воспользоваться нужно готовыми инструментами mysql spartial, кажется форматы там популярные, найти готовые либы для работы с ними из браузера будет не сложно.

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

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

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

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

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

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

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

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

Какого фига вы рекомендуете человеку удалять гланды через задницу. Какой вебсокет в 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
)