Комментарии 6
Может дешевле было редис/хазель прикрутить, если вам БД жалко?
Редис и Хазел внутри нашего приложения не используются - любая новая интеграция кажется более сложным решением по сравнением со встроенными механизмами джава. Новая интеграция это сетевые задержки, это точка которую надо поддерживать, мониторить... - в общем на первый взгляд не кажется простым решением.
Новая интеграция это сетевые задержки
А чтение партиции всеми консьюмерами - это прям образец эффективности. Ага.
Как вы решили проблему оффсетов? Или просто забили? Что будет, когда консьюмер уйдёт в, например, STW, а остальные продолжат работать?
Есть, например, embedded hazelcast, который решил бы вашу проблему и заодно не создал бы новых.
Спасибо вам за настойчивость в решениях. Безусловно решение с распределенным кешом выглядит заманчиво и просто.
В статье описан один из вариантов, который нам показался наиболее простым в реализации и достаточно эффективным в отведенные сроки.
Проблему оффсетов для себя рассматривали как минимальную или если сказать по простому как вы и написали - забили.
Учитывая что вся проверка происходит в момент запроса от клиента - если произойдет STW или отвалится консьюмер - у клиента высветится окошко по типу 'попробуйте позже', после чего он спокойно еще раз сможет попробовать, где на вторую попытку подключения вероятность подобной проблемы уже крайне мала.
Интересная статья, всегда приятно почитать по технические реализации высоко нагруженных систем.
В текущей реализации ResultContainer используется ConcurrentHashMap, где CompletableFuture-объекты остаются в памяти до явного удаления. Если удаление по requestId по каким-либо причинам не произойдёт (например, из-за исключения в обработке или забыли вызвать remove), контейнер будет неограниченно расти. Это особенно опасно в условиях высокой нагрузки или при нестабильной работе внешнего сервиса, когда возникает много "висячих" запросов.
Чтобы это решить, можно рассмотреть использование кеширующих структур с автоудалением, например:
Guava CacheсexpireAfterWriteCaffeineсexpireAfterи ограничением размераConcurrentLinkedHashMap
Это позволит автоматически удалять устаревшие или неотработанные записи без необходимости вручную управлять очисткой. Такой подход помогает избежать утечек памяти и делает ResultContainer более устойчивым к ошибкам или недочётам в логике очистки.
Спасибо за комментарий и за то, что обратили внимание на этот аспект! Действительно, использование кеширующих структур с автоудалением — отличное решение. Интересно было бы узнать ваше мнение о том, какой из предложенных подходов вы считаете наиболее удобным в реализации и почему? Поделитесь опытом или идеями, это было очень полезно!
Асинхрон внутри синхрона