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

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

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

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

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

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

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

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

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

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

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

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