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

Question

У меня есть кластер веб-приложений (Java + Tomcat), а приложения генерируют события. Объем не такой высокий, но где-то менее 10 миллионов событий в день (неравномерно распределенных с пиками и долинами).

Нам нужно отобразить вычисленные агрегаты событий в пользовательском интерфейсе. В настоящее время это делается путем запуска запросов БД к большой таблице со многими индексами на каждом дисплее страницы.

Есть ли хороший архитектурный подход к поддержанию потока событий, а также расчет (на лету) и сохранение совокупных чисел, таких как Average, Mean, Min, Max и т. Д.?

Реальное время не имеет значения, но почти реальное время является обязательным. Например, допустима латентность менее 1 минуты.

Answer 1

Вы можете пойти с моделью толкания или тянущей моделью. (Или проактивно/реактивно, если вам нравятся эти условия.) В обоих случаях у вас есть централизованный хранитель записей, который должен собирать нужные вам данные. В push-модели ваши децентрализованные службы/серверы/приложения будут периодически подталкивать обновления к вашему хранителю записей. В модели тяги ваш хранитель записей будет периодически запрашивать ваши децентрализованные службы и запрашивать обновления.

В сценарии push каждый независимый сервис/сервер/приложение хранит журнал своего собственного счетчика событий. После того, как счетчик событий отметит определенный порог, он уведомит хранителя записей о новом статусе. Например, они могут обновлять каждые 100 или 1000 или дельта-события. Таким образом, (при условии отсутствия неопределяемых сбоев) хранитель записей всегда знает, сколько событий произошло в системе плюс или минус ваша дельта. Это дает большую производительность, поскольку всякий раз, когда кто-то хочет получить доступ к записям событий, все данные уже агрегированы. Одна из недостатков заключается в том, что на систему накладываются низкие, но постоянные накладные расходы. Другим является то, что вы никогда не знаете, была ли служба неудачной или недавно у нее не было много событий (плюс/минус дельта).

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

Теперь оба этих подхода не зависят от методологии реализации. Любой из этих подходов может быть реализован с полностью плоской топологией, где каждая служба напрямую связывается с вашим хранителем записей. В качестве альтернативы вы можете сформировать иерархию сервисов, чтобы каждый родитель в иерархии отвечал за агрегирование данных своих детей. То, что вы хотите сделать в этом отношении, действительно зависит от того, насколько быстро эффективна система.