d'Ivan

как настроить консьюмер IBMMQ так, чтобы он забирал из очереди не все сообщения - без ограничений - которые ему хочет выдать сервер (менеджер), а как-то дозированно: по 1, 2, N и только после обработки уже вычитанных вычитывал следующие?

Зачем?
Используй СУБД, считывая записи с LIMIT, OFFSET

По мне, так для того, чтобы знать когда задача обработана, достаточно отправлять сообщение об окончании в отдельную очередь "оповещения". Обработчик очереди будет слушать ее и может запустить "агрегирующие процессы".

Соответственно, узнать длину очереди в таком состоянии воркер не может.

Обработчики очередей не должны заботиться о длине очереди. Это не их ответственность. Они находятся в постоянной готовности обработать следующую задачу.

Плюс, воркер в процессе собирает статистику, и должен как-то отдать её в конце работы. Я пока что решил это таким способом: напихиваю в конец очереди N (по числу воркеров) специальных заданий останова - воркер получает такое задание, отключается от очереди и делает всё необходимое.

статистику можно сохранять в СУБД, отправлять в какую-либо отдельную очередь "отчеты" и пр. (в общем обмениваться через IPC).

Вообще, AMQP - непростой протокол и в нам есть много взаимодействий по сети. У разных реализаций протокола могут быть разные особенности, даже в пределах того же языка программирования.
Если отправка по интернету, то вообще все может быть менее предсказуемо и соединения могут отваливаться спонтанно, что может приводить к "заморозке" или частым переподключениям.
Не предоставлено никакой информации об:
используемых версиях библиотек и RabbitMQ, рантайма, конфигураций сети, ... как и самого кода.

Логи должны указать на причину происходящего. Возможно, имеется проблема с соединением к Redis (СУБД доступна?) и тогда есть безуспешные 3 попытки.

Выполнять задачи в очереди можно если задачи могут выполняться отложенно. При обработке в очереди нет гарантии выполнения в заданный срок времени и механизмы взаимодействия при этом усложняются.
Для управления нагрузкой в пиковое время необходимо горизонтально масштабировать экземпляры приложения при повышении нагрузки сверх заданного лимита. По ходу, может понадобиться масштабирование СУБД.

Если я отправлю в очередь 'send_push' сообщение '{post_id: 123}': , его получит консьюмер, выберет из БД 1тыс пользователей

А что мешает консьюмеру брать из БД по 1000 в цикле?

Один процесс-диспетчер периодически проверяет наличие необработанных записей и кладет в очередь массив первичных ключей размером в 50 записей.
Т.е. процесс делает выборку 50 необработанных записей, кладет в очередь и так до тех пор пока не останется меньше 50. Просыпается через некоторое время и повторяет этот процесс заново.
На обрабатываемые записи нужно ставить метки типа dispatched - это гарантирует что записи не будут выбраны снова.
Воркеры берут каждый свою задачу с массивами pk, обрабатывают их и помечают записи статусом done и так до тех пор пока не закончатся.
А можно и без диспетчера обойтись. Главное, помечать статусом записи.

Так ничего сложного ведь

Пока очередь не пуста
  Взять с очереди сообщение/файл
  Обработать

А можно не городить огород, а использовать ZeroMQ/RabbitMQ/Beanstalkd/...
или, возможно, обойтись без очередей.