Сеть, кластер и виртуальные разделы

Я пытаюсь разработать распределенное приложение JBoss, и сегодня днем ​​я услышал, как некоторые коллеги говорили о теореме CAP и, в частности, о ее части "P" (разделение). Они говорили о том, как это применимо к различным типам разделов, а именно к разделам кластера, сетевым разделам и виртуальным разделам.

Мое понимание сетевого раздела заключается в том, что это преднамеренный дизайн для фрагментации сети на 2+ изолированные части, чтобы она могла справиться с отключением одного или нескольких отдельных фрагментов. Как разделы кластера вписываются в эту модель (и, таким образом, связаны с CAP) и что такое «виртуальный» раздел?!?

Мне интересно, нужно ли мне принимать во внимание что-либо из этого при кластеризации моего приложения JBoss, и если да, то с чего начать с таких соображений. Заранее спасибо!


java cluster-computing partitioning distributed-computing jboss
person IAmYourFaja    schedule 08.03.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Согласно CAP теореме, вы не можете достичь всех трех параметров: Cпостоянства, Aдоступности и Pдопускаемости артикуляции одновременно.

Моя интерпретация заключается в том, что это не означает, что ваше приложение обязательно потеряет A навсегда, если вы выберете C+P. Приложение может иметь любую пару CAP в разные моменты времени. И вы должны решить, какую пару CAP вы хотите иметь чаще всего.

В контексте кластера JBoss вы можете настроить изолированный резервный вторичный раздел, чтобы подкачивать его вместо основного раздела во время работ по обновлению/обслуживанию. Таким образом, у вас в основном будет C+A без P, потому что вы не используете оба раздела в основное время. Теперь вы решили, что пришло время обновить ваше приложение. Какие у вас есть варианты? Вы можете временно изменить C или A на P. То есть можно поменять местами разделы (потерять C) или вывести из строя весь кластер (потерять A).

Конечно, вы можете выбрать другие комбинации CAP для основного времени. Это зависит от того, какой SLA подходит для вашего приложения. Более популярны C+A и A+P.

person Tair    schedule 09.03.2013

arrow_upward
0
arrow_downward

Допуск разбиения в теореме CAP является теоретической концепцией, а не конкретной. Это относится к способности всей системы обрабатывать сбои связи. Это не относится к какому-либо преднамеренному разделению узлов.

сама теорема CAP говорит с точки зрения веб-сервиса:

В сети, подверженной сбоям связи, ни одна веб-служба не может реализовать атомарную общую память для чтения/записи, которая гарантирует ответ на каждый запрос.

Обратите внимание, что для веб-сервисов, поддерживаемых базой данных, вам не нужно беспокоиться о теореме CAP, поскольку вы не пытаетесь реализовать какую-либо общую память; база данных делает это за вас. Если вы поддерживаете любое активное состояние в своем приложении, вам действительно нужно беспокоиться о теореме CAP, потому что это состояние представляет некоторую память для чтения/записи, которую вы хотите поддерживать атомарно (cпоследовательно), надежно (aдоступно) и в условиях сетевых сбоев между узлами (partition терпимо).

Если вы поддерживаете базу данных на более чем одном узле, сама база данных должна иметь дело с теоремой CAP. Любое развернутое решение высокой доступности идет на различные компромиссы, чтобы справляться со сбоями связи. Например, реплика MongoDB устанавливает компромисс доступности, заставляя любой узел, не подключенный к большинству узлов, отказаться от своего основного статуса. Убедитесь, что вы понимаете, что делает ваша база данных в неблагоприятных условиях, и убедитесь, что они соответствуют требованиям вашего приложения.

person kjw0188    schedule 11.03.2013