redis — много независимых серверов на запись -> 1 агрегирующий
есть несколько боевых серверов,
на каждом пишется в редис некоторая статистика,
для каждого сервера статистика своя
есть агрегирующий сервер, где нужно статистику собирать, группировать и обсчитывать,
и желательно в реальном времени
пока вижу варианты:
1 собирать статистику с каждого редиса на боевых серверах по таймауту отдельным скриптом, на php или python и класть в агрегирующий редис
но тут возникает много сложностей с обеспечением атомарности операций
2 сделать на каждый боевой редис по слейву на агрегирующем сервере и уже на сервере по таймауту синхронизировать слейвы и группировать данные в результирующую базу
но тут возникает сложность в большой лишней работе
3 класть на боевых серверах статистику в очередь в редисе и забирать удаленным скриптом на php в реальном времени без группировки на редисе, редис использовать только как менеджер сообщений
но тут возникает сложность в больших объемах сырой необработанной статистики, передаваемой по сети
Не вариант сразу отправлять статистику при получении новой её «порции»? Без внешних планировщиков. Т.е. писать сразу в агрегирующий редис, что находится в локальной сети, минуя память боевых серверов. Не очень понятна их роль в сборе статистики. Если агрегирующий не справится с задачей (памяти мало, скажем), можно использовать distributed redis подключение (например, реализовано в клиенте для руби, redis-rb), т.е. сервер, где лежат данные по ключу, будет определяться контрольной суммой ключа и таким образом будет достигаться необходимая производительность. «Агрегатор» сможет подключиться и получить верные данные без проблемы синхронизации.
Простой
Простой
Средний
