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