PD
Спасибо!
После фразы 'в rmq нет персистанса' можно всю статью выкидывать в мусор.
Size: a a a
2019 August 20
LV
В kafka любую проблему можно решить. Вопрос зачем, если часто другое решение в качестве очереди от этих проблем избавляет.
LV
Само избавляет.
PD
Так вот - нет других решений без этих проблем, увы...
PD
Или есть с более значимыми, типа отсутствия надёжности вообще.
LV
Любое решение - это набор компромиссов. Сейчас я вижу, что часто kafka используется как решение без понимания того, какие проблемы оно может принести в проект. Это печально. Есть проекты, где она очень хорошо подходит. Но есть и такие (и на мой взгляд - таких как раз большинство), в которых надо тщательно взвесить все плюсы и минусы kafka.
PD
Любое решение - это набор компромиссов. Сейчас я вижу, что часто kafka используется как решение без понимания того, какие проблемы оно может принести в проект. Это печально. Есть проекты, где она очень хорошо подходит. Но есть и такие (и на мой взгляд - таких как раз большинство), в которых надо тщательно взвесить все плюсы и минусы kafka.
Это понятно. Но беда в том, что единственный нормальный конкурент - очередь в базе (если нужна надёжность). Остальные решения - увы.
Я бы сам хотел увидеть классическую AMQP, но производительную и надёжную. Но увы (
Я бы сам хотел увидеть классическую AMQP, но производительную и надёжную. Но увы (
PD
Да, если надёжность не требуется, то можно смотреть на nuts. Но вот сценариев для rmq уже совсем не видно..
Хотя лет 5 назад это был выбор 'по умолчанию'
Хотя лет 5 назад это был выбор 'по умолчанию'
EI
Да, если надёжность не требуется, то можно смотреть на nuts. Но вот сценариев для rmq уже совсем не видно..
Хотя лет 5 назад это был выбор 'по умолчанию'
Хотя лет 5 назад это был выбор 'по умолчанию'
nats реализует простой pubsub, тем и хорош и быстр.
EI
Вообще, после того, как в haproxy реализовали grpc и retry - я бы часть задач очереди (которые, по-факту, просто асинхронные вызовы) переводил в async grpc.
Чую найду 50 комментариев "да ты вообще понимаешь, что говоришь?" ...
Чую найду 50 комментариев "да ты вообще понимаешь, что говоришь?" ...
p
Ну, когда-то это была гарантия записи на диск.
Я знаю ;) вопрос в другом: а в чем сложности с ним в 2019 году? Есть контроллеры с bbu, есть nvme ssd дающие с порога 100-200k iops.
PD
Вообще, после того, как в haproxy реализовали grpc и retry - я бы часть задач очереди (которые, по-факту, просто асинхронные вызовы) переводил в async grpc.
Чую найду 50 комментариев "да ты вообще понимаешь, что говоришь?" ...
Чую найду 50 комментариев "да ты вообще понимаешь, что говоришь?" ...
Да честно говоря, c корутинами даже grpc не обязателен, можно и async http + retry policy.
PD
Я знаю ;) вопрос в другом: а в чем сложности с ним в 2019 году? Есть контроллеры с bbu, есть nvme ssd дающие с порога 100-200k iops.
Не знаю. Для РСУБД есть в этом некоторый смысл, но сейчас у большинства систем надёжность делается через число реплик и это даже лучше (хотя и дороже по железу).
PD
Я сам был 'апологетом fsync', но уже нет )
EI
Я сам был 'апологетом fsync', но уже нет )
А в паре предложений можете написать путь к "уже нет"? :)
PD
Fsync про локальные гарантии, в рамках сервера. Мне важнее про гарантии при падениях ДЦ, а тут репликация на ближний георезерв важнее и нужна до fsync.
EI
Fsync про локальные гарантии, в рамках сервера. Мне важнее про гарантии при падениях ДЦ, а тут репликация на ближний георезерв важнее и нужна до fsync.
Класс, спасибо
p
Fsync про локальные гарантии, в рамках сервера. Мне важнее про гарантии при падениях ДЦ, а тут репликация на ближний георезерв важнее и нужна до fsync.
Отреплицировался и упал
PD
Ну и ок. Главное, что бы реплика не упала. А если и она, то тоже ок, коммит не прошел )
PD
Тут как раз схема Кафки с минимальным числом подтверждений и возможностью задать rack очень удобна.