Параллелизм и репликация данных

Параллелизм

Термин "параллелизм" означает возможность одновременного выполнения многих процессов с доступом к одним и тем же данным, причем в одно и то же время. Как известно, в такой системе для корректной обработки данных параллельными процессами без возникновения конфликтных ситуаций необходимо использовать некоторый метод управления параллелизмом.

Стандартный метод разрешения таких проблем - метод блокировки. Блокировка не является единственным возможным подходом в решении проблемы управления параллелизмом, но она, несомненно, чаще других встречается на практике. Однако с внедрением метода блокировки возникают другие проблемы, среди них наиболее известна проблема тупиковых ситуаций. Формальный критерий правильности выполнения некоторого набора параллельных транзакций описан в концепции способности к упорядочению.

Следует отметить, что параллелизм является весьма обширной темой, и поэтому в данном разделе будут описаны лишь некоторые важные идеи.

Транзакции

Транзакции - основной инструмент управления параллельными процессами в распределенных корпоративных приложениях. Слово "транзакция" часто приходит на ум в связи с коммерческими и банковскими операциями. Обращение к банкомату, ввод пароля и получение наличности - это транзакция.

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

ACID:свойства транзакций

Транзакции в программных системах часто описывают в терминах свойств, обозначаемых общей аббревиатурой ACID.

• Atomicity (атомарность). В контексте транзакции либо выполняются все действия, либо не выполняется ни одно из них. Частичное или избирательное выполнение недопустимо. Например, если клиент банка переводит сумму с одного счета на другой и в момент между завершением расходной операции и началом приходной операции сервер терпит крах, система должна вести себя так, будто расходной операции не было вовсе. Система должна либо осуществить обе операции, либо не выполнить ни одной. Фиксация ( commit ) результатов служит свидетельством успешного окончания транзакции; откат ( rollback ) приводит систему в состояние, в котором она пребывала до начала транзакции.
• Consistency (согласованность). Системные ресурсы должны пребывать в целостном и непротиворечивом состоянии как до начала транзакции, так и после ее окончания.
• Isolation (изолированность). Промежуточные результаты транзакции должны быть закрыты для доступа со стороны любой другой действующей транзакции до момента их фиксации. Иными словами, транзакция протекает так, будто в тот же период времени других параллельных транзакций не существует.
• Durability (устойчивость). Результат выполнения транзакции не должен быть утрачен ни при каких условиях.

Ресурсы транзакций

Наиболее часто термин "транзакция" произносится применительно к СУБД. Однако это более широкое понятие, которое используется во многих других областях. Существует множество других объектов, управляемых с помощью механизмов поддержки транзакций, например, очереди сообщений или заданий на печать, банкоматы и т.д. Таким образом, термин "ресурсы транзакций" служит для обозначения всего, что может быть затребовано параллельно протекающими процессами, определяемыми с помощью модели транзакций. Наиболее распространенным ресурсом транзакций являются базы данных. Поэтому для наглядности и краткости упоминаются именно они, хотя все сказанное применимо и к другим видам ресурсов.

Для обеспечения высокого уровня пропускной способности современные системы управления транзакциями проектируются в расчете на максимально короткие транзакции. Обычно из практики исключаются транзакции, которые охватывают действия по обработке нескольких запросов; если же подобной ситуации избежать не удается, решения реализуются на основе схемы длинных транзакций. Чаще, однако, границы транзакции совпадают с моментами начала и завершения обработки одного запроса. Подобная транзакция запроса - весьма удачная модель, и многие среды поддерживают простой и естественный синтаксис ее описания.

Системные транзакции и бизнес-транзакции

Те транзакции, о которых до сих пор говорилось и которые упоминаются в большинстве случаев, называют системными.Именно такие транзакции поддерживаются СУБД и специализированными системами управления. Транзакция базы данных - это группа SQL -команд, обрамленная инструкциями начала и завершения транзакции. Если, скажем, четвертая от начала транзакции команда приводит к нарушению некоторого ограничения целостности, система должна аннулировать результаты выполнения первых трех команд и уведомить процесс-инициатор о неудачном завершении транзакции. Если все четыре команды обработаны успешно, их результаты становятся достоянием других процессов одновременно, а не каждый в отдельности. Технологии управления системными транзакциями в достаточной мере стандартизированы и доступны для разработчиков прикладных программ.

Однако смысл системных транзакций остается скрытым для пользователей бизнес-приложений. Например, с точки зрения посетителя банковского Web -портала, транзакция состоит из процедуры регистрации, выбора счета, задания суммы, определения вида операции и щелчка на кнопке "ОК". Подобная последовательность действий называется бизнес-транзакцией и должна обладать теми же свойствами ACID, что и аналогичная системная транзакция. Если пользователь прерывает выполнение сценария до нажатия кнопки "ОК", любые изменения в состоянии системы подлежат безусловной отмене; если транзакция завершается успешно, все ее промежуточные результаты фиксируются на уровне системы только после нажатия кнопки "ОК".

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

Если разрабатываемая система не предполагает функционирования многих параллельных процессов, без длинных транзакций можно обойтись. Длинные транзакции, кстати, не всегда являются таким уж большим злом, с их помощью часто удается избежать многих проблем, хотя их использование, как правило, приводит к меньшей масштабируемости системы. Дело в том, что процесс преобразования длинных транзакций в короткие часто оказывается крайне сложным и неоднозначным.

Тем не менее, во многих распределенных приложениях длинные транзакции стараются не применять. В таких случаях приходится принимать на себя ответственность за поддержку свойств ACID бизнес-транзакции, т.е. решать проблему обеспечения параллелизма в автономном режиме. Любое взаимодействие бизнес-транзакции с таким ресурсом транзакции, как база данных, выполняется внутри системной транзакции (тем самым обеспечивается целостность этого ресурса). Для правильной реализации бизнес-транзакций простого последовательного вызова системных транзакций недостаточно - программное приложение должно обеспечить надлежащие средства их "склеивания".

Свойства атомарности и устойчивости бизнес-транзакций поддерживать значительно легче, чем другие свойства ACID. Действительно, достаточно реализовать фазу фиксации бизнес-транзакции с помощью системной транзакции. Прежде чем предпринимать попытку фиксации всех внесенных изменений в наборе записей, бизнес-транзакция должна активизировать системную транзакцию. Только системная транзакция поможет гарантировать, что результаты всех модификаций будут зафиксированы цельно и надежно. Единственной потенциально сложной задачей в этом случае является поддержка точного набора измененных данных в течение всего жизненного цикла бизнес-транзакции.

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

Наряду с очевидными проблемами противоречивости операций изменения существуют более тонкие, связанные с несогласованностью операций чтения. Когда информация считывается несколькими системными транзакциями, сложно гарантировать ее согласованность. Степень рассогласования считанных данных может оказаться настолько большой, что будет способна привести к сбою всей системы.

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

В настоящий момент большинство разработчиков промежуточного программного обеспечения ( middleware ) включают сервис транзакций в свои системы.