у кафка топик есть разные retention policy и мы используем compacted для таких топиков. Тоже упомянул про это в статье со ссылкой:
Таким образом любой сервис, который слушает Kafka topic, может собрать у себя актуальную реплику справочника. Но нужно не забывать, чтобы key(row i) не изменялся. В таком случае мы можем применить к kafka topic retention policy compacted. Т.к. нас интересует только последний record по ключу пусть kafka удаляет старые данные для одинаковых ключей в соответствии с retention policy.
данные именно что хранятся в 1) postgres 2) в compacted топике кафка 3) в оперативной памяти сервиса. Не знаю возможно и можно придумать название удачней, но я вас точно не обманул, данные вполне себе хранятся в топике кафка и кафка вполне себе выступает хранилищем из которого данные вытягиваются в приложение.
если сервис упал-поднялся-отжался - то все данные при инициализации сервиса будут загружены с самого начала. Посмотрите внимательней код KafkaGlobalStore, также я отдельно расписал про проблемы, что нужно тестировать и оценивать размер этих справочников, чтобы для вас не было дорого как хранение данных в оперативной памяти так и их загрузка каждый раз туда при старте сервиса. Посмотрите разделы "Потребляемые ресурсы и время загрузки" и "Что делать, если появятся большие справочники". При каждом старте приложения топик будет вычитываться сначала, также я ответил на комментарий ниже про горизонтальное масштабирования, смысл тот же - для каждого инстанса при каждом старте топик будет вычитываться заново до старта основной логики в идеале ( тут уж spring в помощь)
точно также, любой инстанс будет работать одинаков - загружать всю реплику из топика полностью. В пункте "Kafka Store Component" я об этом написал, что есть в kafka streams партицированные хранилища, есть Global Store, вот нам пока достаточно концепции Global Store - когда мы полностью всегда при старте приложения вычитываем все данные топика из всех партиций, а затем уже приложение начинает делать свою остальную работу используя справочник, при этом справочник продолжает обновляться.
Т.е. если мы запустим 10 или 20 инстансов, все 10 или 20 инстансов каждый вычитают весь топик и будут содержать в себе полные реплики справочников. Собственно про это код KafkaGlobalStore.Т.к. это Global Store можете масштабировать сколько угодно без специальных настроек и оглядки на количество партиций в топике-справочнике, все зависит только от остальной логики вашего приложения. Данная реализация никак вас не ограничивает в масштабировании.
специфика работы Postgres в компании, что Postgres предоставляется команде как сервис и служба поддержки проекта не имеет доступа, такие требования были объявлены на старте проекта. Не исключаю, что можно сделать элегантней и проще, но из тех вводных, что были, показалось, что данное решение тоже достаточно простое и эффективное, тем более что в confluent guides вполне себе описаны схожие на мой взгляд кейсы.
В целом данная статья написана еще и из интереса того, как этот "велосипед" выглядит для не замыленного взгляда, так что не исключаю :)
Из преимуществ решения для меня это то, что я имею обновляемый кэш и в тоже время полную реплику справочника в топике.
я не совсем вас понял. Kafka вполне себе выступает как хранилище, в топике хранится реплика данных из postgres.
А если бы не кафка была, все поломалось бы? :) - тоже не понял что имеется ввиду, что значит была или не была, у нас уже используется кафка, почему и как - это отдельная наверное дискуссия должна быть, кафка как сказано в начале является центральной высокодоступной системой и если она не работает, то да, все не работает - такое допущение, при этом если не работает postgres - часть системы должна функционировать
Вообще мы в наших сервисах как раз таки используем по умолчанию параметр none, чтобы в случае если кто-то в конфиге вдруг что-то перепутал и нечаенно отредактировал consumer group, чтоб не произошла вычитка сначала при такой человеческом факторе - как раз none работает как предохранитель.
Также для новой consumer group может действительно не подходить ни earliest ни latest, в этом случае можно создать consumer group через командную строку. Так собственно у нас и предполагается, что стоит none и службе поддержке при запуске сервиса нужно осознанно понимать откуда начать чтение. Если подходят latest и earliest для первого запуска, то выставляем их, но затем все равно меняем на none как предохранитель. Если не подходят - то надо вручную указать.
За живое задели, мои трамваи в Москве последние полгода уже почему то не показывает:) но это скорей всего сбой московского транспорта, у них и табло работаю черти как на остановках
Если сравнивать производительность для конечно точки, то JAR работает стабильно лучше. - не очень понял это предложение
Спасибо за статью.
Сделал для себя вывод, что кажется 7 процентов того не стоят, сколько особенностей настройки стоит держать в голове. Да и если я правильно понимаю, то в итоге есть вероятность, что с jit оптимизациями приложение будет работать даже быстрей, чем native image
да, понятно, что и нас догонит инфляция, но не так моментально для большей части товаров. по-моему очевидная мудрость - зарабатывать или в долларах или в валюте той страны, в которой живешь хотя бы, по моему это какая-то очевидная реальность, поэтому и статья и выглядит, как плач подростка только-только начавшего работать и столкнувшегося с реальностью, что не везде и не всегда будут смузи сколько захочешь бесплатно наливать и попу подтирать.
Так наивно, что как будто пост подростка, как ребенок взрослея сталкивается с реальностью: что в магазине нужно платить за продукты, что каждый месяц надо за коммуналку платить и то, что любой работодатель не будет обеспечивать ваш ожидаемый уровень жизни в любой точке мира( хорошо если в одной отдельно взятой стране обеспечивает, индексируя регулярно зарплату), ну если вы конечно не штучный инженер. Очень много говорит о возрасте автора/авторки. Этот пузырь зарплат, который был до февраля 22го воспитал непуганое поколение итишников.
Вам бы радоваться, что уехав из страны у вас сохранился какой никакой доход и не терять время и искать работу за твердую валюту, а Вы банально теряли и теряете время. Вот Авито судя по всему времени не теряли, решили сначала закрыть риски, что все разбегутся, предложив условия работы за границей, а теперь посчитали и поняли, что уже можно и не напрягаться, видимо набрали достаточно на внутреннем рынке.
Мой работодатель например сразу уволил всех выехавших, дав время на подумать, в силу специфики бизнеса. Так что Вам бы радоваться, что у Вас не было такого стресса, как например у моих бывших коллег, которым пришлось судорожно искать работу да еще и обживаться на новом месте. Уже пора бы повзрослеть и понимать, что никто Вам ничего не должен, как и Вы ничего не должны работодатель, не важно Авито это или кто-то другой, - ничего личного, только бизнес, смотрите свой договор и если он нарушен, то смело идите в суд.
В мире много разных валют, учитывайте это при переезде и даже просто в путешествии.
Такое ощущение, что корпоративный аккаунт Сбера угнали :) В Сбере не делают ревью перед публикацией в корпоративном аккаунте? Вообще не понятно о чем, к чему и с какой целью написано, а название интриговало... Реально похоже на что-то сгенерированное chatgpt или студентом.
Больше всего в во внутрикорпоративном труконфе нравится фича по которой всех выкидывает по истечении времени, запланированного в календаре. За минуту до окончания встречи у всех начинается паника, что нас счас выкинет, а вроде ещё есть что обсудить. И только истинные знатоки умеют создать встречу так, чтоб она не была ограничена по времени. Спасибо что заботитесь о чётких границах встречи!
Да, я с Вами согласен, возможно в будущем придется поддержать что-то типа@DependsOn,пока для начала, для решения текущих задач мне достаточно такой реализации, в процессе эксплуатации данного подход возможно понадобится дополнить функциональность постпроцессора. Как я упомянул в статье, сначала вообще хотелось сделать какую-то универсальную выгрузку и загрузку бина из контекста по этому событию, но немного погрузившись понял, что много чего нужно учесть и вряд ли это будет "универсально". Так что за полной универсальностью не гонюсь, будем решать проблемы по мере поступления. В любом случае, даже используя стандартные библиотеки springa все равно надо понимать как это работает, как и в случае с моим постпроцессором, чтобы понимать правильно ли работает разработанное приложение.
Я как будто читаю BRD для внутреннего пользования, представить что такой документ может быть интересен кому то извне - сложно.
Зачем изобретать велосипед, если перед глазами есть успех ушедших иностранных сервисов. До ухода букинг был самой популярной площадкой бронирования, думаю потому что предоставлял хороший сервис. Я знать не знаю какие у них там были алгоритмы, транзакции, но я точно знаю, что когда я бронировал на букинг я мог быть +- уверен даже на наших российских югах будет где переночевать. Не важно было ли это с бесплатной отменой бронирования или полной оплатой. А если и были проблемы, то служба поддержки в любой части мира как правило реально помогала. Сделайте что-то сравнимое с этим и весь рынок будет Ваш. Пока я не знаю настолько ответственный отечественный сервис. Все эти островки, суточно, броневики...
у кафка топик есть разные retention policy и мы используем compacted для таких топиков. Тоже упомянул про это в статье со ссылкой:
Таким образом любой сервис, который слушает Kafka topic, может собрать у себя актуальную реплику справочника. Но нужно не забывать, чтобы key(row i) не изменялся. В таком случае мы можем применить к kafka topic retention policy compacted. Т.к. нас интересует только последний record по ключу пусть kafka удаляет старые данные для одинаковых ключей в соответствии с retention policy.
а я не понимаю вашего смятения:)
данные именно что хранятся в 1) postgres 2) в compacted топике кафка 3) в оперативной памяти сервиса. Не знаю возможно и можно придумать название удачней, но я вас точно не обманул, данные вполне себе хранятся в топике кафка и кафка вполне себе выступает хранилищем из которого данные вытягиваются в приложение.
если сервис упал-поднялся-отжался - то все данные при инициализации сервиса будут загружены с самого начала. Посмотрите внимательней код KafkaGlobalStore, также я отдельно расписал про проблемы, что нужно тестировать и оценивать размер этих справочников, чтобы для вас не было дорого как хранение данных в оперативной памяти так и их загрузка каждый раз туда при старте сервиса. Посмотрите разделы "Потребляемые ресурсы и время загрузки" и "Что делать, если появятся большие справочники". При каждом старте приложения топик будет вычитываться сначала, также я ответил на комментарий ниже про горизонтальное масштабирования, смысл тот же - для каждого инстанса при каждом старте топик будет вычитываться заново до старта основной логики в идеале ( тут уж spring в помощь)
точно также, любой инстанс будет работать одинаков - загружать всю реплику из топика полностью. В пункте "Kafka Store Component" я об этом написал, что есть в kafka streams партицированные хранилища, есть Global Store, вот нам пока достаточно концепции Global Store - когда мы полностью всегда при старте приложения вычитываем все данные топика из всех партиций, а затем уже приложение начинает делать свою остальную работу используя справочник, при этом справочник продолжает обновляться.
Т.е. если мы запустим 10 или 20 инстансов, все 10 или 20 инстансов каждый вычитают весь топик и будут содержать в себе полные реплики справочников. Собственно про это код
KafkaGlobalStore.Т.к. это Global Store можете масштабировать сколько угодно без специальных настроек и оглядки на количество партиций в топике-справочнике, все зависит только от остальной логики вашего приложения. Данная реализация никак вас не ограничивает в масштабировании.специфика работы Postgres в компании, что Postgres предоставляется команде как сервис и служба поддержки проекта не имеет доступа, такие требования были объявлены на старте проекта. Не исключаю, что можно сделать элегантней и проще, но из тех вводных, что были, показалось, что данное решение тоже достаточно простое и эффективное, тем более что в confluent guides вполне себе описаны схожие на мой взгляд кейсы.
В целом данная статья написана еще и из интереса того, как этот "велосипед" выглядит для не замыленного взгляда, так что не исключаю :)
Из преимуществ решения для меня это то, что я имею обновляемый кэш и в тоже время полную реплику справочника в топике.
я не совсем вас понял. Kafka вполне себе выступает как хранилище, в топике хранится реплика данных из postgres.
А если бы не кафка была, все поломалось бы? :) - тоже не понял что имеется ввиду, что значит была или не была, у нас уже используется кафка, почему и как - это отдельная наверное дискуссия должна быть, кафка как сказано в начале является центральной высокодоступной системой и если она не работает, то да, все не работает - такое допущение, при этом если не работает postgres - часть системы должна функционировать
Вообще мы в наших сервисах как раз таки используем по умолчанию параметр none, чтобы в случае если кто-то в конфиге вдруг что-то перепутал и нечаенно отредактировал consumer group, чтоб не произошла вычитка сначала при такой человеческом факторе - как раз none работает как предохранитель.
Также для новой consumer group может действительно не подходить ни earliest ни latest, в этом случае можно создать consumer group через командную строку. Так собственно у нас и предполагается, что стоит none и службе поддержке при запуске сервиса нужно осознанно понимать откуда начать чтение. Если подходят latest и earliest для первого запуска, то выставляем их, но затем все равно меняем на none как предохранитель. Если не подходят - то надо вручную указать.
За живое задели, мои трамваи в Москве последние полгода уже почему то не показывает:) но это скорей всего сбой московского транспорта, у них и табло работаю черти как на остановках
Если сравнивать производительность для конечно точки, то JAR работает стабильно лучше. - не очень понял это предложение
Спасибо за статью.
Сделал для себя вывод, что кажется 7 процентов того не стоят, сколько особенностей настройки стоит держать в голове. Да и если я правильно понимаю, то в итоге есть вероятность, что с jit оптимизациями приложение будет работать даже быстрей, чем native image
да, понятно, что и нас догонит инфляция, но не так моментально для большей части товаров. по-моему очевидная мудрость - зарабатывать или в долларах или в валюте той страны, в которой живешь хотя бы, по моему это какая-то очевидная реальность, поэтому и статья и выглядит, как плач подростка только-только начавшего работать и столкнувшегося с реальностью, что не везде и не всегда будут смузи сколько захочешь бесплатно наливать и попу подтирать.
Так наивно, что как будто пост подростка, как ребенок взрослея сталкивается с реальностью: что в магазине нужно платить за продукты, что каждый месяц надо за коммуналку платить и то, что любой работодатель не будет обеспечивать ваш ожидаемый уровень жизни в любой точке мира( хорошо если в одной отдельно взятой стране обеспечивает, индексируя регулярно зарплату), ну если вы конечно не штучный инженер. Очень много говорит о возрасте автора/авторки. Этот пузырь зарплат, который был до февраля 22го воспитал непуганое поколение итишников.
Вам бы радоваться, что уехав из страны у вас сохранился какой никакой доход и не терять время и искать работу за твердую валюту, а Вы банально теряли и теряете время. Вот Авито судя по всему времени не теряли, решили сначала закрыть риски, что все разбегутся, предложив условия работы за границей, а теперь посчитали и поняли, что уже можно и не напрягаться, видимо набрали достаточно на внутреннем рынке.
Мой работодатель например сразу уволил всех выехавших, дав время на подумать, в силу специфики бизнеса. Так что Вам бы радоваться, что у Вас не было такого стресса, как например у моих бывших коллег, которым пришлось судорожно искать работу да еще и обживаться на новом месте. Уже пора бы повзрослеть и понимать, что никто Вам ничего не должен, как и Вы ничего не должны работодатель, не важно Авито это или кто-то другой, - ничего личного, только бизнес, смотрите свой договор и если он нарушен, то смело идите в суд.
В мире много разных валют, учитывайте это при переезде и даже просто в путешествии.
Такое ощущение, что корпоративный аккаунт Сбера угнали :) В Сбере не делают ревью перед публикацией в корпоративном аккаунте? Вообще не понятно о чем, к чему и с какой целью написано, а название интриговало... Реально похоже на что-то сгенерированное chatgpt или студентом.
Больше всего в во внутрикорпоративном труконфе нравится фича по которой всех выкидывает по истечении времени, запланированного в календаре. За минуту до окончания встречи у всех начинается паника, что нас счас выкинет, а вроде ещё есть что обсудить. И только истинные знатоки умеют создать встречу так, чтоб она не была ограничена по времени. Спасибо что заботитесь о чётких границах встречи!
Да, я с Вами согласен, возможно в будущем придется поддержать что-то типа@DependsOn,пока для начала, для решения текущих задач мне достаточно такой реализации, в процессе эксплуатации данного подход возможно понадобится дополнить функциональность постпроцессора. Как я упомянул в статье, сначала вообще хотелось сделать какую-то универсальную выгрузку и загрузку бина из контекста по этому событию, но немного погрузившись понял, что много чего нужно учесть и вряд ли это будет "универсально". Так что за полной универсальностью не гонюсь, будем решать проблемы по мере поступления. В любом случае, даже используя стандартные библиотеки springa все равно надо понимать как это работает, как и в случае с моим постпроцессором, чтобы понимать правильно ли работает разработанное приложение.
Про крупно-калиберную пушку не понял:)
Да, правильно, спасибо! поправил
Я как будто читаю BRD для внутреннего пользования, представить что такой документ может быть интересен кому то извне - сложно.
Зачем изобретать велосипед, если перед глазами есть успех ушедших иностранных сервисов. До ухода букинг был самой популярной площадкой бронирования, думаю потому что предоставлял хороший сервис. Я знать не знаю какие у них там были алгоритмы, транзакции, но я точно знаю, что когда я бронировал на букинг я мог быть +- уверен даже на наших российских югах будет где переночевать. Не важно было ли это с бесплатной отменой бронирования или полной оплатой. А если и были проблемы, то служба поддержки в любой части мира как правило реально помогала. Сделайте что-то сравнимое с этим и весь рынок будет Ваш. Пока я не знаю настолько ответственный отечественный сервис. Все эти островки, суточно, броневики...