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

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

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

  • Вычет стоимости предметов из баланса аккаунта пользователя.
  • Обновление уровней запасов продуктов.
  • Отправка письма с подтверждением пользователю.

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

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

Вот некоторые из проблем параллелизма:

Потерянные обновления. Предположим, что на вашем банковском счете есть 100 долларов США, и два человека одновременно пытаются снять 50 долларов США. Если оба обновления произойдут одновременно, есть риск, что баланс будет равен 50 долларам вместо 0 долларов.

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

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

Контексты выполнения — это различные ситуации или среды, в которых происходит обработка.

  • Запросы
  • Сессии
  • Процессы
  • Потоки
  • Транзакции

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

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

Процесс — это надежная среда с собственным пространством для хранения данных.

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

Транзакция – это группа запросов, которые клиент хочет рассматривать как один. Это может быть системная транзакция или бизнес-транзакция в приложении.

При решении проблем параллелизма в игру вступают два решения: изоляция и неизменяемость.

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

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

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

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

Система контроля версий, такая как Subversion (SVN), может быть примером приложения, использующего пессимистическую блокировку. После того как пользователь извлечет файл, никто другой не сможет его редактировать, пока пользователь не вернет его обратно.

Оптимистическая блокировка:

  • Плюсы: не нужно ждать снятия блокировки, позволяет одновременное редактирование, уменьшает взаимоблокировки.
  • Минусы: Не подходит при высокой вероятности конфликтов или при работе с большими файлами

Пессимистичная блокировка:

  • Плюсы: предотвращает одновременное редактирование и конфликты, обеспечивает эксклюзивный доступ
  • Минусы: не подходит, когда многим пользователям нужно редактировать одни и те же файлы или когда пользователям нужно не забывать снимать блокировки.

Еще один способ предотвратить несогласованное чтение — использовать временное чтение, которое показывает состояние кода в определенный момент времени. Однако это может быть сложно реализовать и может оказаться непрактичным для больших баз данных.

Взаимоблокировки

Допустим, Джон работает с файлом «Клиент», а Лиза — с файлом «Заказ». Лиза понимает, что ей также нужно работать с файлом клиента, чтобы завершить его задачу, но Джон уже заблокировал его. Так что Лизе приходится ждать, пока Джон закончит редактирование. Тем временем Джон понимает, что ему нужно отредактировать файл Заказа, который Лиза заблокировала. Это создает взаимоблокировку, поскольку ни один из них не может продолжать работу, пока другой не освободит необходимый ресурс.

Методы устранения взаимоблокировок:

  • Обнаружение взаимоблокировок. Программное обеспечение обнаруживает взаимоблокировки, выбирает жертву и отбрасывает их работу и блокировки, чтобы продолжить работу.
  • Тайм-ауты: установка ограничений по времени для блокировок; в случае превышения владелец становится жертвой.
  • Предотвращение взаимоблокировок: гарантия того, что все необходимые блокировки будут получены заранее, а дополнительные приобретения будут предотвращены позже, чтобы предотвратить возникновение взаимоблокировок.
  • Порядок блокировок. Введите порядок получения блокировок (например, в алфавитном порядке).
  • Консервативные подходы. Комбинируйте профилактические меры, такие как предварительное получение блокировок и использование тайм-аутов.

Углубленное изучение транзакций

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

Транзакции с программным обеспечением с точки зрения свойств ACID:

  • Атомарность. Это правило «все или ничего». либо все они выполнены, либо ни один из них.
  • Последовательность. Это правило гарантирует, что данные остаются чистыми и правильными до и после транзакции.
  • Изоляция означает, что каждая транзакция выполняется в пузыре, отдельно от всех остальных. Только после успешного завершения результаты становятся доступными для других транзакций.
  • Надежность. Наконец, это гарантирует, что он будет заблокирован после завершения транзакции.

Уменьшение изоляции транзакций для повышения эффективности

Транзакционные системы часто полагаются на стандарт SQL, который определяет четыре уровня изоляции:

  • Сериализуемый: дает тот же результат, но всегда получает данные до или после обновления.
  • Повторяемое чтение: иногда при добавлении элементов в коллекцию читателю могут быть видны только определенные элементы.
  • Read Committed: позволяет транзакции читать только те данные, которые зафиксированы другими транзакциями.
  • Чтение незафиксированных: Разрешены грязные чтения, что означает, что транзакция может считывать данные, которые другие транзакции изменили, но еще не зафиксировали.

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

Деловые и системные транзакции

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

  1. добавление книги в корзину;
  2. проверка;
  3. проверка наличия книги;
  4. ввод и проверка платежных реквизитов;
  5. обработка платежей;
  6. обновление инвентаря;
  7. подтверждение заказа.

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

Шаблоны для контроля параллелизма в автономном режиме

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

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

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

  • Оптимистичная автономная блокировка
  • Пессимистичная автономная блокировка
  • Крупнозернистый замок
  • Неявная блокировка

Параллелизм сервера приложений

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

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

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

Некоторые платформы предлагают золотую середину, позволяя изолированным областям данных назначаться одному потоку, обеспечивая как изоляцию, так и эффективность. Обычно это достигается созданием новых объектов для каждого запроса и обеспечением их недоступности для других потоков.

Итог:

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

Если вы хотите когда-нибудь встретиться со мной, подпишитесь на меня в LinkedIn.

Спасибо, что нашли время прочитать эту статью, вдохновленнуюP of EAA Мартина Фаулера, и я надеюсь, что она вам понравилась! Если да, поддержите меня, нажав кнопку аплодисментов.