N — несколько тысяч, в перспективе — несколько десятков миллионов. Спасибо за наводку на exactly-once, вроде то что надо.
Есть еще вопрос. Можно ли с Кафка реализовать следующее?
1. Продюсеры пишут сообщение в конкретный топик и конкретную секцию
2. Консюмеры опрашивают брокера на наличие новых сообщений в топике (без привязки к секции)
3. Брокер отдает (одновременно) неограниченное количество сообщений из топика но не больше одного сообщения из конкретной секции.
Если это возможно, то это будет идеальным решением для меня.
Спасибо.
Понимаю, что не SO, но просто кто-то как-то намекнул, что Kafka возможно сможет мне помочь. Допустим есть такая задача, которая сегодня решена (очень плохо решена) с помощью RabbitMq и поможет ли Kafka с ней справиться?
Есть N продюсеров, публикующих сообщения и порядок сообщений от каждого продюсера критично важен, а так же N — величина не постоянная, нужно реагировать на ее увеличение и уменьшение. Сообщения публикуются примерно раз в 4 сек, обработка занимает 2-3 сек, но иногда бывают временные сбои из-за которых обработка занимает порядка 6-20 сек.
Сегодня для каждого продюсера выделена очередь в которую он пишет и для каждой очереди есть консюмер (Kubernetes Pod) который из нее читает. Неоправданно дорогое решение, ведь каждая реплика консюмера может одновременно читать с 10, а то и больше очередей. Трудность заключается в том, что если каждому Pod'у заранее давать список очередей, которые он должен слушать, то при появлении новой очереди, невозможно назначить ее обработчиком уже существующий Pod. С другой стороны, если Pod'у динамически назначать очереди для прослушивания, то при падении, такой Pod потеряет информацию о назначенных ему очередях, а значит эти очереди «повиснут в воздухе».
Есть идея решения этой проблемы, но придется общаться с Kubernetes Api чего бы хотелось избежать.
Так вот, кто нибудь может предложить, как можно сэкономить на консюмерах, и что для этого может предложить Kafka?
Бизнес логика требовала раз в секунду скачивать HLS плейлист и проверять не появилась ли там новая запись, если появилась, то новый файл (или файлы) скачивался на диск (с помощью HttpClient). Под Windows все работало прекрасно, а вот в Docker под Linux начались проблемы: скачивание плейлиста занимало от 3 до 6 секунд. То же самое происходило с файлами (~200 KB). Что бы узнать проблема в Docker или в Linux код был запущен на Linux машине без Docker'а, как оказалось Docker здесь не причем. Потом я наткнулся на этот блог: https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
Изменив имплементацию на повторное использование HttpClient, все идеально заработало под Linux'ом, а под Windows стало работать еще быстрее.
Вопрос к знатокам: почему такая огромная разница в поведении HttpClient под Windows и Linux?
Теперь берем тот же гороскоп, рандомально меняем знаки и описания к ним и постим в другом месте. А там снова все находят что-то общее с собой. Именно так работают все гороскопы :)
Странно, при добавлении комментария часть текста пропала. Имелось в виду «Например, выполнили проверку X<=0 и бросили исключение, а дальше по коду проверили (X>0 && Y>0)»
Мне кажется, что не стоит каждый «всегда лживый/истинный» код считать ошибкой. Иногда это просто защита от дурака. Например, выполнили проверку X0 && Y>0), просто на случай, что кто-нибудь в будущем может, скажем, убрать знак '=' в первой проверку, просто потому что между двумя проверками появится новый код, который будет требовать этого. И вот, из за невнимательности он создал баг, которого можно было избежать за долго до его появления.
К тому же, иногда полная проверка (X>0 && Y>0) имеет какой-то смысл, например в математической формуле и сразу будет бросаться в глаза знающему человеку, который поймет что именно здесь высчитывается та самая часть формулы.
Спасибо, это то что надо!
Есть еще вопрос. Можно ли с Кафка реализовать следующее?
1. Продюсеры пишут сообщение в конкретный топик и конкретную секцию
2. Консюмеры опрашивают брокера на наличие новых сообщений в топике (без привязки к секции)
3. Брокер отдает (одновременно) неограниченное количество сообщений из топика но не больше одного сообщения из конкретной секции.
Если это возможно, то это будет идеальным решением для меня.
Спасибо.
Есть N продюсеров, публикующих сообщения и порядок сообщений от каждого продюсера критично важен, а так же N — величина не постоянная, нужно реагировать на ее увеличение и уменьшение. Сообщения публикуются примерно раз в 4 сек, обработка занимает 2-3 сек, но иногда бывают временные сбои из-за которых обработка занимает порядка 6-20 сек.
Сегодня для каждого продюсера выделена очередь в которую он пишет и для каждой очереди есть консюмер (Kubernetes Pod) который из нее читает. Неоправданно дорогое решение, ведь каждая реплика консюмера может одновременно читать с 10, а то и больше очередей. Трудность заключается в том, что если каждому Pod'у заранее давать список очередей, которые он должен слушать, то при появлении новой очереди, невозможно назначить ее обработчиком уже существующий Pod. С другой стороны, если Pod'у динамически назначать очереди для прослушивания, то при падении, такой Pod потеряет информацию о назначенных ему очередях, а значит эти очереди «повиснут в воздухе».
Есть идея решения этой проблемы, но придется общаться с Kubernetes Api чего бы хотелось избежать.
Так вот, кто нибудь может предложить, как можно сэкономить на консюмерах, и что для этого может предложить Kafka?
https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
Изменив имплементацию на повторное использование HttpClient, все идеально заработало под Linux'ом, а под Windows стало работать еще быстрее.
Вопрос к знатокам: почему такая огромная разница в поведении HttpClient под Windows и Linux?
К тому же, иногда полная проверка (X>0 && Y>0) имеет какой-то смысл, например в математической формуле и сразу будет бросаться в глаза знающему человеку, который поймет что именно здесь высчитывается та самая часть формулы.