| ||||||||||||
| ||||||||||||
|
2010 г.
Дом на пескеПэт Хелланд, Дейв Кэмпбел
8. CAP и ACID2.0Как отмечалось выше, в теореме CAP [13, 14] утверждается, что из трех свойств – Consistency, Availability и Partition-tolerance (согласованность, доступность и терпимость к разделению) можно удовлетворить любые два, но не все три сразу. Мы с этим не спорим. Однако интересно то, что под "согласованностью" в этой теореме понимается согласованность в смысле классических ACID-транзакций (Atomic, Consistent, Isolated и Durable – атомарность, согласованность, изолированность и долговечность). Целью ACID-транзакций является создание для каждого приложения такой среды, в которой якобы имеется только один компьютер, и он не делает ничего другого при обработке данной транзакции. Рассмотрим новые свойства ACID (или ACID2.0). Эта аббревиатура раскрывается как Associative, Commutative, Idempotent и Distributed (ассоциативность, коммутативность, идемптентность и распределенность) [17]. ACID2.0-работа считается успешно выполненной, если каждая из ее частей выполнена
Заметим, что примеры 4 (корзина покупок) и 5 (обработка чеков) соответствуют этому стилю согласованности. 8.1 Отказоустойчивость при наличии ACIDДля поддержки сериализуемости классические алгоритмы делают в каждый момент времени что-то одно. Все известные нам и любимые нами алгоритмы управления параллелизмом всячески пытаются добиться видимости того, что в каждый момент времени происходит что-то одно. При анализе абстракции отказоустойчивости, описанной в разд. 2, мы видем, что во главе угла находятся синхронные контрольные точки и линейная история. Если корректность определяется в соответствии с классическими свойствами ACID, то важно обеспечить упорядоченность транзакций. И это, конечно, сериализуемость [3, 10, 12]. Интересно сопоставить пример 1 (Tandem образца 1984 г.) и пример 2 (Tandem образца 1986 г.). В примере 1 установка контрольных точек с резервной системой происходит на основе операций записи и чтения. Это корректно, но не обязательно обеспечивает высокую производительность. В примере 2 синхронизация состояния происходит при завершении транзакции. Внутритранзакционным параллелизмом управляют традиционные методы СУБД. Только после завершения транзакции требуется гарантировать, что выполненная работа переживет отказ. 8.2 Отказоустойчивость при наличии ACID2.0OK, посмотрим, что происходит с понятием отказоустойчивости когда вы НЕ стремитесь к сериализуемости (классические свойства ACID), а довольствуетесь новыми свойствами ACID – ассоциативностью, коммутативностью, идемпотентностью и распределенностью. Если вы разбиваете алгоритм выполнения требуемой работы на части, то каждая часть должна быть идемпотентной (точно так же, как в базовом подходе к отказоустойчивости). Кроме того, мы считаем, что работа распределена по сети, а не сконцентрирована в какой-либо централизованной системе. Единственным способом обеспечить эту возможность при сохранении классических ACID-гарантий является использование хорошо описанных пессимистических или оптимистических механизмов управления параллелизмом. Обычно они являются взаимозаменяемыми. Если приложение ограничивается дополнительными требованиями коммутативности и ассоциативности, мир становится ГОРАЗДО проще. Тогда не нужно больше согласовывать состояния основной и резервной систем в синхронном режиме. Можно очень пассивно относиться к совместно используемой информации. Это делает возможной автономную работу, использование медленных каналов связи, применение низкокачественных центров данных и т.д. Как это ни удивительно, мы обнаружили, что во многих случаях бизнес-практики эти ограничения удовлетворяются. Анализ традиционных способов выполнения бизнес-операций показывает наличие многих примеров, соответствующих этому подходу. В мире баз данных мы настолько "прикипели" к абстракциям чтения и записи, что забываем в поиске новых идей смотреть на то, что и как делают обычные люди. 9. Предстоящая работаПо-видимому, было бы очень полезно проанализировать разные приложения в бизнес-среде, чтобы обнаружить повторяющиеся схемы их организации. Что за операции используются в различных приложениях? Когда они являются коммутативными? Какие приемы делают их идемпотентными? Имеются ли решения, для которых требуется лишь синтаксическая переработка для применения в разных средах? Имеется ли таксономия паттернов, к которым могут приводиться различные решения? Наши предки были ОЧЕНЬ умны и для реализации своего бизнеса использовали слабо связанные системы. Они соединяли слабо связанные системы с использованием телеграмм, писем и почтовых систем. Для функционирования этих систем требовались переупорядочиваемые операции. Иногда одна и та же работа запрашивалась дважды, и в этих случаях требовались протоколы, поддерживающие идемпотентность. Как использовались эти схемы при прокладывании железных дорог и построении фордовских автомобилей серии Model-T? Не ждут ли эти паттерны своего использования в современных распределенных системах? 10. ЗаключениеМы рассмотрели кое-что из эволюции высокодоступных и отказоустойчивых систем. Как видно, все надежные системы строятся в виде некоторого набора ненадежных компонентов, которые соединяются таким образом, что система может продолжать полезно функционировать при отказах некоторых из этих ненадежных компонентов. С течением времени размер единицы сбоя становился все больше и больше. Многие годы технология построения отказоустойчивых систем обеспечивала их строгое транзакционное поведение за счет синхронной установки контрольных точек на границах отказов. По мере возрастания размеров единицы отказа задержки, вызываемые операцией установки контрольных точек, выросли настолько, что стали обременительными. В ответ на увеличивающийся размер задержки стали использовать асинхронную передачу состояния на границах отказов. Для этого потребовались новые модели и паттерны разработки приложений. Мы постарались описать паттерны, используемые во многих современных приложениях для борьбы с отказами в территориально распределенных системах. Для обеспечения успешного выполнения приложений поверх хаоса распределенного мира требуются возможности переупорядочивания и повторяемости работ. Разработчики приложений интуитивно тяготеют к миру согласованности "рано или поздно" (обычно без использования формализмов, которые могли бы помочь им добиться успеха). Наконец, мы проанализировали эти идеи, принимая во внимание теорию CAP, и показали, что в этом новом мире многие решения разрабатываются в расчете на некоторое ослабление классической согласованности для поддержки доступности и устойчивости к разделению. Это ослабленное понятие согласованности очень полезно и заслуживает больших академических исследований. 11. БлагодарностиМы хотим поблагодарить Декстера Барнеса (Dexter Barnes) и Свами Сивасубраманьяна (Swami Sivasubramanian) за их комментарии к этой статье. 12. Литература
|
 | |||||||||
| |||||||||
|
CITForum © 1997–2025