вы можете запускать внешний скрипт в бэкграунде - делов то.
но по факту все что вы тут расписали - решается очередью. сидит демон и мониторит очередь на наличие задач - получил обрабатывает. не получил - сидит ждет. профит по сравнению с чем? с вашей реализацией манагера потоков на php? ну при всем уважении к вам и пхп по стабильности я поставлю на какой нибудь rabbitmq, да и по скорости тоже на него.
Самое простое решение, как уже указали, использовать несколько воркеров, столько, сколько будет оптимальным. Для этого проще всего запускать их в разных процессах, чем использовать потоки или подключать асинхронность.
странное утверждение. не все и всегда можно сделать через базу. Да и не нужно скорее всего, многократный апдейт одного и того же это очень странное поведение, и не факт что оно нужно для решения неизвестной задачи.
Если СУБД имеет нормальное железо и нам требуется чтобы она выдерживала высокую нагрузку. То, как минимум проверьте используемые индексы, unique и foreighn keys, быть может возможно от них отказаться. Как максимум, продумать неблокирующую схему работы, например разбить эту одну обновляемую строку на несколько строк предназначенных разным запросам, поделить общий remains на несколько, тогда на начальных этапах разные запросы будут обновлять разные строки и не будет блокировок, когда remains уменьшится, то все равно будт обращаться к одним и тем же. Здесь мы потеряем в скорости select, но зато избежим блокировок на начальных этапах, если конечно remains достаточно большой. Но, все это очень усложнит работу, да и схему надо проверять, не зная других составляющих не факт, что это чтото даст,.
И, гораздо проще запихнуть это в Redis, и работать в нем, как ни крути он не пишет одно и то же по 4 раза, а если упираемся в запись на диск, то это оптимальное решение.