Опубликован: 10.10.2010 | Доступ: свободный | Студентов: 3054 / 200 | Оценка: 4.14 / 3.32 | Длительность: 13:16:00
ISBN: 978-5-9963-0444-8
Специальности: Системный архитектор
Дополнительный материал 1:

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

< Лекция 13 || Дополнительный материал 1: 1234 || Дополнительный материал 2 >
Аннотация: В лекции дается краткое введение в проблематику параллельной обработки данных
Ключевые слова: параллелизм, метод управления, блокировка, тупиковая ситуация, управление параллельными процессами, слово, транзакция, ACID, СУБД, очереди сообщений, печать, базы данных, ПО, синтаксис, транзакция базы данных, группа, команда, ограничение целостности, операции, пользователь, база данных, целостность, приложение, поддержка, цикла, очередь, информация, промежуточное программное обеспечение, middleware, значение, вероятность, откат, грязное чтение, объект, доступ, снятие блокировки, монопольная блокировка, exclusive lock, управление блокировками, запрос, матрица, ресурс, граф, захват, выход, поиск, программирование приложений, параллельная обработка данных, множества, уровень изоляции, свойство транзакции, DB2, компромисс, таблица, dirty read, READ COMMITTED, serializability, транзакционная обработка, атомарность, память, фиксация транзакции, диск, журналирование, вложенная транзакция, дерево, оплата, репликация, массив, метка, менеджер, передача данных, отступ, офис, распределение прав

Параллелизм

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

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

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

Транзакции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< Лекция 13 || Дополнительный материал 1: 1234 || Дополнительный материал 2 >
Алмаз Мурзабеков
Алмаз Мурзабеков
Прохожу курс "Построение распределенных систем на Java" в третьей лекции где описывается TCPServer вылетает эта ошибка
"Connection cannot be resolved to a type"


Java version 1.7.0_05