Хотя я-бы оставил один до конкретного аггрегатора.

так аггрегатор тоже многопоточный. те.. примерно 80 воркеров на одной машине, и каждый имеет по одному коннекту ко всем шардам

Зачем? ))

так каждый поток имеет разный контекст

И забудьте слово "многопоточный", это не про Перл. А если вы имеете в виду многопроцессный, то это просто отдельные инстансы

кто жто? :)

многопроцессный, 80 процессов, каждый имеет свой контекст и соединения к шардам

CBOR::XS - это RFC 7049, http://cbor.io

CBOR::XS имеет поддержку сериализации объектов - просто определяешь методы

опять же CBOR умеет без схемы

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

Я-бы просто сказал что есть 80 инстансов, но ладно. Теперь следите за руками...

Я утверждаю, что если мы рассмотрим 1 аггрегатор и 1 набор шардов, как одну логическую единицу, то в этой единице простои будут минимальны.

Почему я так думаю: Шарды, по количеству данных, имеют одинаковые размеры и, следовательно, время просмотра будет примерно одинаково. Аггрегатор не сможет работать быстрее, чем самый медленный шард и скоростью работы аггрегатора можно пренебречь.

это средство дистрибуции заданий с хорошим горизонтальным масштабированием

задолбаешься, посмотри на питон-реализации CBOR, поддерживающие теги 26 или 27, это как раз про объекты (а без тегов CBOR эквивалентен JSON, только бинарный)

тут всё понятно

записал, почитаю

спасибо

можно добавлять не только процессы, но и новые сервера

Ну тогда у вас на шарде один коннект, через который вы слушаете запросы, нету проблемы случайной перегрузки шарда (когда на один шард пришли 100 аггрегаторов) и время ответа примерно одинаково и предскажуемо.

Ну а как раскидать нагрузку на аггрегаторы - это уже другой вопрос... nginx с реверс прокси. допустим как вариант.