How to solve a problem with parallel data processing?

Question

PHP

У меня есть API, на которое постоянно приходит очень много данных от разных клиентов.
В ответ на запрос я отдаю код 200 и складываю данные в очередь redis.
Данные нужно обрабатывать как можно быстрее, поэтому у меня 50 воркеров, собирающих данные из очереди и параллельно обрабатывающих их.
Но тут же возникает проблема — данные каждого отдельного клиента обязательно должны обрабатываться последовательно, то есть вариант с просто 50 воркерами не доходит.
Как силами PHP (и не только) эффективно решить такую задачу?

Answer 1

Так вам вариант и без воркеров не подходит потому что вебсервер/php-fpm обслуживается в несколько процессов в любом случае. И если данные приходят одновременно, то не будет никакой последовательности.
В общем задача нерешаемая в такой трактовке я бы сказал.
Непонятно что приходит, почему по очереди надо и т.д.
Если в данных не содержится никакого признака с порядковым номером, то все решения так или иначе упрутся в то что данные могут прилететь одновременно и обрабатываться параллельно и что тогда делать?
Если отбросить пункт про
то решение это складывать данные как угодно, а потом синхронно обрабатывать.
Без этого разруливать логику кодом надо в любом случае, проверять есть ли более ранние данные или что-то такое. Но опять же все это без конкретики в пустоту.

Answer 2

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