Настройка производительности распределенной (XA) транзакции - как?

2

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

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

  • 0
    За что голосовать "минус"? И закрыть запрос?
  • 2
    Вы на самом деле не задавали вопрос, вы просто опубликовали заявление о намерении представить свой ответ. Также вы пометили java и .net (которые не перекрываются), в то время как ваш ответ не является конкретным и может применяться к любому языку / платформе.
Показать ещё 4 комментария
Теги:
database
transactions
xa
atomikos

1 ответ

3
Лучший ответ

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

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

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

Изображение 174551

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 2
    web.archive.org/web/20160113083734/http://www.jroller.com/… и ваша диаграмма неверна - принудительная запись TC выполняется после подготовки, потому что до этого у вас нет решения о фиксации записи.
  • 0
    UML должен быть правильным сейчас.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню