Как решить задачу с параллельной обработкой данных?

Question

[SimBioT19]

У меня есть API, на которое постоянно приходит очень много данных от разных клиентов.
В ответ на запрос я отдаю код 200 и складываю данные в очередь redis.

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

Как силами PHP (и не только) эффективно решить такую задачу?

Comments

[Максим Федоров]

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

[Decadal]

что вы имеете в виду под "данные отдельного клиента должны обрабатываться последовательно"?
если последовательность их обработки играет роль, они должны приходить либо готовыми пачками, либо накапливаться до тех пор, пока не будут до конца сформированы, и лишь после этого отданы на обработку

[SimBioT19]

Decadal, данные от одного клиента могут приходить 1 раз в минуту или 5 в секунду.
Обрабатывать их нужно сразу.

Answer 1

[Александр Аксентьев]

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

В общем задача нерешаемая в такой трактовке я бы сказал.
Непонятно что приходит, почему по очереди надо и т.д.

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

Если отбросить пункт про

Данные нужно обрабатывать как можно быстрее

то решение это складывать данные как угодно, а потом синхронно обрабатывать.

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

Comments

[SimBioT19]

Я понимаю.
Вопрос вот в чём: есть клиент, который, например, периодически присылает запросы обновить баланс у него на счету. Данные, допустим {"user_id":1,"operation":"+1"} или {"user_id":1,"operation":"-2"} и т.д.

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

При этом клиентов (user_id) может быть очень много, а обновлять баланс нужно сразу.

[Александр Аксентьев]

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

[SimBioT19]

Александр Аксентьев, про баланс — это просто пример, абсолютно не связанный с темой вопроса.

Если подскажете по поводу

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

При этом клиентов (user_id) может быть очень много, а обновлять баланс нужно сразу.

Буду благодарен.

[Александр Аксентьев]

SimBioT19, ну так записали транзакцию отправили куда надо новый баланс, обновили опять отправили.

Как еще-то? Не понимаю причем здесь что юзеров много. Пропускная способность зависит от количества воркеров/серверов, редис с отложенной записью в этой схеме ничего не даёт. Наоборот даже точка отказа.

Так и не понимаю зачем последовательность нужна.

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

Answer 2

[dtBlack]

Вариантов решения, на скорый взгляд, я вижу два:
1. Создать таблицу(массив) блокировок, то есть при начале обработки данных пользователя добавляем его в таблицу блокировки. по окончанию удаляем. При выборе задания пропускаем те на пользователе которого есть блокировка. Из минусов, возможно придется городить костыль для пропуска элемента в списке, я с redis-ом не работал.
1.1. то же самое, что и 1, но не пропускать, а взять данные и ждать удаления пользователя из блокировки. Из минусов, потеря времени на ожидании, зато без костылей.
2. Уйти от очереди данных, к очереди пользователей. То есть одномерной очереди к "двумерной очереди". Первый минус, придется менять логику и тд., а второй то что в итоге вместо очереди мы получим какую то дикость и redis возможно уже не подойдет. :)