так он эффективно будет стоят на месте и ждать кафку, а это именно та ситуация которую я и не хочу допускать

тогда можно один из брокеров запустить на машине с сервисом

не, не подойдёт, мне сообщения надо посылать а не WAL стримить 🙂

в итоге все равно упрется в wal на диск

а не сильно жирно ли будет?

Если хочется обработать отказ удаленной и распределенной системы и продложить работать - нужно писать данные локально.

ну брокер кафки не такой уж и прожорливый

но это я скорее шутил чем серьезно писал, просто в итоге наверно придется писать на диск иначе я хз как проблему решить если прям нужно локально писать

но тем не менее я могу себе представить что это будет гораздо дороже чем некий миниатюрный процесс с файлом который периодически пытается на кафку записать

да, я об этом и говорю..

есть у нас небольшой процесс на той-же тачке, и он локально предоставляет API для записи сообщений. Их он пишет надёжно на диск, и потом асинхронно пытается записать их в Кафку

мне его самому придётся походу писать, видимо готового решения мне в экосистеме кафки не найти

мб logstash?

насколько я помню он уже умеет в очереди на диске

помоему не выйдет, мне довольно специфический API нужен 😐

короче придётся самому писать 🙃

Поделитесь потом?)

разумеется

я на самом деле пытаюсь strong consistenty поверх event sourcing’а реализовать
а Kafka’у использовать как event stream для распределения событий по экосистеме микросервисов

поэтому сам event log придётся писать собственноручно

Господа, если kafkacat выдаёт информацию по брокеру, но пишет, что 0 брокеров — это значит что-то пошло не так?

❯ kafkacat -L -b 10.0.101.1
Metadata for all topics (from broker -1: 10.0.101.1:9092/bootstrap):
 0 brokers:
 2 topics:
  topic "_confluent-metrics" with 12 partitions:
    partition 0, leader -1, replicas: 2,1,4, isrs: , Broker: Leader not available
    partition 5, leader -1, replicas: 2,4,3, isrs: , Broker: Leader not available
    partition 10, leader -1, replicas: 2,3,5, isrs: , Broker: Leader not available
    partition 8, leader -1, replicas: 1,5,4, isrs: , Broker: Leader not available
    partition 2, leader -1, replicas: 5,2,3, isrs: , Broker: Leader not available
    partition 9, leader -1, replicas: 4,1,2, isrs: , Broker: Leader not available
    partition 11, leader -1, replicas: 3,5,1, isrs: , Broker: Leader not available
    partition 4, leader -1, replicas: 4,5,1, isrs: , Broker: Leader not available
    partition 1, leader -1, replicas: 3,4,2, isrs: , Broker: Leader not available
    partition 6, leader -1, replicas: 3,2,5, isrs: , Broker: Leader not available
    partition 7, leader -1, replicas: 5,3,1, isrs: , Broker: Leader not available
    partition 3, leader -1, replicas: 1,3,5, isrs: , Broker: Leader not available
  topic "__confluent.support.metrics" with 1 partitions:
    partition 0, leader -1, replicas: 4,2,3, isrs: , Broker: Leader not available

Еще через Conduktor пытаюсь зайти, тот пишет, что видит кафку, но не может присоединиться, советует чекнуть advertised.listeners, но он уже выставлен в адрес хоста.

kafkacat причем может видеть остальных брокеров с нод брокеров, но такое чувство, что брокеры друг друга не поймали.

Плюс по логам брокеры крутятся без ошибок.

если у тебя внутри дц нетворк сплит то кафка это меньше о чем ты будешь переживать, если у тебя кафка в одном дц, в приложения в другом и такие требования то у тебя проблем еще больше чем в первом случае

всё это неважно, важно чтоб микросервис продолжал работать независимо от внешних факторов 🙂 и синхронизировал свои события асинхронно