Распределенные транзакции - почему мы сохраняем транлоги в файловую систему?

Question

Все менеджеры транзакций (Atomikos, Bitronix, IBM WebSphere TM и т. Д.) Сохраняют некоторые "журналы транзакций" в папке "tranlogs" в файловой системе.

Когда случается что-то ужасное и сервер выходит из строя, иногда транлоги ломаются. Они требуют ручной процедуры восстановления.

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

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

1. Если что-то пошло не так на какой-либо стороне (сеть, ошибка приложения, тайм-аут) - я ожидаю, что вся многоресурсная транзакция не будет зафиксирована ни в одной ее части. Все остатки должны быть убраны рано или поздно автоматически.
2. В случае сбоя менеджера транзакций (сбой файловой системы, сбой источника питания) - я ожидаю, что все транзакции под этой TM будут откатываться (очевидно, на уровне тайм-аута БД).
3. Хранение файлов для журналов не является обязательным, если я не хочу никакого автоматического восстановления TX (что бы это ни значило).

Вопросы

Почему я не могу так думать? Что такого сложного в 2PC?

Каковы точные риски, когда я очищаю сломанные транлоги?

Если я ошибаюсь и мне действительно нужен весь беспорядок с состоянием файловой системы 2PC. Вас не беспокоит тот факт, что менеджер TX может на самом деле легко и безобразно нарушить состояние хранилища?

Answer 1

Когда я впервые столкнулся с двухфазным коммитом в реальной жизни в 1994 году (первоначально в более крупной среде Oracle7), у меня была похожая первоначальная реакция. Какой кровавый позор, что вообще невозможно сделать это простым. Но, оглядываясь на книги по алгоритмам университета, выясняется, что общего решения для 2PC не существует.

Посмотрите, например, как прийти к консенсусу в распределенной среде

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

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

Сопереживаю тебе. Как правило, его исправление в бинарной логике идентично "Ложь подразумевает что-либо".

подведение

На Why can't I think like this? а также What's so complicated about 2PCСмотри выше. Эта алгоритмическая проблема не может быть решена повсеместно.

На What are the exact risks when I clear broken tranlogs?: у менеджера транзакций есть какая-то база данных, которая его поддерживает. Удаление журналов является той же проблемой в общем программном обеспечении реляционных баз данных; вы теряете информацию о транзакциях в процессе. Некоторые платформы БД все еще могут иметь несколько или в основном целочисленные файлы. Для справки и немного теории базы данных, см. Википедию.

На Don't you feel sick about the fact that TX manager can actually break storage state in an easy and ugly manner?Да, иногда, когда мне приходится много работать в команде, я действительно ненавижу это. Но хорошо, это держит меня на работе:-)

Дополнение: до 2шт или нет

Из вашего добавления я понимаю, что вы думаете, стоит ли включать 2PC в ваши проекты.

На мой взгляд, ваш пробег может отличаться. Наша компания придерживается политики 2PC: по возможности избегайте ее. Однако в некоторых средах, особенно в устаревших системах и сложных средах, таких как банковская система, вы не можете обойти это. Заказчик требует этого, и он может не захотеть позволять вам вносить серьезные изменения в другие компоненты инфраструктуры.

Когда вы должны сделать 2PC: делайте это хорошо. Мне нравится чистая архитектура программного обеспечения и инфраструктуры, и что-то настолько простое, что даже через 5 лет становится понятно, как это работает.

Во всех остальных случаях мы избегаем двухфазного коммита. У нас есть собственная структура (Invantive Producer) от клиента до сервера приложений и базы данных. В этой структуре мы решили пожертвовать элементами ACID, когда обычно работаем в распределенной среде. Разработчик приложения должен заботиться о себе, например, об атомарности. Часто это возможно без особых усилий или даже не требует размышлений. Например, все программное обеспечение должно быть безопасно для перезапуска. Даже при атомарности транзакций это требует некоторого размышления, чтобы сделать это хорошо в массивной многопользовательской среде (например, проблемы с блокировкой).

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

Так что мой совет будет:

• Старайтесь избегать 2PC.
• Но хорошо инкапсулируйте логику транзакций.
• Позволяет делать 2PC без полной перестройки, а только менять вещи там, где это необходимо.

Я надеюсь, это поможет вам. Если вы можете рассказать мне больше о ваших типичных средах (размер в #tables, размер в постоянных данных в ГБ, размер в #concurrent пользователях, типичное программное обеспечение mgmt для транзакций и платформа), я могу внести некоторые дополнения или улучшения.

Дополнение: электронная почта и предотвращение потери сообщений в 2PC

Относительно того, предлагает ли объединение БД с JMS: Нет, объединение БД с JMS обычно мало что дает; он сам по себе уже имеет некоторую базу данных, поэтому первоначальный вопрос о журналах транзакций.

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

Это крепкий орешек; Я с удовольствием проводил аудит безопасности, и одной из самых простых проблем безопасности была проверка использования электронной почты.

Электронная почта - помимо того, что она не является конфиденциальной и защищенной от взлома в большинстве ситуаций, таких как открытка, - не имеет гарантий для доставки и / или чтения без дополнительных мер. Например, даже когда электронная почта доставляется непосредственно между вашим агентом пересылки почты и получателем, потеря данных может произойти без уведомления монитора транзакций. Это даже ухудшается, когда задействовано несколько прыжков. Например, у каждого MTA есть свой собственный механизм очередей, в котором "бомба может быть сброшена", что приводит к потере данных. Но вы также можете подумать о спам-мерах, неправильной конфигурации, почтовых циклах, нажатии на удаление файла случайно и т. Д. Даже если вы можете зарегистрировать отправку электронного письма без потери информации о транзакции с помощью 2PC, это не дает абсолютно никакой информации о том, электронная почта прибудет вообще или даже сделает это через первый переход.

Компания, в которой я работаю, продает большой программный пакет для бизнес-проектов. Этот пакет имеет встроенный механизм очередей, который также обрабатывает события электронной почты. Обычно объединяется в большинстве реализаций с Exchange в настоящее время. Через несколько месяцев у нас возникла приятная проблема: транзакция запущена, открытый почтовый канал, почта доставлена ​​в Exchange как MTA, зарегистрировать, что почта была обработана... транзакция прервана, поскольку табличное пространство Oracle заполнено. При следующем запуске почта снова была доставлена ​​в Exchange, снова прервана и т. Д. Алгоритм был усовершенствован, но из этого простого примера вы можете видеть, что вам нужны все конечные точки для взаимодействия в вашем 2PC, даже когда некоторые из конечных точек далеко в организации, получающей и отображающей вашу электронную почту.

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