Comments 8
А как обстоит дело с атомарностью перекладывания событий между очередями? Из одной очереди, допустим, «сняли» а в другую по техническим причинам не сумели «положить» — может такое быть?
Здесь все зависит от конкретной реализации на уровне обработки очереди, если очередь поддерживает механизм подтверждения (ack), то можно обеспечить атаморность с помощью такого механизма. Можно обеспечивать ее на уровне кода, с использованием дополнительных буферов, систем ретраев и других подходов
Так а как делать ретраи в случае с Internal API?
Реквест сделан, конзюмер получил 200 ОК, но по каким то непредвиденным причинам мы получили сбой в процессе на стороне FPM, сообщение помечено как выполнено, а работа не проделана, здесь может быть потенциальная точка отказа.
Реквест сделан, конзюмер получил 200 ОК, но по каким то непредвиденным причинам мы получили сбой в процессе на стороне FPM, сообщение помечено как выполнено, а работа не проделана, здесь может быть потенциальная точка отказа.
В представленной схеме, внутри FPM процесса у нас разгребается определенная очередь и поочередно процессятся задачи из нее, в одном потоке. Соответственно если скрипт упадет в процессе обработки очередной задачи, не подтвердив ее, следующая отправка обработки этой очереди в internal API начнет обработку с этого же сообщения.
А зачем используется redis вместо той же kafka?
Это вопрос инструментария, данный архитектурный подход можно использовать с любыми инструментами. Мы используем redis, так как у нас в компании достаточно высокая компетенция по нему, так же он позволяет нам очень гибко оперировать сырыми данными, реализуя кастомную логику очередей, как на стандартных типах данных, реализованных в redis, так и расширяя возможности redis через Lua скрипты.
А RoadRunner в качестве замены NGINX+FPM не рассматривался? И если выбор был не в пользу RoadRunner, то по какой причине?
Sign up to leave a comment.
Обработка миллионов событий в сутки при помощи каскадов очередей