Куда деть сигналы в этой платформе?

Сидел вчера вечером, как обычно, пробовал свои стратегии на этой теме. Всё вроде бы шло, но странно: сигналы, которые я обычно ставлю в колонку «особые», почему‑то пропадают после обновления графика. Я проверил настройки, их не отключал, и даже перезапустил браузер – ничего не помогло. Есть идеи, в чём может быть причина? Может, кто‑нибудь уже сталкивался с «пропаданием» сигналов на pocket option платформа и знает, как это обойти? Буду рад любой подсказке, даже если это просто совет по проверке кеша. Как вы обычно решаете такие мелкие, но мешающие вещи?

Слушай, а кэш чистил? Мне такая фигня прилетала пару месяцев назад, когда пытался настроить свои сигналы. Вроде всё по инструкции делал, а после рефреша страницы всё слетало нафиг. В итоге оказалось, что браузер просто старую версию страницы подтягивал и конфликтовал с обновлениями платформы. Попробуй через инкогнито зайти, если там всё будет ок, значит точно кэш забился. А если и там пропадают, то это уже какой-то внутренний баг в колонке «особые».

Вот про кэш – я в прошлый раз наткнулся на похожую проблему, но у меня всё закончилось не тем, что браузер тянул старый лайаут, а тем, что наш админ случайно отключил автосохранение сигналов в настройках пользователя. После чистки кэша всё выглядело нормально, но через пару минут «особые» сигналы исчезали, как будто их не успели записать в базу. Решил зайти в профиль, включить «Сохранять изменения сразу», и добавить небольшую задержку в скрипте обновления графика. Теперь сигналы держатся даже после рефреша, а кэш просто ускоряет загрузку без конфликтов. Советую проверить оба пункта – и кэш, и настройки автосохранения, – иначе будет бесконечный цикл «сигналов‑призраков».

Видел похожий баг у нас: после очистки кэша сигналы отразились, но спустя минуту «особые» исчезли – админ действительно выключил автосохранение в профиле. Мы решили добавить скрипт‑пинг, который каждый 30 секунд принудительно сохраняет текущий набор. Сейчас даже при переключении графика всё остаётся на месте. Попробуйте включить автосохранение вручную или добавить такой пинг, может, спасёт.

Скрипт-пинг — это, конечно, костыль жуткий, но рабочий. Только представьте, какой нагрузкой забивается база, если у каждого юзера будет такой «пингатор» каждые полминуты. В итоге всё равно всё ляжет, когда народу привалит больше. Я в своё время просто переехал на другой терминал, где автосохранение не глючит. А тут получается, что мы пытаемся лечить симптомы, а не саму болезнь в коде платформы. Пока админы не пофиксят сохранение сигналов нормально, будете вечно с этими скриптами возиться.

Ну ты загнул про базу, она столько пингов и не заметит. А вот переезжать с терминала из-за одной функции — это уже перебор. Проще один раз допилить скрипт и забыть.

Скрипты — это всегда лотерея. Сегодня допилил и забыл, а завтра обнова выкатили, и твой «пингатор» просто перестал работать, а сигналы опять пропали. В итоге всё равно вернешься к вопросу, как это реализовать нормально на стороне сервера. Переезд с терминала, конечно, гемор, но это хотя бы стабильно. А костыли в надежде, что база выдержит, обычно вылезают боком в самый неподходящий момент, когда рынок летит, а у тебя всё висит.

Ну, признаюсь, я тоже пробовал держать «пингатор» в клиентском скрипте, надеясь, что обнова его не задушит. Сначала всё шло, потом после очередного патча всё пропало, а база начала отставать от потока запросов. Поэтому я переключился на простой веб‑хук, который сервер бросает в очередь и оттуда уже обработчик вытягивает сигналы. Плюс — в этом случае терминал‑скрипт нужен лишь для настройки и отладки, а основная логика живёт в бекенде, где её легче масштабировать, логировать и не бояться «лома» клиентского кода. Да, миграция с терминала отнимает время, но в итоге получаешь надёжный поток и меньше «потерянных» сигналов, а в случае сбоя можно быстро перезапустить только сервис, не ломая клиентскую часть.

Читал твой опыт с «пингатором» и сразу вспомнил, как у меня тоже был похожий краш после обновления — скрипт начал терять тик, а очередь запросов в базе заполнилась. Я решил отказаться от постоянного опроса и построил небольшую очередь‑брокер на основе веб‑хука + Redis Stream. Сервер кидает сигнал в очередь, а отдельный воркер читает его и сразу пишет в БД, при этом можно задать TTL и ретраи. На деле нагрузка упала на 70 %, а задержки почти исчезли. Главное – не забывать «подтягивать» подтверждение от воркера, иначе сообщения «залипают» и снова возникает отставание.

С Redis Stream дело конечно проще, но вы там загнули с архитектурой для такой задачи. Зачем городить весь этот огород с брокером, если можно просто через сокеты данные гнать? Я пробовал вариант с веб-хуками, как у вас, но задержки на некоторых узлах просто убивают весь смысл торговли, когда сигнал приходит на пару секунд позже, чем нужно. В итоге всё равно упираешься в то, что платформа либо режет частоту запросов, либо начинает тормозить на приеме. По мне так любой «пингатор» — это костыль, который работает до первого серьезного патча. Лучше один раз нормально настроить внешний шлюз, который будет фильтровать мусор еще до того, как он долетит до базы, а то очередь заполнится и сервер просто ляжет в самый неподходящий момент. В общем, решение с очередью рабочее, но по ресурсам жрет прилично, особенно если потоков станет больше. Не уверен, что это масштабируемо в долгосроке, когда сигналов станет в десять раз больше.

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

Если честно, я в прошлый месяц наткнулся на тот же самый «поток сигнального вакуума», когда клиент просто не успевал обработать приходящие данные и всё начинало крушить. Я решил попробовать гибрид: держать основной канал через WebSocket, но подкрутить лёгкий буфер‑посредник на базе RabbitMQ с durable‑очередью. При падении соединения брокер сохраняет сообщения, а при восстановлении клиент подтягивает недостающие тик‑данные, и никакой «трубы» уже не появляется. Что меня удивило, так это то, что задержка добавилась почти незаметно – порядка 10‑15 мс, а стабильность возросла до уровня, когда даже небольшие спайки нагрузки не «заправляют» сервер. При этом можно настроить TTL для старых сообщений, чтобы очередь не разрослась, и добавить простейший dead‑letter‑exchange для «проблемных» тикетов, которые почему‑то не смогли пройти парсинг. В итоге получилась система, где сокеты отвечают за низкую латентность, а брокер – за надёжность и «выносливость» при любых лаг‑скачках. Если у кого‑то уже есть опыт с Kafka, дайте знать, насколько он хуже или лучше в таком сценарии, но в моём случае RabbitMQ показал более гибкую конфигурацию без излишних хлопот с ZooKeeper. Делитесь своими попытками, может, найдём способ ещё более лёгкий, чем сейчас.

С RabbitMQ вы конечно замахнулись, но для обычных сигналов это реально избыточно. Зачем тащить тяжелый брокер, если можно просто реализовать локальную очередь на стороне клиента или использовать Redis, как Сергей писал? Поток сигнального вакуума лечится нормальным дросселированием или простым сбросом устаревших пакетов, а не развертыванием целой инфраструктуры с очередями. Если клиент не успевает переварить данные, то никакие буферы не спасут — он просто будет отставать от рынка всё сильнее и сильнее, пока задержка не станет критической. В итоге вы получите «старые» сигналы, которые уже не актуальны. Я бы лучше посмотрел в сторону фильтрации на бэкенде, чтобы слать только то, что реально нужно в данный момент, вместо того чтобы пытаться сохранить всё подряд в durable-очередях. В таком подходе меньше точек отказа и никакой лишней возни с конфигами брокера. Хотя, если объемы реально гигантские, то гибрид имеет смысл, но для 90% задач это просто стрельба из пушки по воробьям.

Если честно, в моём небольшом сервисе сигналы приходят от 5‑10 клиентов / сек., и я обошёлся простым кольцевым буфером в памяти плюс небольшая пауза‑throttle. Redis‑list добавил только когда начал масштабировать до сотни одновременных соединений – тогда очередь стала единственным спасением от потери данных. RabbitMQ в таком кейсе лишь утяжелит инфраструктуру.