Как я масштабировал систему уведомлений трекера ошибок Хоук

[Maxim-MA]

Крутая работа, очень здорово описан подход, особенно понравилось, как через Redis и Lua аккуратно обошли race condition и сохранили горизонтальную масштабируемость, читалось как хороший разбор продакшен-кейса )

Думаю, стоит подумать о реализации скользящего окна с помощью Redis Sorted Set + ZREMRANGEBYSCORE Это может дать более точный контроль над событиями в интервале времени, особенно в сценариях, где счётчик «обнуляется» слишком резко

[e11sy]

У меня были мысли в эту сторону, но пока в приоритете минимальное потребление памяти и производительность под пиковую нагрузку. Но если требования к точности вырастут — Sorted Set с таймстемпами точно будет следующим шагом.

Спасибо за идею!

[AlexSpaizNet]

Может я что-то упускаю, но где здесь про масштабирование?

[e11sy]

Спасибо за вопрос!

Под этим я имел в виду, что система может быть масштабирована горизонтально, без потери данных и дублирования уведомлений. Раньше вся логика обработки событий была завязана на один процесс, а теперь она распределена и использует общее хранилище. Это позволяет нескольким воркерам работать одновременно и эффективно справляться с большим количеством событий.

• Распределение событий по воркерам происходит с помощью RabbitMQ

• Вся агрегация вынесена в общее хранилище (Redis), доступное для всех воркеров.

• Используются Lua-скрипты для атомарной работы с данными и устранения гонок.

• Поддерживается независимая работа нескольких воркеров без риска дублирования уведомлений.

Теперь система может обрабатывать миллионы событий в час и не упирается в ограничения одного инстанса воркера — это и есть масштабирование в контексте highload-сервиса.