home.social

#очереди — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #очереди, aggregated by home.social.

fetched live
  1. Доставка вебхуков: повторы, дубли и ещё три источника проблем

    Получатель записал заказ в базу, но соединение оборвалось до того, как отправитель получил ответ. Повторить вебхук — рискнуть вторым заказом, не повторить — потерять событие. Разбираем пять задач доставки: расписание повторов, дубли, подпись, изоляцию недоступных получателей и защиту от запросов во внутреннюю сеть.

    habr.com/ru/articles/1091396/

    #вебхуки #webhooks #идемпотентность #retry #exponential_backoff #hmac #ssrf #circuit_breaker #очереди #php

  2. chunk() пропустил половину рассылки

    Раз в минуту четыре фоновые команды обходят таблицу на сотни тысяч чатов и решают, кому бот напишет первым: у кого обновились суточные лимиты, кто начал разговор и замолчал, у кого кончилась подписка. Год назад выяснилось, что за один проход каждая обслуживает ровно половину тех, кого сама же выбрала. Ошибок при этом нет, лог чистый, метрика отправленных растёт. Виноват chunk(), который листает выборку через OFFSET: обработанная строка из этой выборки выпадает, и окно уезжает. Разбор на живом проекте с 300 тысячами пользователей в месяц: как chunk() теряет строки и чем его заменить, почему withoutOverlapping() по умолчанию блокирует команду на сутки, откуда берутся дубли рассылки и зачем пришлось переворачивать порядок колонок в составном индексе.

    habr.com/ru/articles/1084640/

    #php #laravel #крон #очереди #высокая_нагрузка #telegram_bot #рассылки

  3. 429 — это не про скорость. Это про бюджет, которого ты не видишь

    Рейт-лимит — это не ограничение скорости. Это бюджет, и тратишь его не ты один. Разбор на Telegram Bot API, Redis и одном наивном планировщике 2023 года.

    habr.com/ru/articles/1083632/

    #rate_limit #429 #Telegram_Bot_API #Redis #token_bucket #очереди #идемпотентность

  4. Сотни Telegram‑ботов в одном процессе Node.js: общий webhook, очередь в PostgreSQL и Mini App на 5 КБ

    Каждому пользователю моего конструктора нужен свой Telegram‑бот. Рассказываю, как держать сотни ботов в одном процессе Node.js: общий webhook, очередь в PostgreSQL на SKIP LOCKED и Mini App на 5 КБ. С замерами нагрузки и честным разбором, где у схемы потолок.

    habr.com/ru/articles/1087660/

    #бот #телеграм #миниприложение #webhook #postgresql #nodejs #очереди #telegram_bot_api

  5. Очереди, которых нет в конфиге: динамические супервизоры Laravel Horizon

    Очереди задач — одна из тех вещей, которые настраивают один раз и больше не трогают. Конфиг описывает известные потоки фоновых работ, деплой раскатывает его, воркеры поднимаются и делают своё дело. Так работает в подавляющем большинстве проектов. А что если появляется необходимость запускать максимально изолированные задачи, которыми должен управлять пользователь, а не разработчик: создавать, запускать, останавливать? Это единица, которую надо изолировать, появляется и исчезает между деплоями, а единственный способ рассказать об этом системе — отредактировать конфиг и раскатать всё заново. В Laravel Horizon документация заканчивается на конфиге и паре artisan-команд про то, как поднять супервизоры, настроить воркеры, их масштабирование и указать очереди. А что, если нам нужно создать свои собственные очереди и их воркеры в рантайме? Об этом документация молчит. Но если прочитать исходники, выясняется, что конфиг — не единственный источник истины. Это статья про построение динамических очередей поверх статического конфига Laravel Horizon, используя внутренние недокументированные механизмы, которые Horizon сам использует внутри себя. Про архитектуру с автоматическим восстановлением консенсуса, разрешением ошибок и оптимизацией памяти для долго живущих очередей.

    habr.com/ru/articles/1085278/

    #laravel #horizon #queues #очереди #очереди_в_laravel

  6. [Перевод] Структуры данных на практике. Глава 18: Очереди драйверов устройств

    Наш сетевой драйвер терял пакеты. Не время от времени, а постоянно. На пропускной способности линии с 64-байтными пакетами мы теряли 31% всего трафика. В качестве оборудования использовался Ethernet-контроллер на 1 Гбит/с на SoC RISC-V. В спецификациях говорилось, что он может справляться со скоростью проводного трафика. Движок DMA работал корректно. Обработчик прерываний срабатывал вовремя. Тем не менее, пакеты исчезали. Я начал с очевидного подозреваемого: очереди получения. Реализация выглядела вполне логично — простой связанный список с указателями на голову и хвост. Под нагрузкой (64-байтные пакеты на пропускной способности линии) драйвер терял 31% пакетов! При профилировании обнаружилась причина проблемы: производительность убивали связанный список и спин-блокировки. Я переписал драйвер, использовав кольцевой буфер без блокировок. Результаты: потеря 31% пакетов превратилась в 0,12% — улучшение в 258 раз! В этой главе мы поговорим о структуре очередей для драйверов устройств.

    habr.com/ru/articles/1051508/

    #очереди #связанные_списки #драйверы

  7. Создаем потокобезопасную очередь с условными переменными: «академический» пример против реальности

    Представьте, что вы едете в ночном поезде. Чтобы гарантированно выйти на нужной станции, придется не спать всю ночь и внимательно отслеживать остановки. Свою станцию вы не пропустите, но сойдете с поезда уставшим. Другой способ: узнать из расписания предполагаемое время прибытия поезда, поставить будильник на нужное время с небольшим запасом и лечь спать. Этого вполне достаточно, чтобы не пропустить свою станцию, но, если поезд задержится, пробуждение окажется слишком ранним. Идеальным решением было бы лечь спать, положившись на то, что кто-нибудь или что-нибудь разбудит вас незадолго до реального прибытия поезда на нужную станцию... Какое отношение этот пример имеет к работе с потоками в программировании? Дело в том, что решить задачу синхронизации конкурентных операций можно также несколькими способами, близкими к ситуации выше. Меня зовут Александр, я разработчик на С++ в YADRO, и в этой статье я разберу несколько вариантов эффективной организации ожидания потоков.

    habr.com/ru/companies/yadro/ar

    #с++ #очереди #мьютексы #consumer #задача #многопоточность #producer

  8. Что под капотом у ИИ-агента для отдела продаж: архитектура, код и грабли

    «ИИ-агент для продаж» на демо выглядит как одна кнопка: подключил, и он сам слушает звонок и ставит задачу в CRM. В проде между этими двумя точками десяток слоёв, и в каждом всё тихо ломается. Разбираем пайплайн целиком: распознавание и диаризация на телефонном звуке 8 кГц, извлечение фактов с проверкой каждого вывода против расшифровки, запись в CRM без дублей и потерь, действия наружу через MCP вместо хрупкого браузера, контроль качества на сотне размеченных звонков. Везде код, реальные цифры и грабли из боевого режима.

    habr.com/ru/articles/1050336/

    #ииагенты #llm #asr #диаризация #whisper #amocrm #очереди #followup

  9. Что под капотом у ИИ-агента для отдела продаж: архитектура, код и грабли «ИИ-агент для продаж» на демо выгляд...

    #ии-агенты #llm #asr #диаризация #whisper #amocrm #очереди #follow-up

    Origin | Interest | Match
  10. Публикация событий из Laravel в Centrifugo: Events, listeners, queue jobs и безопасный real-time payload

    В этой статье разберём, как правильно организовать публикацию real-time событий в Laravel: почему не стоит отправлять сообщения напрямую из контроллеров, как использовать Laravel Events и listeners, зачем нужны queue jobs, почему afterCommit() критичен для корректности данных и каким должен быть безопасный payload без полной Eloquent-модели.

    habr.com/ru/articles/1036322/

    #laravel #centrifugo #архитектура #очереди

  11. Celery Autoscale: что в лоб — то по лбу?

    Celery популярен. Модель prefork работает по умолчанию. Autoscale смотрится неплохим вариантом для любого воркера. Идея посмотреть, как выглядит механизм изнутри родилась давно, когда по работе сталкивался с проблемами у клиентов в отложенных задачах, но никаких артефактов или задокументированного аномального поведения не было. Это стартовая статья об архитектуре, моделях и масштабировании Celery.

    habr.com/ru/articles/1030838/

    #celery #очереди

  12. Странное тестовое задание или как упустить работу мечты Из названия не понятно буду ли я писать про странно...

    #очереди #оптимизация #запросов #sql #postgresql

    Origin | Interest | Match
  13. Очереди на PostgreSQL: антипаттерн или реальность жизни

    Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них. В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа. Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности. Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.

    habr.com/ru/companies/yandex/a

    #postgresql #sql #очереди #высоконагруженные_системы

  14. Очереди на PostgreSQL: антипаттерн или реальность жизни Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑к...

    #postgresql #sql #очереди #высоконагруженные #системы

    Origin | Interest | Match
  15. Очереди на PostgreSQL: антипаттерн или реальность жизни Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑к...

    #postgresql #sql #очереди #высоконагруженные #системы

    Origin | Interest | Match
  16. Когда ошибка становится наставником: почему баги прошлого нередко полезнее любого чек-листа

    Каждый разработчик хотя бы раз в жизни сталкивался с ситуацией, когда баг, который вроде бы уже исправлен, неожиданно возвращался в продакшен. В этой статье я расскажу о тех случаях, когда ошибки служили для меня не провалом, а очень настойчивым, но полезным учителем. Да, иногда именно они объясняют архитектуру, принцип работы систем или забытый corner case лучше самых толстых документаций. Эта статья не учит идеализму — наоборот, она про то, как ценить несовершенство.

    habr.com/ru/articles/972944/

    #ошибка #баг #отладка #архитектура #опыт_разработчика #race_condition #обработка_данных #очереди #продакшен #надежность

  17. Long Polling и Webhooks. Обработка событий в Telegram-ботах Есть два способа, которые позволяют вашему боту получать обно...

    #webhooks #long #polling #bot #telegram #telegram #bot #telegram-боты #обработка #событий #очереди

    Origin | Interest | Match
  18. [Перевод] Как я спустя 15 лет решил проблему распределённых очередей Когда я работал Reddit и отвечал там за инф...

    #rabbitmq #redis #reddit #очереди #задач

    Origin | Interest | Match
  19. Развивать или выпиливать легаси: где грань?

    Дисклеймер: сказанное ниже относится к ситуации, когда в компании нет отдела (или хотя бы архитектора), который занимается созданием и развитием внутренних технологий и продукты компании тоже не являются инфраструктурными технологиями. Я много лет занимался тех. консалтингом и работал архитектором в компаниях с кучей внутренних команд со своими проектами и один из самых частых вопросов:

    habr.com/ru/articles/943396/

    #infrastructure #очереди #базы_данных #golang #highload

  20. Развивать или выпиливать легаси: где грань? Дисклеймер: сказанное ниже относится к ситуации, когда в компан...

    #infrastructure #очереди #базы #данных #golang #highload

    Origin | Interest | Match
  21. Kafka, RabbitMQ, NATS в 2025

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

    habr.com/ru/articles/923046/

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

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

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

    habr.com/ru/articles/896266/

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

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

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

    habr.com/ru/articles/871454/

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

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

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

    habr.com/ru/companies/ruvds/ar

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

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

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

    habr.com/ru/companies/beget/ar

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

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

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

    habr.com/ru/companies/vk/artic

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

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

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

    habr.com/ru/articles/792220/

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

Share on Mastodon

Enter the server where you have an account.