rPman

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

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

Для пространственного арбитража (выравнивание цен между биржами) тебе нужны только ask и bids, т.е. для этого тебе нужны только depth запросы.

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

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

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

В довесок можно создавать виртуальные торговые пар (кросс-курсы), если к примеру на одной бирже они есть а на другой нет.

Чтобы ускорить процесс, нужно делить его на две части - поиск торговой пары, для которой появилась возможность совершить арбитражную сделку, и вычисление объема, в пределах которого эта сделка может быть исполнена (речь идет о сделках по маркету, когда она совершается на весь объем одномоментно). Первое - достаточно при вычислении depth дополнительно хранить две цены buy и sell, по которой здесь и сейчас можно совершить сделку на минимальный объем сделки, определяемый лимитами биржи, соответственно сравнение проводить только этих чисел. При обнаружении пересечений - вести подсчет предельного объема уже на основе стаканов (если анализ проводить на каждое событие, получаемое по websocket, то алгоритм можно сократить до сравнения одного нового лимитного ордера со стаканами других бирж).

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

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

p.p.s. Возможна комбинация подхода, после оценки динамики ликвидности валютной пары, на бирже удерживается пара лимитных buy/sell с такой ценой, чтобы ее исполнение могло бы позволить получить доход с арбитражной сделкой по маркету на другой бирже, с отслеживанием их частичного или полного исполнения с помощью websocket. в этом случае можно будет пытаться ловить резкие движения, когда рынок на столько резко меняется, что исполняет ордера по достаточно выгодным ценам...

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

Благодаря добавлению почти нормальных классов и некоторой типизации, php стал вполне неплохим языком программирования.

С точки зрения изучения алгоритмов, этого более чем достаточно.

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

Канонически для изучения именно программирования с прицелом на работу, лучше выбирать что то из c++/java/python может c# (точнее весь .net) но с оговорками.

c++ благодаря последним (десятилетие) стандартам стал на столько удобным и простым (особенно если не стрелять себе в ногу извращениями) при высокой скорости работы приложений, огромной базой инструментов, что его можно выбирать первым (но не главным) языком, особенно если не учить его углубленно... используя знания о нем как базис, другие языки изучать будет значительно проще. но GUI приложения писать на c++ грустно.

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

java - учит строгости, даст полезную базу для изучения,.. кто то поставил бы его на первое место новичкам и не только... но после него 'опускаться' до c++ будет сложно, и больших скоростей как и у python от него не жди

Не выбирай первым языком всякие javascript (они испортят тебя как программиста) или go/rust (от них можно получить разочарование при поиске работы).

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

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

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

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

Возможно вступают особенности оптимизации выполнения на процессорах с маленьким размером массива (кеши, предсказание ветвления), например если массив int порядка 1000 элементов у меня тесты это и показывают insert быстрее или равный по скорости, а 10к..1000к уже заметно медленнее

а тут и 1000 различия есть https://www.mycompiler.io/view/1CQUKga8um2

От задачи.
Если тебе нужна скорость, то придется пожертвовать памятью и создать массив указателей на элементы (т.е. в твоем примере это массив указателей на элементы с индексом 2,3,6,7,8,10).

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

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

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

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

Пример, берем младшие 4 бита для адреса (возможность одновременно быть в обработке 4-ем заказам)
1 - 10110001 цена 177р
2 - 01100010 цена 98р
3 - 11110100 цена 244р
4 - 00011000 цена 24р
если платежка пришла по 3-ем заказам, например 1+2+4 то это даст сумму 299р - 100101011, смотрим на младшие биты, установлены 1,2 и 4

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

Логично что это подойдет только если заказов мало, например 2^10 это всего 10.24р

К сожалению если не добавить какого то еще знания о возможностях группировки заказов, то это никак не оптимизировать