Спасибо, интересный вариант для роли шины данных! Garnet действительно выглядит интересно — особенно с учётом заявленной производительности и кластера "из коробки". Судя по их тестам, он обгоняет Redis. Посмотрим, как покажет себя в реальных условиях.
В принципе, для таких целей можно использовать и Postgres через LISTEN/NOTIFY — как простую, встроенную шину. Но... давайте честно: PostgreSQL и без того не всегда знает, куда деваться от нагрузки, а тут мы ещё и события хотим через него гонять :)
У нас Redis и так используется как кеш во многих сервисах, поэтому он оказался естественным выбором и для Pub/Sub — ничего нового подключать, конфигурировать или поддерживать не нужно. Проверено, стабильно, понятно всем в команде.
Но в целом круто, что появляются альтернативы вроде Garnet. Особенно если они в будущем дорастут до продакшен-уровня и будут поддерживать всё то, что уже стабильно работает в Redis. Буду с интересом следить за развитием.
Спасибо! Да, уже пару человек сказали, что обсуждение получилось даже "полезнее" статьи — в любом случае приятно, что люди нашли время прочитать и поучаствовать в беседе :)
Если коротко: в нашей практике Redis сам по себе не падал. Прямых инцидентов с его отказами не было.
Использование Redis с Sentinel у нас — это архитектурно утверждённый стандарт (насколько мне известно). Одиночный Redis считается потенциальной точкой отказа, поэтому отказоустойчивость через Sentinel закладывается на этапе проектирования — не как реакция на сбои, а как часть принятой инженерной политики.
Примеры в статье — рабочие, конфигурация проверена, всё запускается. Специального нагрузочного тестирования Pub/Sub мы не проводили, но на текущей нагрузке система работает более чем стабильно.
Ваш подход с упором на минимально достаточную конфигурацию вполне понятен. Redis даже в одиночном экземпляре обладает хорошим запасом прочности и в большинстве случаев работает надёжно. Если push-уведомления не критичны и система может обойтись без автоматической отказоустойчивости — обычный Redis справляется с задачей. Всё зависит от контекста, объёма и требований конкретной системы.
Да, sticky-сессии могут помочь в простых случаях, но здесь они не решают основную проблему. Событие может произойти в любом поде сервиса и не связано с конкретной сессией пользователя. Если клиент подключён ко второй поде, а событие произошло в первой — он его просто не получит.
В таких сценариях нужен общий канал, через который все поды узнают о событии и смогут передать его клиентам. Для этого используется Redis Pub/Sub, а сама рассылка уведомлений вынесена в отдельный сервис — чтобы не дублировать эту логику в каждом микросервисе.
Наверное, стоило добавить схему, чтобы это было видно наглядно. В этот раз сосредоточился на коде и примерах, но в следующих статьях обязательно добавлю визуализацию.
Интересный комментарий, такой подход действительно возможен.
Да, при использовании уникального group.id на каждую реплику Kafka действительно рассылает одно и то же сообщение в каждую consumer group — технически это реализуемо и будет работать.
Но для нашей задачи это оказалось избыточным по нескольким причинам:
1. Kafka будет дублировать доставку сообщения в каждую группу отдельно. При увеличении числа реплик такая схема начинает нагружать брокер.
2. В динамическом окружении, вроде Kubernetes, сложно гарантировать уникальность group.id для каждой поды. Это требует дополнительной обвязки или авто-генерации конфигурации.
3. Если пода была перезапущена (например, во время деплоя), Kafka сохраняет для неё накопившиеся сообщения, и после восстановления она начнёт их вычитывать. Это приведёт к тому, что в UI будут отправлены устаревшие события, которых по факту уже не должно быть, и фронт может сделать лишние запросы к бэкенду.
В нашем случае push-уведомления нужны "на сейчас", история и ретраи не требуются. Если пользователь не получил событие — он просто увидит актуальное состояние при следующем действии.
Поэтому Redis Pub/Sub оказался проще и лучше подходящим для такой задачи — все поды получают событие сразу, без лишней обработки и хранения.
Да, Redis не хранит события, но у нас обычно настроено бесшовное обновление с двумя или более работающими подами. Пока один обновляется, другие продолжают слушать Redis. Уведомления не теряются, всё работает в реальном времени
Ну и на всякий случай: если уведомление потеряется — всё равно можно нажать F5 ;)
Спасибо за хороший вопрос! Да, Kafka, NATS, RabbitMQ — это отличныеи и мощные брокеры. Но у нас немного другой кейс.
Нам нужно просто отправить уведомления в UI: пользователь должен сразу увидеть изменение (например, что вагон разгрузили). Эти события не критичны, мы специально не храним их историю. Если что-то «улетело» — не страшно, фронт всегда может получить актуальное состояние вручную.
Kafka и ей подобные — отличны для сложных сценариев, но вот с какими моментами придётся столкнуться в нашем случае:
offset'ы: если сервис уведомлений был недоступен какое-то время, Kafka при восстановлении высыпит всю очередь сообщений — что нам тут вообще не нужно. В итоге на UI приходят старые и ненужные события, и фронт начёт спамить по бэку запросами.
consumer-группы: нам важно, чтобы все поды получали события. А с Kafka надо городить схемы с разными groupId, чтобы не получилось, что один получил — а второй не узнал.
история: повторюсь — нам не понадобится она для этой задачи, события "одноразовые" и живут ровно до момента отображения.
А Redis даёт простой и быстрый Pub/Sub. Все поды получают события одновременно, нет лишнего слоя абстракции и инфраструктуры. Плюс бонусом — это ещё и распределённый кэш, который пригодится не только для real-time.
Поэтому в таких задачах Redis выглядит как самое простое и при этом эффективное решение.
Благодарю за ваш интерес! Мы активно используем ChatGPT для автоматизации процесса создания документации архитектуры приложений. Например, инструмент может подключиться к контексту приложения и автоматически генерировать подробные описания модулей и их взаимодействия, что значительно ускоряет и упрощает документирование. Ранее этот процесс занимал у нас несколько дней, а теперь может быть завершен в течение нескольких часов, освобождая нашу команду для сосредоточения на более стратегических задачах.
Кроме того, ChatGPT помогает нам анализировать обратную связь от пользователей. Например, он классифицирует отзывы и выделяет повторяющиеся темы, позволяя нам быстро идентифицировать области для улучшения. В проектах автоматизации поддержки клиентов ChatGPT используется в чат-ботах, которые обрабатывают более 70% стандартных запросов пользователей, что значительно повышает эффективность нашей работы и улучшает общий пользовательский опыт.
Согласен с вами. Сначала нужно найти кандидата, что может занять около двух недель или больше. Затем важно, чтобы кандидат устроил всех по зарплате и соответствовал требованиям собеседования. Часто кандидат, подходящий по всем критериям, называет зарплату на 50 - 100 тысяч больше, чем тот, кто ушел. Пока проект стоит, время идет. В итоге соглашаются на сотрудника с более высокими зарплатными ожиданиями, чем у ушедшего.
Также важно учитывать, что новый кандидат начинает работать через примерно месяц: неделя — на обдумывание предложения, две недели — на отработку, и еще неделя или две — на получение и настройку рабочего оборудования. Затем он начинает вникать в проект. В общем, это вопрос значительного времени, которого у работодателя обычно нет.
Когда я пришёл в НЛМК 4 года назад, у меня был определённый скепсис. Несмотря на рассказы о высокотехнологичной и приятной рабочей среде, я не был до конца уверен.
Начав работать, я убедился, что здесь действительно есть всё необходимое: современное оборудование, крутой стек технологий, включая Java, которая на момент моего прихода была версией 11, но теперь все пишут на Java 21, и сервисы активно мигрируют на новую версию. Здесь используются микросервисы, машинное зрение, OKD, Elasticsearch, отлично отлаженные CI/CD процессы и грамотная команда девопсов. Легкая интеграция достигается за счёт использования асинхронных технологий, таких как Apache Kafka. Более того, в разработке активно стали использовать ChatGPT для автоматизации процессов и улучшения взаимодействия с данными.
Аналитики превосходно описывают задачи, а получить обратную связь от пользователей не составляет труда. Здесь никогда не возникает ситуации, когда ожидают, что ты сам будешь разбираться с чем-то непонятным — всегда есть коллеги, готовые помочь и поделиться знаниями. Также здесь есть саппорт, команда тестировщиков и разработчиков.
Руководство и HR-команда эффективно поддерживают рабочие процессы, создавая условия для комфортной работы и профессионального роста. Со временем я понял, что здесь предоставляются уникальные возможности и условия, которые сложно найти где-либо ещё.
Сейчас я вам расскажу, как правильно нужно расти, в it. Пришел на проект. На проект поишел еще один разраб. Отработал пол года и сходил по собесам, принес офер на 100 тыс больше. Дальше разговор простой либо мне тут дают столько же либо я пошел. Мне дали я остался отработал еще пол года. Сходил по собесам принес офер еще на 100 больше мне опять увеличели зп. Я еще годик работал справно и честно и изо всех сил. ( плюс была ежегодная индексация). Потом работодатель заметил что я хорошо работаю и решили сделать мне ассесмент и еще одному разрабу. Так вот он все это время не ходил и не просил денег и получается что у меня зп повышалась 2 раза и еще сейчас третий. А у него почтиза три года первый раз и разница у нас в зп колоссальная. И т.к. сделали ассесмент я считаю можно еще годик честно поработать и дальше опять по собесам т.к. ассесмент не светит. Если контр офер не дадут то уйду к новому работодателю я ничего не теряю. Вот. Так надо рости просто так тебе зп никто не добавит и я сейчас на коне, а тот разраб который не просил ни разу денег - он под конём. Выводы делайте сами.
Ps: совет когда hr спрашивает чем мы вас можем заинтересовать кроме денег- я всегда отвечаю честно : " Где нет денег - там и интереса нет... "
История выдуманная, все совпадения случайны. ;) или может не случайны?
Компании, имеющие адекватные стандарты собеседования и ищущие специалистов для решения задач либо ушли, либо уже имеют таких специалистов, а они в свою очередь знают, что сейчас на рынке, поэтому и не покидают свои места
Спасибо, интересный вариант для роли шины данных! Garnet действительно выглядит интересно — особенно с учётом заявленной производительности и кластера "из коробки". Судя по их тестам, он обгоняет Redis. Посмотрим, как покажет себя в реальных условиях.
В принципе, для таких целей можно использовать и Postgres через LISTEN/NOTIFY — как простую, встроенную шину. Но... давайте честно: PostgreSQL и без того не всегда знает, куда деваться от нагрузки, а тут мы ещё и события хотим через него гонять :)
У нас Redis и так используется как кеш во многих сервисах, поэтому он оказался естественным выбором и для Pub/Sub — ничего нового подключать, конфигурировать или поддерживать не нужно. Проверено, стабильно, понятно всем в команде.
Но в целом круто, что появляются альтернативы вроде Garnet. Особенно если они в будущем дорастут до продакшен-уровня и будут поддерживать всё то, что уже стабильно работает в Redis. Буду с интересом следить за развитием.
Спасибо! Да, уже пару человек сказали, что обсуждение получилось даже "полезнее" статьи — в любом случае приятно, что люди нашли время прочитать и поучаствовать в беседе :)
Спасибо за отличный вопрос — по существу.
Если коротко: в нашей практике Redis сам по себе не падал. Прямых инцидентов с его отказами не было.
Использование Redis с Sentinel у нас — это архитектурно утверждённый стандарт (насколько мне известно). Одиночный Redis считается потенциальной точкой отказа, поэтому отказоустойчивость через Sentinel закладывается на этапе проектирования — не как реакция на сбои, а как часть принятой инженерной политики.
Примеры в статье — рабочие, конфигурация проверена, всё запускается. Специального нагрузочного тестирования Pub/Sub мы не проводили, но на текущей нагрузке система работает более чем стабильно.
Ваш подход с упором на минимально достаточную конфигурацию вполне понятен. Redis даже в одиночном экземпляре обладает хорошим запасом прочности и в большинстве случаев работает надёжно. Если push-уведомления не критичны и система может обойтись без автоматической отказоустойчивости — обычный Redis справляется с задачей. Всё зависит от контекста, объёма и требований конкретной системы.
Да, sticky-сессии могут помочь в простых случаях, но здесь они не решают основную проблему. Событие может произойти в любом поде сервиса и не связано с конкретной сессией пользователя. Если клиент подключён ко второй поде, а событие произошло в первой — он его просто не получит.
В таких сценариях нужен общий канал, через который все поды узнают о событии и смогут передать его клиентам. Для этого используется Redis Pub/Sub, а сама рассылка уведомлений вынесена в отдельный сервис — чтобы не дублировать эту логику в каждом микросервисе.
Наверное, стоило добавить схему, чтобы это было видно наглядно. В этот раз сосредоточился на коде и примерах, но в следующих статьях обязательно добавлю визуализацию.
Интересный комментарий, такой подход действительно возможен.
Да, при использовании уникального group.id на каждую реплику Kafka действительно рассылает одно и то же сообщение в каждую consumer group — технически это реализуемо и будет работать.
Но для нашей задачи это оказалось избыточным по нескольким причинам:
1. Kafka будет дублировать доставку сообщения в каждую группу отдельно. При увеличении числа реплик такая схема начинает нагружать брокер.
2. В динамическом окружении, вроде Kubernetes, сложно гарантировать уникальность group.id для каждой поды. Это требует дополнительной обвязки или авто-генерации конфигурации.
3. Если пода была перезапущена (например, во время деплоя), Kafka сохраняет для неё накопившиеся сообщения, и после восстановления она начнёт их вычитывать. Это приведёт к тому, что в UI будут отправлены устаревшие события, которых по факту уже не должно быть, и фронт может сделать лишние запросы к бэкенду.
В нашем случае push-уведомления нужны "на сейчас", история и ретраи не требуются. Если пользователь не получил событие — он просто увидит актуальное состояние при следующем действии.
Поэтому Redis Pub/Sub оказался проще и лучше подходящим для такой задачи — все поды получают событие сразу, без лишней обработки и хранения.
Да, Redis не хранит события, но у нас обычно настроено бесшовное обновление с двумя или более работающими подами. Пока один обновляется, другие продолжают слушать Redis. Уведомления не теряются, всё работает в реальном времени
Ну и на всякий случай: если уведомление потеряется — всё равно можно нажать F5 ;)
Спасибо за хороший вопрос! Да, Kafka, NATS, RabbitMQ — это отличныеи и мощные брокеры. Но у нас немного другой кейс.
Нам нужно просто отправить уведомления в UI: пользователь должен сразу увидеть изменение (например, что вагон разгрузили). Эти события не критичны, мы специально не храним их историю. Если что-то «улетело» — не страшно, фронт всегда может получить актуальное состояние вручную.
Kafka и ей подобные — отличны для сложных сценариев, но вот с какими моментами придётся столкнуться в нашем случае:
offset'ы: если сервис уведомлений был недоступен какое-то время, Kafka при восстановлении высыпит всю очередь сообщений — что нам тут вообще не нужно. В итоге на UI приходят старые и ненужные события, и фронт начёт спамить по бэку запросами.
consumer-группы: нам важно, чтобы все поды получали события. А с Kafka надо городить схемы с разными groupId, чтобы не получилось, что один получил — а второй не узнал.
история: повторюсь — нам не понадобится она для этой задачи, события "одноразовые" и живут ровно до момента отображения.
А Redis даёт простой и быстрый Pub/Sub. Все поды получают события одновременно, нет лишнего слоя абстракции и инфраструктуры. Плюс бонусом — это ещё и распределённый кэш, который пригодится не только для real-time.
Поэтому в таких задачах Redis выглядит как самое простое и при этом эффективное решение.
'азино три топора - поднять бобла'...)))
Благодарю за ваш интерес! Мы активно используем ChatGPT для автоматизации процесса создания документации архитектуры приложений. Например, инструмент может подключиться к контексту приложения и автоматически генерировать подробные описания модулей и их взаимодействия, что значительно ускоряет и упрощает документирование. Ранее этот процесс занимал у нас несколько дней, а теперь может быть завершен в течение нескольких часов, освобождая нашу команду для сосредоточения на более стратегических задачах.
Кроме того, ChatGPT помогает нам анализировать обратную связь от пользователей. Например, он классифицирует отзывы и выделяет повторяющиеся темы, позволяя нам быстро идентифицировать области для улучшения. В проектах автоматизации поддержки клиентов ChatGPT используется в чат-ботах, которые обрабатывают более 70% стандартных запросов пользователей, что значительно повышает эффективность нашей работы и улучшает общий пользовательский опыт.
Согласен с вами. Сначала нужно найти кандидата, что может занять около двух недель или больше. Затем важно, чтобы кандидат устроил всех по зарплате и соответствовал требованиям собеседования. Часто кандидат, подходящий по всем критериям, называет зарплату на 50 - 100 тысяч больше, чем тот, кто ушел. Пока проект стоит, время идет. В итоге соглашаются на сотрудника с более высокими зарплатными ожиданиями, чем у ушедшего.
Также важно учитывать, что новый кандидат начинает работать через примерно месяц: неделя — на обдумывание предложения, две недели — на отработку, и еще неделя или две — на получение и настройку рабочего оборудования. Затем он начинает вникать в проект. В общем, это вопрос значительного времени, которого у работодателя обычно нет.
Когда я пришёл в НЛМК 4 года назад, у меня был определённый скепсис. Несмотря на рассказы о высокотехнологичной и приятной рабочей среде, я не был до конца уверен.
Начав работать, я убедился, что здесь действительно есть всё необходимое: современное оборудование, крутой стек технологий, включая Java, которая на момент моего прихода была версией 11, но теперь все пишут на Java 21, и сервисы активно мигрируют на новую версию. Здесь используются микросервисы, машинное зрение, OKD, Elasticsearch, отлично отлаженные CI/CD процессы и грамотная команда девопсов. Легкая интеграция достигается за счёт использования асинхронных технологий, таких как Apache Kafka. Более того, в разработке активно стали использовать ChatGPT для автоматизации процессов и улучшения взаимодействия с данными.
Аналитики превосходно описывают задачи, а получить обратную связь от пользователей не составляет труда. Здесь никогда не возникает ситуации, когда ожидают, что ты сам будешь разбираться с чем-то непонятным — всегда есть коллеги, готовые помочь и поделиться знаниями. Также здесь есть саппорт, команда тестировщиков и разработчиков.
Руководство и HR-команда эффективно поддерживают рабочие процессы, создавая условия для комфортной работы и профессионального роста. Со временем я понял, что здесь предоставляются уникальные возможности и условия, которые сложно найти где-либо ещё.
Капитан очевидность))
Не надо из хобби делать работу ;) иначе это будет работа
Сейчас я вам расскажу, как правильно нужно расти, в it. Пришел на проект. На проект поишел еще один разраб. Отработал пол года и сходил по собесам, принес офер на 100 тыс больше. Дальше разговор простой либо мне тут дают столько же либо я пошел. Мне дали я остался отработал еще пол года. Сходил по собесам принес офер еще на 100 больше мне опять увеличели зп. Я еще годик работал справно и честно и изо всех сил. ( плюс была ежегодная индексация). Потом работодатель заметил что я хорошо работаю и решили сделать мне ассесмент и еще одному разрабу. Так вот он все это время не ходил и не просил денег и получается что у меня зп повышалась 2 раза и еще сейчас третий. А у него почтиза три года первый раз и разница у нас в зп колоссальная. И т.к. сделали ассесмент я считаю можно еще годик честно поработать и дальше опять по собесам т.к. ассесмент не светит. Если контр офер не дадут то уйду к новому работодателю я ничего не теряю. Вот. Так надо рости просто так тебе зп никто не добавит и я сейчас на коне, а тот разраб который не просил ни разу денег - он под конём. Выводы делайте сами.
Ps: совет когда hr спрашивает чем мы вас можем заинтересовать кроме денег- я всегда отвечаю честно : " Где нет денег - там и интереса нет... "
История выдуманная, все совпадения случайны. ;) или может не случайны?
Иммунитет от радиации)
Лав код это интимное))) скаем таки не показтель
soft-delete не является deprecated и каждый инструмент подходит под решение разных задач. Мы не испытываем проблем при работе с ним.
Наверное, мы друг друга не поняли, идентификатор сохранять не информативно для примера, конечно, я с вами согласен, ID более чем достаточно.
Да, полностью согласен с вами.
У нас записи удалённые остаются в бд чисто чтобы посмотреть что удалено и кто удалил (в рамках статьи). Поэтому нас часть проблем не касается.