LV
Сейчас с моими нагрузками справляется и rmq. Который дает мне внятную семантику "обработал". А не считал.
Size: a a a
2019 August 20
LV
По ядру на партицию. С корутинами не работал. Но сомневаюсь, что они дают мне гарантии - позже считанное сообщение будет обработано строго позже, чем ранее считанное.
PD
Ну, значит нагрузки низкие, можно и по одной записи читать и даже fsync ждать. Впрочем, на rmq ты гарантий не получишь вообще
PD
По ядру на партицию. С корутинами не работал. Но сомневаюсь, что они дают мне гарантии - позже считанное сообщение будет обработано строго позже, чем ранее считанное.
Если тебе важен порядок, то ты не можешь обработать сообщение в пачке, если раньше был сбой. И тут тебе никакая очередь не поможет, включая rmq.
LV
Ну, а какие варианты для лог-бэйзед очереди. На пульсаре тоже самое будет
Насколько я читал, pulsar предоставляет семантику "обработано". А это ключевое, чего мне не хватает в кафке
PD
Нет в rmq гарантий обработки. И нигде нет и не может быть )
LV
Если тебе важен порядок, то ты не можешь обработать сообщение в пачке, если раньше был сбой. И тут тебе никакая очередь не поможет, включая rmq.
Мне важен порядок комита офсета
PD
В смысле 'порядок коммита'?
LV
Ну чтобы офсет был строго закомичен только после хорошей обработке
PD
Порядок обработки при этом важен?
LV
Я пишу про семантику "обработано". Когда я подтверждаю ack'ом обработку одного сообщения. В кафке семантика коммита офсета - прочитано. Потому как изначально она была спроектирована для использования с данными, допускающими потерю
LV
Порядок обработки при этом важен?
В случае кафки важен. Для логики - нет
PD
В Кафке ты сам управляешь моментом, когда и где делать оффсет. Можешь при чтении, можешь при обработке.
Если порядок не важен - то заводи побольше партиций, читай по одной записи, настраивай масштабирование как хочешь.
Если порядок не важен - то заводи побольше партиций, читай по одной записи, настраивай масштабирование как хочешь.
LV
В кафке вы либо берете из партиции строго поочередно и значит не можете взять в одновременную работу сообщений больше чем партиций, либо до пускает потерю сообщений.
PD
Ты можешь одним консумером читать из кучи партиций. Собственно, число консумеров не может быть больше числа партиций, но меньше - легко.
PD
А сколько тебе нужно одновременно? Если rmq справляется, то хватит и 100.
PD
Ну или взять пачку, после обработки часть вернуть обратно. И это вполне надёжно
PD
С учётом транзакций внутри Кафки можно и более сложные логики делать. Но обычно не надо.
PD
Все реальные гарантии rmq я построю на Кафке, только с большей производительностью.
LV
Я знаю как работает кафка досточно хорошо)) И именно это знание заставляет меня искать альтернативы. Если мой проект будет допускать потерю данных - возьму кафку. Таких областей много.