В моем блоге я представил много статей о распределении и транзакциях. Прежде чем читать эту статью, я надеюсь, что читатели смогут понять эти основные знания. Вот простой список предыдущих статей, которые были расположены по порядку. Вы можете нажать «Читать в заказ:
Введение в распределенные системы
Исследование распределенной согласованности
CAP-теория распределенных систем
БАЗОВАЯ теория распределенных систем
Транзакции в Java — транзакции JDBC и транзакции JTA
Транзакции в Java — глобальные и локальные транзакции
О распределенных транзакциях, двухфазном протоколе фиксации, трехфазном протоколе фиксации
Глубокое понимание 2PC и 3PC распределенных систем
Вот краткое изложение предыдущих статей, которые являются базовыми знаниями этой статьи. В распределенных системах существует теория CAP, согласно которой доступность, согласованность данных и отказоустойчивость разделов не могут быть удовлетворены одновременно. Таким образом, основанная на CAP теория конечной согласованности BASE-теория в настоящее время более надежна для решения распределенных задач.
В распределенной системе невозможно использовать локальные транзакции для обеспечения согласованности данных. Стандартная распределенная транзакция — это глобальная транзакция (модель DTP). Он основан на 2PC для управления. Однако из-за того, что у самого 2PC есть проблема блокировки синхронизации, это также приводит к низкой эффективности глобальных транзакций. Следовательно, такая глобальная транзакция не подходит для решения проблемы распределенных транзакций крупных веб-сайтов.
гибкие дела
В отрасли решение, в основном используемое для решения распределенных транзакций, заключается в использовании гибких транзакций. Так называемая гибкая транзакция, по сравнению с жесткой транзакцией ACID в транзакции базы данных, вещь, гарантированная гибкой транзакцией, «в основном доступна и в конечном итоге непротиворечива». данные.
Хотя гибкие транзакции не полностью следуют ACID, как жесткие транзакции, они также частично следуют ACID.Давайте рассмотрим четыре атрибута ACID и степень поддержки гибких транзакций:
Атомарность: строго следуйте
Согласованность: согласованность после транзакции строго соблюдается; согласованность в транзакции может быть соответствующим образом ослаблена.
Изоляция: не затрагивается между параллельными транзакциями; видимость промежуточных результатов транзакций позволяет ослабить безопасность
Постоянство: Строго следовать
Основы гибких транзакций
Определение гибких транзакций было введено ранее.В настоящее время в отрасли существует три основных типа гибких транзакций: асинхронный тип гарантии, тип компенсации и тип уведомления с максимальной эффективностью.
Эти три типа гибких транзакций в основном имеют соответствующие реализации, и разные типы гибких транзакций необходимо использовать в разных сценариях. Эти типы гибких транзакций на самом деле зависят от некоторых основных режимов или базовых интерфейсов и основных функций.
Например, для реализации гарантированных асинхронных гибких транзакций с использованием надежной согласованности сообщений в конечном итоге используются идемпотентные и запрашиваемые операции. Что касается конкретной реализации, мы представим ее в следующих статьях.В этой статье кратко представлены эти основные режимы реализации гибких зависимостей транзакций.
Обратите внимание, что шаблон гибких транзакций, который будет представлен ниже, не является решением для гибких транзакций. Это основа для выполнения гибких транзакций. То есть, если вы хотите выполнять гибкие транзакции, ваши интерфейсы и функции должны соответствовать следующим требованиям. Не обязательно все, потому что требования разных программ разные. Но если они не удовлетворены, нельзя вести гибкие дела.
запрашиваемая операция
Операции с запросами, необходимые почти для всех распределенных решений.
Возьмем пример распространенного распределенного сценария, такого как функция обработки заказов:
/** 支付订单处理 **/
public void completeOrder() {
orderDao.update(); // 订单服务本地更新订单状态
accountService.update(); // 调用资金账户服务给资金帐户加款
pointService.update(); // 调用积分服务给积分帐户增加积分
accountingService.insert(); // 调用会计服务向会计系统写入会计原始凭证
merchantNotifyService.notify(); // 调用商户通知服务向商户发送支付结果通知
}
В приведенном выше примере обработки платежного поручения, за исключением订单服务本地更新订单状态Все остальные операции необходимо выполнять через вызов интерфейса RPC, в этом случае простая локальная транзакция не может гарантировать согласованность данных. Необходимо ввести распределенные транзакции. В процессе выполнения распределенной транзакции, если на определенном этапе возникает ошибка, необходимо четко знать статус обработки других операций.Для этого требуется, чтобы другие сервисы предоставляли интерфейсы запросов, чтобы гарантировать, что статус обработки операций может быть оценен по запросу. .
Чтобы гарантировать, что операция может быть запрошена, необходимо иметь глобальный уникальный идентификатор для каждого вызова каждой службы, который может быть номером бизнес-документа (например, номером заказа) или порядковым номером операции, присвоенным системой. (например, серийный номер платежной записи)). Кроме того, информация о времени операции также должна иметь полную запись.
идемпотентная операция
Идемпотентность на самом деле является математическим понятием. Идемпотентная функция или идемпотентный метод — это функция, которая может многократно выполняться с одними и теми же параметрами и получать один и тот же результат, например:
f(f(x)) = f(x)
Характерной чертой идемпотентной операции в программировании является то, что любое ее многократное выполнение имеет тот же эффект, что и однократное выполнение. То есть один и тот же метод с одними и теми же параметрами вызывает один и тот же бизнес-результат несколько раз и вызывает его один раз.
Это требование на самом деле относительно легко понять, потому что для обеспечения окончательной согласованности данных многие решения потребуют много повторных операций.Если метод не гарантированно идемпотентный, он не будет повторяться.
Существует множество способов реализации идемпотентных операций, таких как кэширование всех запросов и результатов обработки в системе и прямой возврат последнего результата обработки после обнаружения повторяющейся операции.
Компенсируемая операция
Когда дело доходит до транзакций, чтобы обеспечить атомарность, может произойти фиксация и откат.В распределенных транзакциях, если вы хотите выполнить откат, вам необходимо предоставить компенсируемые операции.
Например, в приведенном выше примере обработки заказа в调用积分服务给积分帐户增加积分После выполнения операции, после согласования распределенной транзакции, окончательно принимается решение об откате всей транзакции, после чего необходимо предоставить调用积分服务给积分帐户扣减积分операция.
Более того, операция компенсации также должна удовлетворять идемпотентности.
Операция ТСС
TCC расшифровывается как Try-Confirm-Cancel.
Попробуйте: попробуйте выполнить бизнес
Выполните все бизнес-проверки (согласованность) и зарезервируйте необходимые бизнес-ресурсы (квазиизоляция).
Подтвердить: Подтвердить выполнение бизнеса
Реальное выполнение бизнеса без какой-либо бизнес-проверки. Используйте только бизнес-ресурсы, зарезервированные на этапе «Попытка». Подтверждение операции должно удовлетворять идемпотентности.
Отменить: отменить выполнение дела
Освобождение ресурсов службы, зарезервированных на этапе пробной версии.
Операция отмены должна удовлетворять идемпотентности
Этот тип аналогичен компенсирующим операциям тем, что предоставляет механизм фиксации и отката. является типичным двухфазным типом операции. Упомянутая здесь операция двухэтапного типа не относится к 2PC, которая все же отличается от 2PC.
Сравнение протоколов TCC и 2PCTCC находится на уровне бизнес-сервисов, а не на уровне ресурсов. TCC не имеет отдельного этапа подготовки, а операция Try имеет возможности как для операций с ресурсами, так и для подготовки. Операция Try может гибко выбирать степень детализации блокировки бизнес-ресурсов (определяемую бизнес) TCC имеет более высокую стоимость разработки
Суммировать
В этой статье в основном кратко представлены основы гибких транзакций и реализация гибких транзакций. Гибкая транзакция является текущим основным решением для распределенных транзакций, и ее основные режимы включают четыре: идемпотентная операция, компенсируемая операция, операция с запросом и операция TCC. В последующих статьях будут представлены решения для распределенных транзакций, так что следите за обновлениями.
использованная литература
Распределенная обработка транзакций в крупномасштабных системах SOA