Как бы вы настроили распределенную ( XA) транзакцию для повышения производительности?

Question

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

Что такое внутренние транзакции XA и как мы можем их настроить?

Answer 1

Сначала давайте добавим общий словарный запас. У нас есть две или более сторон

• Координатор транзакций - вот где находится наша бизнес-логика. Это сторона, которая управляет распределенной транзакцией.
• Участник транзакции (XAResource) это может быть любой Dababase, поддерживающий распределенные транзакции, или какой-либо другой объект, поддерживающий протокол XA, такой как служба обмена сообщениями.

Позволяет выделить основные функции API, выполняемые во время транзакции XA. - начало (XID) - конец (XID) - подготовка (XID) - фиксация (XID)

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

Параметр XID используется в качестве уникального ключа, идентифицирующего транзакцию. Каждый координатор транзакций и каждый участник в любое время могут участвовать в более чем одной транзакции, поэтому это необходимо для их идентификации. XID состоит из двух частей: одна часть идентифицирует глобальную транзакцию, вторая часть идентифицирует участника. Это означает, что каждый участник в той же транзакции будет иметь свой собственный субидентификатор. Как только мы достигли фазы подготовки транзакции, каждый участник транзакции записывает свою работу в журнал транзакций, и каждый участник транзакции (XARersource) голосует, если его часть в порядке или не выполнена. Как только все голоса получены, транзакция совершается. Если питание отключается, и Координатор транзакций, и Участник транзакции сохраняют свои журналы транзакций надежными и могут предполагать свою работу. Если один из участников проголосует за СБОЙ во время принятия транзакции, будет инициирован последующий откат.

Последствия с точки зрения производительности

В соответствии с теоремой CAP каждое приложение (функциональность) находится где-то между треугольником, определяемым согласованностью, разбиением и доступностью. Основная проблема с транзакцией XA/ Distributed заключается в том, что она требует чрезвычайной согласованности.

Это требование приводит к очень высокой активности ввода-вывода в сети и на диске.

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

Форсирование диска растет с увеличением количества участников.

1 участник считается обычной транзакцией
2 участника на 5 дисков
3 равно 7

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

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

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

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

• Для этого вам нужно убедиться, что у вас быстрая сеть с минимальной задержкой
• Убедитесь, что у вас есть жесткие диски с минимальной задержкой и максимальной скоростью произвольной записи. Хороший SSD может сделать чудо. -Попробовать как можно меньше распределенных ресурсов в транзакции
• Постарайтесь разделить ваши данные на данные, которые предъявляют строгие требования к согласованности и доступности (оперативные данные), и данные, которые предъявляют низкие требования к согласованности. Использование данных в реальном времени Распределенная транзакция. Для автономных данных используйте обычную транзакцию или нет транзакции, если ваши данные не требуют этого.

Мой ответ основан на том, что я прочитал в "XA выставлено" (и личном опыте), который, кажется, больше не доступен в Интернете, что побудило меня написать это.