он умеет в параллель спрашивать много store серверов и отдавать первый полный ответ. Если полного ответа нет, то он постарается восстановить как можно больше данных, используя метрики с других store серверов.

Заодно мы заменили graphite-web на store серверах

мы реализовали маленький сабсет возможностей graphite-web (только то что нужно для кластеризации)

И сделали его более быстрым.

Так как запросы и нужды росли, нам перестало хватать 80 RPS/store

(примерно столько было когда мы проивзели замену)

а с новой схемой, carbonserver <-> carbonzipper может обслуживать несколько тысяч запросов в секунду - то есть больше эта связка не узкое место

все это написано на Го

Распределение метрик

(картинка с одного из последних кластеров со старым хэшом)

Когда store серверов становится много, встает вопрос о том как этим управлять

И в большинстве случаев люди приходят к использованию какого-нибудь consistent hash'а

В carbon-relay есть свой, но нас он быстро перестал устраивать

Собственно возвращаясь на минутку - хэш нужен чтобы отправлять метрики только на какой-то определенный store

а свойство консистентности гарантирует то, что добивив новый сервер ты не получишь полного перераспределения метрик. Только часть со старых серверов смигрирует на новый.

Но как и у любого хэша, встает вопрос того насколько хороша сама функция

Та что в carbon-relay быстро перестала нас устраивать

Мы реализовали одну из более равномерных, но там тоже возникли те же проблемы

Собственно на картинке выше - разница между самым загруженным и свободным серверов составляет несколько тысяч метрик в секунду.

В худшем случаи разница может быть до 20%