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

Question

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

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

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

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

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

Вопросы

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

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

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

Answer 1

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

Смотри, например how to come to consensus in a distributed environment

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

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

Прошу прощения за вас. Фиксация обычно кажется идентичной «ложность подразумевает что-либо» в бинарной логике.

Резюмируя

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

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

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

Дополнение: к 2PC или не

С вашей Кроме того, я понимаю, что вы думаете, стоит ли включать 2PC в ваших проектах.

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

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

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

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

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

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

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

Добавление: Электронная почта и избежать потери сообщений в 2PC

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

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

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

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

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

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