Kafka, RabbitMQ, NATS в 2025

Всем привет, Команда devhands.io сделала с Владимиром Перепелицей интервью, посвященное сравнению наиболее популярных решений в области очередей и брокеров сообщений — Kafka, RabbitMQ, NATS. Владимир — эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload. А мы, R&D-центр devhands.io , разрабатываем образовательные программы по хайлоаду, перформансу, архитектуре, базам данных и другим направлениям . Наш канал - https://t.me/rybakalexey . Под катом – расшифровка интервью.

https://habr.com/ru/articles/923046/

#брокер_сообщений #очередь_сообщений #очереди #kafka #rabbitmq #nats

[Перевод] Библиотека для кэширования Caffeine: анализ кода

То и дело, прожигая время за чтением reddit, я натыкаюсь на очередной пост, в котором упоминается метод S3 FIFO и упоминается, что он лучше LRU (вытеснение реже всего используемых значений) — потому, что даёт более низкий процент промахов кэша. Видные компании, в частности, RedPandas, Rising Wave и Cloudflare уже внедрили S3 FIFO у себя на различных мощностях, что только подогрело мой интерес к нему. Кэши — чертовски интересная тема, а по работе мне приходится сильно полагаться на работу с кэшами при обслуживании нескольких сервисов. Так что я был уверен, что рано или поздно мне потребуется протестировать S3 FIFO или, как минимум, удостовериться, что я понимаю ключевые идеи, заложенные в этой технологии. Правда, казалось, что рановато с головой погружаться в изучение нового подхода к кэшированию, пока ещё досконально не разобрался в аналогичной системе, с которой приходится иметь дело на работе сейчас. У нас в команде для работы с кэшированием используется библиотека Caffeine , и, положа руку на сердце, я не ориентировался в её внутреннем устройстве, не пытался проверить, можно ли в ней что-нибудь подкрутить, и есть ли в ней параметры, поддающиеся тонкой настройке. В этой статье я попробую законспектировать мои изыскания и рассказать, как на собственном опыте разбирался во внутреннем устройстве библиотеки Caffeine. Все желающие приглашаются в путешествие с разбором сложностей одной из наиболее востребованных систем кэширования, используемых в мире. Будь вы бывалый инженер или просто новичок, интересующийся продвинутыми механизмами кэширования, это исследование прольёт вам свет на многие вопросы и подведёт к важным практическим выводом. Поехали!

https://habr.com/ru/articles/896266/

#кэширование #очереди #алгоритмы #программирование

Тонкости JMS API: как не терять сообщения

Типичная ситуация: один сервис добавил сообщение в очередь, другой сервис его прочитал, но из-за ошибки или рестарта сервиса не смог передать дальше. Сообщение потеряно. В логах при этом не всегда есть что-то полезное, и часто всё заканчивается тем, что разработчики идут ругаться: «Почему в нашей очереди нет вашего сообщения?»

https://habr.com/ru/articles/871454/

#spring #jms #очереди

[Перевод] Как устроены очереди: визуальное объяснение

Очереди используются везде. Когда вы загружаете эту веб-страницу, запрос для её получения взаимодействует с десятками различных очередей на пути от вашей машины к серверу, на котором хостится страница. Очереди — это фундаментальный элемент. В этом посте мы изучим очереди в контексте HTTP-запросов. Начнём мы с простого, и постепенно будем вводить более сложные структуры очередей.

https://habr.com/ru/companies/ruvds/articles/863654/

#очереди #очередь_с_приоритетами #lifo #fifo #queues #ruvds_переводы

[Перевод] Планируем потоки как Томас Джефферсон

Эта статья посвящена тому, как распределять задачи между конвейерами очередей, чтобы минимизировать общее время обработки, а также неожиданной связи между этим методом планирования и методом Томаса Джефферсона.

https://habr.com/ru/companies/beget/articles/847208/

#haskell #очереди #параллельное_выполнение_задач #плапнировщик

Как создавать высокопроизводительные очереди сообщений с различной архитектурой

Масштабирование ИТ-инфраструктуры и переход к высоконагруженным многокомпонентным сервисам дает бизнесу не только преимущества, но и сложности. Одна из основных — необходимость обеспечения для сервисов возможности отказоустойчиво и надежно обмениваться тысячами сообщений без риска их потери или повреждения. И в этих задачах часто не обойтись без реализации очередей сообщений. Рассказываем об основных сложностях развития высоконагруженных ИТ-систем и способах их преодоления с помощью очередей сообщений на примере Tarantool Queue Enterprise . Материал подготовлен по мотивам вебинара «Как создавать высокопроизводительные очереди сообщений с различной архитектурой». Вы можете посмотреть его здесь .

https://habr.com/ru/companies/vk/articles/837060/

#tarantool #kafka #rabbit #очереди

Стеки и Очереди в Swift

В этой статье мы исследуем две фундаментальные структуры данных, которые являются неотъемлемой частью программирования на Swift: стеки и очереди. Они представляют собой коллекции элементов с особыми правилами для добавления и удаления элементов. Стеки работают по принципу "последним пришел, первым ушел" (LIFO), что делает их идеальными для задач, связанных с обратной навигацией или отменой действий. Очереди, следуя принципу "первым пришел, первым ушел" (FIFO), идеально подходят для задач, требующих обработки элементов в порядке их поступления, например, в управлении задачами или потоками данных.

https://habr.com/ru/articles/792220/

#stack #queue #swift #очереди #стек #стеки #очередь #структуры_данных #алгоритмы