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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

CAP theorem itself says, from a web service perspective:

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

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

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