Хранилище Exchange. Часть 3. Extensible Storage Engine (ESE) – обработка транзакций.

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

Список всех статей серии:


В основе механизма обработки транзакций заложены 4 критерия (вкратце эти четыре критерия называют ACID):

  • Atomic – все данные в отдельно взятой транзакции (операции) либо успешны, либо неуспешны. Т.е. или все данные записываются в базу, или все данные отменяются.
  • Consistent – почтовая база переходит из одного корректного состояния в другое корректное состояние.
  • Isolated – результаты транзакции недоступны другим транзакциям, пока эти результаты не будут зафиксированы (commit)
  • Durable – зафиксированные транзакции должны сохраняться в базе даже в случае краха системы



Обработка транзакций

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

image


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

Предположим, что до этого момента каких-либо транзакций не было.

  1. Происходит какая-либо операция (например, пользователь создает и посылает новое письмо):
    • Движок ESE определяет какую страницу (page) из почтовой базы необходимо будет изменить в результате этой операции
    • Далее происходит чтение этой страницы из файла почтовой базы, после чего страница помещается в память в область, называемую ESE cache
    • В этот же момент, происходит оповещение компонента Log Buffer, который записывает текущую транзакцию в другую область в памяти. Называется эта облать, соответственно Log Buffer.
  2. После этого, движок ESE производит изменение этой страницы в памяти, т.е. совершает все действия, которые содержатся в транзакции. Такая “измененная” страница в памяти называется “dirty page”
  3. После внесения изменений в страницу в памяти (dirty page) происходит уведомление компонента Log Buffer, который фиксирует транзакцию (commit). Если при этом память, выделенная для Log Buffer, заполняется, то происходит запись всех транзакций из Log Buffer в транзакционный лог файл (что может привести к созданию нового транзакционного файла)
  4. Переодически (например, при размонитровании почтовой базы или при переполнении ESE cache) все зафиксированные транзакции (а точнее измененные старницы в памяти) записываются в файл почтовой базы
  5. После того, как страницы из памяти запишутся в файл почтовой базы, изменяется checkpoint файл, чтобы отразить какие именно транзакции были последними записаны в базу. При этом, в checkpoint файле указывается как последняя транзакция, так и лог файл, в котором находится эта транзакция

Когда почтовая база размонтируется в обычном режиме, все “dirty” страницы из памяти записываются в файл почтовой базы вместе с изменением checkpoint файла. Если служба Information Store запускается после краха сервиса, то происходит поиск всех лог файлов с незаписанными транзакциями (используя checkpoint файл, если он есть).

Основные компоненты механизма обработки транзакций

  • Log Buffer – это область в оперативной памяти, где записываются все транзакции перед их записью в транзакционный лог файл.
  • Log Writer – когда Log Buffer заполняется, все транзакции записываются этим компонентом в транзакционный лог файл. Причем запись транзакций в лог файл ведется в синхронном режиме, чтобы произвести запись в файл как можно быстрее на случай краха системы.
  • ESE Cache – это область в памяти, в которую записываются страницы из файла почтовой базы, чтобы производить над ними изменения из транзакций. Хранения страниц в памяти позволяет снизить IOPS при работе с почтовой базой.
  • Version Store – этот компонент следит за всеми изменениями в страницах в памяти. Главная его задача – знать когда и какая транзакция была произведена в страницу, чтобы в случае проблем можно было либо отменить транзакцию или разрешить конфликт между разнимы транзакциями.
  • Lazy Write – этот компонент отвечает за запись измененных (dirty) страниц из памяти в файл почтовой базы, исключая перегрузку дисков по IOPS.



Читайте также:

комментария 4

  1. Sergety:

    Спасибо за статью, очень позновательно, с нетерпением жду продолжения!

  2. Sergey:

    Когда стоит ждать прожолжения, материал полезный и нужный.

Добавить комментарий