интервьюер:Как вы понимаете транзакции в движке InnoDB?
Кандидат: В моем понимании транзакция может сделать "набор операций" либо все успешными, либо все неудачными.
Кандидат: цель транзакции — «обеспечить возможную согласованность данных».
Кандидат: Например, я отправил вам красный конверт на 888 юаней от Alipay. Тогда, естественно, мой баланс Alipay будет вычтен на 888 юаней, а ваш баланс Alipay увеличится на 888 юаней.
Кандидат: И транзакция предназначена для того, чтобы убедиться, что мой вывод баланса и увеличение вашего баланса будут успешными или неудачными одновременно, поэтому этот перевод является нормальным.
интервьюер:Хорошо, вы понимаете основные характеристики транзакций?
Кандидат: Ну, это ACID, а именно атомарность, согласованность, изоляция и долговечность.
Кандидат: Атомарность означает, что операции текущей транзакции либо выполняются успешно, либо терпят неудачу в одно и то же время. Атомарность гарантируется журналом отмены, поскольку журнал отмены записывает информацию до того, как данные будут изменены.
Кандидат: Например, если мы хотим вставить часть данных, журнал отмены запишет соответствующий журнал удаления. Когда мы хотим обновить запись, журнал отмены будет записывать предыдущую запись обновления «старого значения».
Кандидат: Если во время выполнения транзакции возникает исключение, выполнить «откат». Механизм InnoDB использует данные, записанные в журнале отмены, для «восстановления» данных до начала транзакции.
Кандидат: Консистенция, о которой я расскажу позже, сначала я расскажу об изоляции.
интервьюер:В порядке…
Кандидат: Изоляция означает, что когда транзакции выполняются «одновременно», их внутренние операции не могут мешать друг другу. Если несколько транзакций могут работать с одними данными одновременно, тогда возникнут проблемы грязного чтения, повторного чтения и фантомного чтения.
Кандидат: Следовательно, между транзакциями должна быть «определенная» изоляция. В движке InnoDB для нас определены четыре уровня изоляции:
Кандидат: Это: чтение незафиксированного (чтение незафиксированного), чтение фиксации (чтение зафиксированного), повторяемое чтение (повторяемое чтение), сериализуемое (последовательное)
Кандидат: Разные уровни изоляции имеют разную изоляцию между транзакциями (чем выше уровень, тем лучше изоляция транзакций, но ниже производительность), и изоляция реализуется различными блокировками MySQL, но экранирует детали блокировки.
Кандидат: Постоянство означает, что после фиксации транзакции ее изменения в базе данных должны быть постоянными. Грубо говоря, данные будут сохраняться на жестком диске.
Кандидат: постоянство гарантируется журналом журнала повторов.Когда мы хотим изменить данные, MySQL сначала находит «страницу», на которой находится запись, затем загружает страницу в память и изменяет соответствующую запись.
Кандидат: Для предотвращения модификации памяти MySQL зависает (если память модифицируется и зависает напрямую, то эта модификация равносильна потере).
Кандидат: MySQL вводит журнал повторов, после того, как память будет записана, будет записан журнал повторов, этот журнал повторов записывает, какие изменения были сделаны на определенной странице на этот раз.
Кандидат: Даже если MySQL зависнет посередине, мы все равно сможем восстановить данные по журналу повторов.
Кандидат: Журнал повторов записывается последовательно, и скорость записи очень высока. И он записывает физические изменения (страницы xxxx были изменены на xxx), размер файла небольшой, а скорость восстановления также высокая.
Кандидат: Давайте поговорим о непротиворечивости назад. «Непротиворечивость» можно понимать как «цель» использования транзакций, а «изоляция», «атомарность» и «долговечность» — все это средства для обеспечения «непротиворечивости». Гарантируется кодом приложения.
Кандидат: например, если во время транзакции возникает исключение, вы должны откатить транзакцию вместо того, чтобы принудительно зафиксировать транзакцию, чтобы вызвать несогласованность данных.
интервьюер: Ну, это хорошо, я много говорил.
интервьюер: Вы только что упомянули изоляцию.Затем вы сказали, что в MySQL есть четыре уровня изоляции, можете ли вы представить их отдельно?
Кандидат: Что ж, чтобы прояснить уровень изоляции, позвольте мне, кстати, рассказать о знаниях, связанных с блокировкой MySQL.
Кандидат: Под движком InnoDB по степени детализации блокировок его можно просто разделить на блокировки строк и блокировки таблиц.
Кандидат: Блокировка строки фактически действует на индекс (индекс упоминался в прошлый раз, поэтому я не буду повторяться здесь). Когда наш SQL попадает в индекс, узел индекса в условии попадания блокируется (это блокировка строки), если индекс не попадает, мы блокируем все дерево индекса (блокировка таблицы).
Кандидат: Проще говоря: заблокировано ли все дерево или несколько узлов, полностью зависит от того, попадает ли условие SQL в соответствующий индексный узел.
Кандидат: А блокировки строк можно просто разделить на блокировки чтения (общие блокировки, S-блокировки) и блокировки записи (эксклюзивные блокировки, X-блокировки).
Кандидат: Блокировка чтения является общей, и несколько транзакций могут читать один и тот же ресурс одновременно, но другим транзакциям не разрешено его изменять. Блокировки записи являются монопольными и блокируют другие блокировки записи и чтения.
Кандидат: Сейчас я вернусь к уровню изоляции и объясню это непосредственно на примере.
интервьюер:В порядке…
Кандидат: Прежде всего, поговорим о read uncommit (чтение uncommit). Например: A переводит деньги B, A выполняет заявление о переводе, но A не отправил транзакцию, B читает данные и обнаруживает, что на его счету больше денег! Б сказал А, что я получил деньги. А откатывает транзакцию [rollback], а когда Б снова проверяет деньги на счету, то обнаруживает, что денег мало.
Кандидат: Простое определение: транзакция B считывает данные, которые транзакция A еще не отправила, что в профессиональных терминах называется «грязным чтением».
Кандидат: Для измерения блокировок, фактически, при уровне изоляции read uncommit чтение не добавит никаких блокировок, а запись добавит эксклюзивные блокировки. Блокировка для чтения не добавляется, что делает невозможным исключение эксклюзивных блокировок.
Кандидат: И мы знаем, что для операций обновления InnoDB обязательно добавит блокировки записи (база данных не может допустить, чтобы одна и та же запись обновлялась одновременно). Для операций чтения, если блокировки не добавлены, это вызовет вышеуказанные грязные чтения.
Кандидат: Грязное чтение однозначно недопустимо в продакшене, если чтение заблокировано, значит при обновлении данных нет возможности их прочитать, что сильно снизит производительность базы.
Кандидат: На уровне движка MySQL InnoDB есть новое решение (для решения проблемы производительности чтения и записи после блокировки), называемое MVCC (Multi-Version Concurrency Control) многоверсионный контроль параллелизма.
Кандидат: в MVCC чтение и запись могут выполняться без блокировки, и можно избежать таких проблем, как грязное чтение. Так как же это делает MVCC?
Кандидат: MVCC создает моментальный снимок данных (Snapshot) и использует этот снимок для обеспечения определенного уровня (уровня оператора или уровня транзакции) согласованного чтения.
Кандидат: вернемся к уровню изоляции транзакций, для уровня изоляции чтения и фиксации он создает моментальные снимки на уровне операторов, а для повторяемого чтения (повторяемого чтения) создает моментальные снимки на уровне транзакций.
Кандидат: Как упоминалось ранее, уровень изоляции read uncommit будет генерировать грязные чтения, а уровень изоляции read commit (read commit) разрешает грязные чтения. Идея на самом деле очень проста: при чтении генерируется «номер версии», и последние зафиксированные данные «номер версии» не будут считаны до тех пор, пока не будут зафиксированы другие транзакции.
Кандидат: Например: транзакция A читает запись (генерирует номер версии), транзакция B изменяет запись (добавляет в это время блокировку записи), и когда транзакция A читает снова, она читает в соответствии с последним номером версии (когда после транзакции B выполняет фиксацию, будет сгенерирован новый номер версии. Если транзакция B еще не зафиксирована, транзакция A все равно будет считывать данные предыдущего номера версии.
Кандидат: Через понятие «версия» решается проблема грязного чтения, а «версия» — это фактически данные, соответствующие снимку.
Кандидат:read commit (read commit) решает проблему грязного чтения, но также имеет другие проблемы с параллелизмом. «Неповторяемое чтение»: транзакция считывает данные, которые были зафиксированы другой транзакцией, что означает, что транзакция может видеть изменения, сделанные другими транзакциями.
Кандидат: Пример неповторяемого чтения: A запрашивает базу данных для получения данных, а B изменяет данные в базе данных, что приводит к различным результатам нескольких запросов A к базе данных [Опасность: на результаты каждого запроса A влияет B ]
Кандидат: после понимания основ MVCC легко подумать о том, как уровень изоляции повторяемого чтения позволяет избежать проблемы неповторяемого чтения (также упомянутой ранее).
Кандидат: Repeatable read (повторяемое чтение) Уровень изоляции "уровень транзакции" snapshot! Каждое чтение является «версией текущей транзакции», даже если текущие данные изменены другими транзакциями (фиксация), будут считаны только данные текущей версии транзакции.
Кандидат: Уровень изоляции повторяющегося чтения имеет проблему фантомного чтения.«Фантомное чтение» относится к чтению данных, вставленных другими транзакциями в рамках одной транзакции, что приводит к непоследовательному чтению до и после.
Кандидат: На уровне изоляции повторяющегося чтения в движке InnoDB, под влиянием моментального чтения MVCC, проблема фантомного чтения была решена (поскольку он считывает данные исторической версии)
КандидатЕсли он в настоящее время прочитал (ссылаясь на выбор * из таблицы для обновления), вам необходимо сопоставить блокировку пробелов, чтобы решить проблему иллюзии.
Кандидат: Остальное — сериализуемый уровень изоляции.Его самый высокий уровень изоляции эквивалентен запрету параллелизма транзакций.Выполнение между транзакциями и транзакциями является последовательным, что является наименее эффективным, но и самым безопасным.
интервьюер: Ну да.Я вижу, вы упомянули MVCC, почему бы вам не поговорить об этом?
Кандидат: MVCC в основном реализуется через просмотр чтения и журнал отмены.
Кандидат: Журнал отмен также упоминался ранее, он будет записывать информацию перед изменением данных, а атомарность в транзакции достигается за счет журнала отмен. Поэтому существует журнал отмен, который может помочь нам найти данные «версии».
Кандидат: Представление для чтения на самом деле при запросе, InnoDB сгенерирует представление для чтения.В представлении для чтения есть несколько важных полей, а именно: trx_ids (набор номеров версий транзакций, которые еще не совершили фиксацию), low_limit_id (следующая транзакция, которая будет сгенерирована ) значение идентификатора), low_limit_id (минимальный идентификатор транзакции, для которой номер версии еще не зафиксирован) и Creator_trx_id (текущий номер версии транзакции).
Кандидат: В каждой строке данных есть два скрытых поля, а именно DB_TRX_ID (запись текущего идентификатора) и DB_ROLL_PTR (указывающий на указатель местоположения предыдущей версии данных в журнале отмены)
Кандидат: Это предзнаменование, легко обнаружить, что MVCC фактически полагается на «сравнение версий» для достижения неблокирующего чтения и записи, а данные о версии существуют в журнале отмены.
Кандидат: Для разных уровней изоляции (фиксация чтения и повторяемое чтение) это не что иное, как при уровне изоляции фиксации чтения каждый раз создается новое представление чтения, а уровень изоляции повторяющегося чтения — это только одно представление чтения на транзакцию.
интервьюер: Ладно. Не буду вдаваться в подробности, поэтому на сегодня остановлюсь.
Резюме этой статьи:
-
Транзакции обеспечивают возможную согласованность данных
-
Транзакции имеют четыре характеристики: атомарность, непротиворечивость, изоляция и устойчивость.
- Атомарность гарантируется журналом отмены
- Долговечность гарантируется журналом повторов
- Изоляция зависит от уровня изоляции базы данных, который мы выбираем, включая чтение без фиксации, чтение с фиксацией, повторяемое чтение, сериализуемость.
- Согласованность — это цель транзакций, и согласованность гарантируется приложением.
-
Параллелизм транзакций будет иметь различные проблемы, включая грязные чтения, повторные чтения и фантомные чтения. Различные уровни изоляции выше могут решить проблему, вызванную одновременными транзакциями, и уровень изоляции фактически реализуется блокировками MySQL.
-
Частая блокировка приведет к снижению производительности базы данных.Многоверсионный контроль MVCC введен для достижения неблокирующего чтения и записи и повышения производительности базы данных.
-
Принцип MVCC реализуется путем чтения и просмотра журнала отмены.
Добро пожаловать в мой публичный аккаунт WeChat【Java3y] Давайте поговорим об интервью по Java
Серия [Онлайн-интервьюер-Мобильный терминал]Продолжаем обновлять два раза в неделю!
【Онлайн-интервьюер-компьютер】СерияПродолжаем обновлять два раза в неделю!
Оригинал это не просто! ! Проси три! !