Честно говоря, я бы переосмыслил ваш подход и скажу почему.
Я проделал большую работу по распределенным системам большого объема (в частности, по финансовым транзакциям) и вашему решению - если объем достаточно высок (и я предполагаю, что это так, или вы не будете рассматривать кластерный решение: вы можете получить огромное количество энергии из одной готовой коробки в эти дни) - тогда вы убьете себя удаленными вызовами (то есть вызовами данных из другого узла).
Я буду говорить о когерентности Tangosol / Oracle здесь, потому что это то, с чем у меня больше всего опыта, хотя Terracotta будет поддерживать некоторые или большинство из этих функций и является бесплатной.
В терминах когерентности у вас есть секционированный кеш, где, если у вас есть n узлов, каждый узел обладает 1 / n от общих данных. Обычно у вас есть резервирование по крайней мере одного уровня, и эта избыточность распределяется настолько равномерно, насколько это возможно, поэтому каждый из других n-1 узлов обладает 1 / n-1 резервных узлов.
Идея такого решения состоит в том, чтобы попытаться убедиться, что как можно больше попаданий в кэш являются локальными (для одного и того же узла кластера). Также, в частности, с многораздельными кэшами, записи относительно дороги (и становятся дороже с большим количеством резервных узлов для каждой записи в кэше) - хотя кэширование с обратной записью может минимизировать это - и чтение довольно дешево (что вам хочу из ваших требований).
Таким образом, ваше решение гарантирует, что каждый кэш будет попадать на удаленный узел.
Также учтите, что создание контента, несомненно, намного дороже, чем его обслуживание, и я предполагаю, что именно поэтому вы пришли к этой идее, потому что тогда у вас может быть больше генераторов контента, чем серверов. Это более многоуровневый подход, который я бы охарактеризовал как горизонтальное нарезание.
Вы достигнете гораздо лучшей масштабируемости, если сможете вертикально нарезать свое приложение. Под этим я подразумеваю, что каждый узел отвечает за хранение, генерацию и обслуживание подмножества всего контента. Это эффективно устраняет связь между междоузлиями (исключая резервные копии) и позволяет настроить решение, просто предоставив каждому узлу подмножество контента различного размера.
В идеале, любая схема, которую вы выбираете для разделения ваших данных, должна воспроизводиться вашим веб-сервером, чтобы он точно знал, какой узел использовать для соответствующих данных.
Теперь у вас могут быть другие причины сделать это так, как вы предлагаете, но я могу ответить на него только в контексте доступной информации.
Я также укажу вам сводку технологий грид / кластеров для Java , которую я написал в ответ на другой вопрос.