Алексей Уколов, С другой стороны, если оно слишком быстро отработает, то мы снова столкнёмся с этой проблемой. Если у автора проблема именно с повторяющимися запросами, то лучше пусть эти 10 секунд так и пройдут, и Redis сам удалит ключ. В этом случае лучше озаботиться генерацией вот этого самого уникального ключа, чтобы он отлавливал именно те запросы, которые точно дубли с точки зрения автора, и пропускал другие. А для этого не стоит удалять ключ в случае успеха.
Зато в случае ошибки как раз и надо удалить ключ, ведь ошибка может быть вызвана не только неверными данными, но и сбоем сети и т.д. И тут ждать 10с будет неверно.
Вечно Крайний, Если вы хотите именно такой подход, то тут будет всё намного сложнее.
handler.php должен запускаться вебсервером как обычно.
handler.php должен просто складывать сообщения с телом запроса в очередь.
worker.php должен быть отдельным процессом и только читать по очереди те сообщения, что в неё пуляют handler.php. Он должен сам проверять, было ли уже такое сообщение или нет и принимать решение о том, отправлять ли данные дальше или игнорировать их.
worker.php должен быть единственным, запускаться самой операционной системой и находиться под наблюдением supervisor, чтобы тот его перезапускал, ежели он упадёт.
Проблема с этим асинхронным подходом в том, что handler.php не знает результата работы worker.php, т.к. они живут в разных вселенных.
Я обычно решаю эту проблему установкой специального сервиса Mercure (mercure.rocks), к которому браузер клиента коннектится и ждёт сообщения от бэкенда по каналу SSE (Server Sent Events). И мы из worker.php будем кидать сообщения обычным http запросом в этот самый Mercure, а он будет раскидывать эти сообщения всем подключённым к нему браузерам.
Сложно? Да, сложно. Но с отдельным и единственным долгоживущим worker.php только так...
101-s,
Рекомендую Wordpress + WooCommerce потому что это одновременно и быстро сделать, и специалистов самого разного уровня как грязи в деревне в осенний день. Так же есть множество плагинов для интеграции с различными "системами учёта", платежными системами, службами доставки и т.д. и т.п. Есть ещё момент UX. Современный покупатель - фифа капризная. И если ваша корзина и шаги оформления заказа будут сильно отличаться от того, к чему он привык, то многие просто не дойдут до конца оформления заказа, если там что-то сильно особенное. Поэтому такие популярные связки как WP+WC очень знакомы покупателям своим процессом оформления именно потому, что таких магазинов чудовищное количество. А узнавание - это очень хорошо для продаж.
Если ваш вариант первый, и у вас уже есть ИМ, то вы абсолютно точно до мельчайших деталей знаете, что вам мешает и чего вам не хватает. И в случае, если готовое решение не будет иметь нужного вам конкретного функционала, то придётся "бороться" с этим готовым решением при помощи каких-то "хаков". Ведь и сила и слабость коробочных решений в том, что у них своё видение и свои принципы, которые могут отличаться от вашего видения и ваших принципов. Поэтому, когда вы точно знаете, что вам нужно, лучше написать магазин с нуля конкретно под ваши нужды. Самый главный недостаток такого решения - это то, что магазин будет крайне сложно дорабатывать, если изначальный разработчик исчезнет. Вариант WP + WC лишён такого недостатка. Поэтому выбирать нужно только надёжную команду с многолетним портфолио.
Squora, Тогда вам вот ещё момент: если будете брать MacBook Pro, то рассмотрите вариант уже с процессором M4 Pro, а не просто M4. Это иногда путает людей, и они берут более дешёвый вариант, который мало чем от Air отличается. А вот процессор M4 Pro - это точно новый уровень и точно увидите разницу
Squora, Вот, кстати, хорошее видео с более подробным разбором разницы между Air и Pro. Там есть ряд неточностей, но это реальный толковый программер, и его советы можно учитывать. https://www.youtube.com/watch?v=UwjBQpdSjsA&t=201s
Squora, Только видео может забить диск такого размера. Никакие репозитории даже близко не подберутся к 512.
А как я уже писал, для видео лучше купить NAS. Я к своему домашнему NAS подключаюсь извне через VPN, и могу смотреть свои видосы из любой точки мира
Squora, Вам стоит ещё учесть, что Маки не сильно падают в цене на вторичном рынке. И если вам "в будущем" чего-то не будет хватать, то продадите этот и купите новый. А ведь вот это нехватающее "в будущем" может и не наступить вовсе. Зато ворчание о том, что ноут не такой лёгкий и удобный как Air, и я за это неудобство ещё и доплатил, наступит в первый же день использования
Squora, Внимательно подумайте, что такое огромное вы будете хранить на ноуте, что вам не хватит 512 SSD.
Я давным-давно купил себе Synology NAS, и всё кино и смонтированное видео хранится там.
У меня мильон проектов, я вообще не думаю об экономии места и каким-то образом мне этой памяти с головой хватает.
512 SSD + NAS - и нет проблем
rPman, websockets - это не http. Это совершенно другой протокол. Соединение только инициируется через http с заголовком Upgrade: websocket. И далее общение по http заменяется общением по websocket по тому же самому TCP/IP соединению.
А в SSE используется тот же http.
И хоть поддержка в браузере есть и у того и у другого, но обрабатывать SSE на клиенте всё равно значительно проще. В SSE можно подписываться на конкретные события. А у вебсокетов один общий хэндлер. Реконнект у SSE автоматический, а не ручной, как у websockets.
rPman, Вебсокеты сложнее вообще для всех. И для клиента и для сервера. А зачем? Просто чтобы получить сигнал о том, что данные изменились? Их надо выбирать, если вы пишете чат в реальном времени для кучи народу, игру или аналог Google Docs. Для большинства остальных случаев это чудовищный оверкилл.
SSE работает тупо на HTTP. EventSource API поддерживается напрямую браузером со всеми ретраями, реконнектами и стандартными сообщениями об ошибках. Нужен просто Javascript и ничего более.
Shurik, Погуглите, как правильно настраивать nginx location под вебсокеты. Там есть ряд особенностей, на которые стоит обратить внимание. В таком конкретном вопросе вам Гугл поможет больше меня
Shurik, Вот я попросил у ИИ накидать как объединить всё что вам нужно в докере. Не проверял ничего, глянул по-быстрому, вроде всё там норм. Но идея вам должна быть понятна.
Shurik, Не надо вам лезть в unix сокеты.
У вас несколько контейнеров на одном сервере. У каждого контейнера открыты свои специфические порты.
Nginx у вас должен работать в качестве reverse-proxy для ваших внутренних контейнеров с разными частями приложения.
Поэтому Nginx желательно вынести в отдельный контейнер. PHP-FPM - еще один контейнер. А вебсокеты - третий контейнер, которому в докере нужно будет назначить автоматический рестарт.
reverse-proxy в контейнере Nginx будет заниматься пробросом данных в тот или иной контейнер с теми или иными параметрами соединения в зависимости от урла.
Рекомендую все три конейнера объединить в docker-compose, который создаёт между контейнерами внутреннюю сеть, и тогда вам даже порты открывать не придётся, а слать запросы на хостнеймы, описанные в docker-compose.yaml
Shurik, Очень часто люди влезают в вебсокеты, даже не зная о существовании такой прекрасной технологии, как SSE (Server-Sent Events). Это вебсокеты "для бедных". Канал связи однонаправленный, с сервера в браузер. Работает через HTTP
Браузер подписывается на получение событий от SSE-сервера. PHP шлёт на SSE-сервер запрос о том, что событие возникло, и SSE-сервер уже рассылает это событие всем подписанным на него браузерам.
Таким образом: Если один человек изменяет список, то всем подписанным на это событие браузерам сообщается, что список изменился, и они могут получить новые данные обычным HTTP-запросом. Либо можно даже новые данные передавать в этом же событии.
Рекомендую освоить сначала этот подход. Вы поймёте, как работает эта схема асинхронного общения, отшлифуете её, а потом, если понадобится, вникнете уже в вебсокеты. Понимание самой сути асинхронной работы с сервером поможет вам потом и в некоторых аспектах эффективного использования весбокетов. Вы наработаете для себя паттерны этих процессов обмена данными.
Вот описание процесса для Symfony. Нужно будет дополнительно установить Mercure Hub. Это сервис, написанный на Go, который как раз занимается реализацией схемы publish/subscribe для SSE https://symfony.com/doc/current/mercure.html
У себя в PHP приложении вы будете отправлять сообщения через банальшейший Symfony messenger, а Mercure Hub автоматом разошлёт его всем клиентам
Shurik, Мне интересен один момент. А вам именно вебсокеты нужны? Какую задачу вы решаете.
Потому как если вам нужно только периодически отправлять какие-то сообщения с сервера на фронтенд, то есть гораздо более простое решение.
Зато в случае ошибки как раз и надо удалить ключ, ведь ошибка может быть вызвана не только неверными данными, но и сбоем сети и т.д. И тут ждать 10с будет неверно.