Серия статей о MySQL:

«MySQL» понимает механизм блокировки InnoDB и то, как решить проблему перепроданности в условиях высокой параллелизма.

Стратегия оптимизации высокопроизводительного индекса MySQL

Интеллект-карта для чтения серии статей:

Прошел месяц с последней статьи о MySQL, и наконец у меня появилось время написать о делах MySQL. Содержание этой статьи предназначено для механизма MySQL InnoDB по умолчанию.

Сначала подойдите к ментальной карте, чтобы прочитать полный текст:

1. Зачем нужен бизнес

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

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

Давайте взглянем на процесс вышеупомянутого банка, который разделен на три простых шага:

A инициирует перевод 10 000 в B -> Банковская карта A минус 10 000 юаней -> Банковская карта B увеличивается на 10 000 юаней.

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

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

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

1.1 ACID

1.1.1 А (атомарность) Атомарность

Тем не менее, пример передачи выше, атомарность подчеркивает, что три шага передачи от A к B должны быть либо успешными, либо нет.

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

1.1.2 C (Консистенция) Консистенция

Согласованность — это когда транзакция переводит базу данных из одного согласованного состояния в другое. Ограничения целостности базы данных не были нарушены до и после запуска транзакции.

В приведенном выше примере перевода, независимо от того, был ли перевод успешным или неудачным, общая сдача А и Б составляет 10 000 юаней, ни больше, ни меньше.

1.1.3 I (изоляция) изоляция

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

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

1.1.4 D (долговечность) Стойкость

Долговечность означает, что после совершения транзакции результат остается постоянным.

2. Осуществление сделки

Реализация транзакции заключается в том, как реализовать функцию ACID, как показано на следующем рисунке:

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

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

2.1 журнал повторов журнал повторов

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

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

2.1.1 Процесс обновления

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

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

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

2.1.2 Содержимое формата хранения

Прежде чем понять формат хранения и содержимое журнала повторов, давайте сравним его с двоичным журналом binlog. Binlog в основном предназначен для репликации master-slave и восстановления POINT-IN-TIME. Я думаю, что все знакомы с ним.

Бинлог записывается только тогда, когда транзакция зафиксирована, и генерируется верхним уровнем базы данных. Журнал повторов создается на уровне механизма Innodb.

Сравните способ написания одного или двух:

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

Журнал повторов начинает запись в начале транзакции, и *T1 указывает, что транзакция зафиксирована. Записывается журнал физического формата, то есть модификация каждой страницы.

Журнал повторов по умолчанию хранится в блоках, каждый блок имеет размер 512 байт. Различные механизмы баз данных имеют соответствующие форматы журналов повторного выполнения.Управление хранилищем Innodb основано на страницах, поэтому его журналы повторного выполнения также основаны на страницах.

формат журнала повторов:

redo_log_type тип журнала повторов
ID табличного пространства space
page_no смещение страницы
redo_log_body хранит содержимое

Выполните оператор вставки, журнал повторов будет примерно таким:

INSERT INTO user SELECT 1,2;
           |
page(2,3), offset 32, value 1,2 # 主键索引
page(2,4), offset 64, value 2   # 辅助索引

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

2.1.3 Механизм восстановления

Давайте посмотрим на механизм восстановления журнала повторов:

На приведенном выше рисунке показан механизм восстановления журнала повторов Прежде всего, позвольте мне объяснить, что означает номер LSN на рисунке?

LSN (номер последовательности журнала) Порядковый номер журнала.В Innodb номер LSN занимает 8 байт и монотонно увеличивается.Значения: общее количество записей журнала повторов, местоположение контрольной точки и версия страницы.

Предполагая, что база данных выходит из строя, когда LSN=10000, контрольная точка на диске — 10000, что означает, что диск был сброшен до серийного номера 10000. Текущая контрольная точка повторного журнала — 13000, и данные 10000-13000 должны быть восстановлен.

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

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

2.2 undo log

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

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

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

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

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

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

3. Заявление о контроле транзакций

На приведенном выше рисунке перечислены некоторые операторы управления транзакцией.Я полагаю, что все использовали start transaction/begin, commit и rollback.

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

В качестве соотношения предположим, что вам нужно три маршрута для поездки к месту назначения: первый — это скоростной поезд из Шэньчжэня в Гуанчжоу, второй — из Гуанчжоу в Джакарту, а третий — из Джакарты на остров. Если вы отмените поездку третьим рейсом, бизнес будет откатываться.Если вы хотите снова встретиться с Шэньчжэнем, вы обязательно почувствуете десять тысяч травяно-грязных лошадей. Поскольку первый и второй шаги одинаковы при повторном входе в транзакцию, нет необходимости откатывать, достаточно откатить третий шаг.

set transaction изменяет уровень изоляции транзакции, например, модифицирует транзакцию уровня сеанса:

set session transaction isolation level read committed;

4. Уровень изоляции транзакций

Изоляция транзакций достигается за счет блокировок.В прошлой статье также упоминался уровень изоляции транзакций.Это краткий обзор.

Четыре уровня изоляции, в порядке READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE, уровень изоляции от низкого к высокому, InnoDB по умолчанию использует уровень REPEATABLE-READ, этот уровень вызовет фантомные проблемы чтения в других базах данных. InnoDB использует алгоритм Next-Key Lock, чтобы избежать этой проблемы.Что такое проблема фантомного чтения, пожалуйста, обратитесь к предыдущей статье.

Чем ниже уровень изоляции, тем меньше времени транзакция запрашивает и удерживает блокировки.

4.1 READ-UNCOMMITTED

READ-UNCOMMITTED по-китайски называется незафиксированным чтением, то есть транзакция прочитала данные, измененные другой незафиксированной транзакцией.Весь процесс выглядит следующим образом:

Как показано на рисунке выше, SessionA и SessionB соответственно открывают транзакцию.Транзакция в SessionB сначала обновляет столбец name записи с идентификатором 1 на «lisi», а затем транзакция в Session запрашивает запись с идентификатором 1. уровне изоляции зафиксированного чтения результат запроса меняется с «zhangsan» на «lisi», что означает, что транзакция прочитала запись, измененную другой незафиксированной транзакцией. Но если транзакция в SessionB откатывается позже, транзакция в SessionA эквивалентна чтению несуществующих данных, что также называется грязным чтением.

Видно, что READ-UNCOMMITTED очень небезопасен.

4.2 READ COMMITTED

READ COMMITTED Китайский язык называется зафиксированным чтением или неповторяемым чтением. То есть транзакция может прочитать данные, измененные другой уже отправленной транзакцией.Если другие транзакции изменяют и отправляют данные, транзакция также может запросить последнее значение. Как показано ниже:

После того, как SessionB изменен на шаге 4, если он не отправлен, SessionA не может его прочитать, но как только SessionB отправлен, SessionA может прочитать измененное содержимое SessionB.

Фиксированное чтение в некоторой степени нарушает изоляцию транзакций.

4.3 REPEATABLE READ

ПОВТОРЯЕМОЕ ЧТЕНИЕ по-китайски называется повторяемым чтением, то есть транзакция может прочитать данные, измененные другой транзакцией, которая была зафиксирована, но после первого чтения записи, даже если другие транзакции позже изменят значение записи и зафиксируют , транзакция Когда запись считывается позже, значение, считанное в первый раз, все еще читается, вместо того, чтобы каждый раз считывать разные данные. Как показано ниже:

InnoDB по умолчанию использует этот уровень изоляции.Независимо от того, как SessionB изменяет значение id=1, то, что читает SessionA, все равно будет первым, когда он читает саму транзакцию.

4.4 SERIALIZABLE

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

Когда SessionB изменяет id=1, SessionA необходимо дождаться, пока SessionB зафиксирует транзакцию при чтении id=1. Понятно, что SessionB добавил блокировку X при обновлении.

5. Распределенные транзакции

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

5.1 Распределенные транзакции InnoDB

InnoDB поддерживает распределенные транзакции и состоит из одного или нескольких менеджеров ресурсов (менеджеров ресурсов), менеджера транзакций (менеджера транзакций) и прикладной программы (программы приложения).

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

Как показано ниже:

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

5.2 Распределенная транзакция TCC

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

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

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

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

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

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

Вопросы для размышления:

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

Добро пожаловать, чтобы оставить сообщение для обсуждения.

Для получения дополнительных статей и обсуждений, связанных с MySQL, обратите внимание на общедоступную учетную запись: "Tiancheng Technology Talk"