Практика режима TCC в производстве

распределенный

1. Почему стоит выбрать ТСС

Dubbo используется для наших служебных вызовов, и это деликатная операция с большими суммами денег.TCC является наиболее подходящим без изменения исходного метода вызова.

2. Основная структура TCC в отрасли

В основном мы исследовали TCC-Trancsactional при его использовании, а затем исследовали Seata с открытым исходным кодом (Fescar). Наконец, в сочетании с реальной ситуацией, я реализовал свою собственную структуру TCC.

Принцип Seata TCC

  1. Чтобы открыть глобальную транзакцию, TM обращается к TC, чтобы открыть глобальную транзакцию, TC создает глобальный идентификатор транзакции и возвращает его в TM, глобальная транзакция открывается, и глобальный идентификатор транзакции включается в RootContext (ThreadLocal). ).
  2. Когда вызывается бизнес-метод, который должен быть выполнен, выполняется синтаксический анализ компонента TCC, создается ресурс TCC и он регистрируется в TC.
  3. При вызове бизнес-метода, который должен быть выполнен, транзакция филиала регистрируется в TC, и транзакция филиала включается в управление глобальной транзакцией.
  4. TM инициирует глобальную фиксацию или откат к TC.

Недостатки Сеата ТСС

  1. Множественные вызовы RPC между участниками и TC, накладные расходы сети будут влиять на определенную производительность.
  2. В настоящее время поддерживаются только транзакции хранилища файлов, а механизм восстановления транзакций неполный.
  3. Контроль исключений требует, чтобы деловая сторона контролировала себя.

TCC Tracnsactional

TCC Transactional в основном состоит из двух аспектов.У него нет отдельного координатора транзакций, но он связывает координатора транзакций и приложение.Преимущество этого в том, что пока гарантируется доступность приложения, доступность координатора транзакций может быть гарантировано, а также сокращение вызовов RPC между деловой стороной и TC. Он предоставляет различные методы хранения транзакций, имеет возможности восстановления транзакций, а также платформу для эксплуатации и обслуживания и используется многими компаниями.

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

В-третьих, дизайн модели базы данных

Сервис транзакций вызывает не менее трех сервисов, каждый из которых предполагает обмен средств. После использования TCC исходная модель базы данных не может адаптироваться к идее дизайна TCC.После обращения к дизайну Ant Financial мы повторно оптимизировали модель данных службы позиций и службы комиссий.

  • Исходная модель базы данных холдинговой службы

    CREATE TABLE IF NOT EXISTS `position`(
`id` INT UNSIGNED AUTO_INCREMENT,
`amount` DECIMAL(20,8), -- 持仓金额
 PRIMARY KEY ( `id` )
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

  • Модифицированная модель базы данных позиций

    CREATE TABLE IF NOT EXISTS `position`(
 `id` INT UNSIGNED AUTO_INCREMENT,
 `amount` DECIMAL(20,8), -- 持仓金额
 `frozen` DECIMAL(20,8), -- 冻结资金
  PRIMARY KEY ( `id` )
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

3. Параллельный контроль

  1. Пробный этап

    update position set amount=amount - #{money},frozen=frozen + #{money}
where id = #{id} and amount > #{money};

    Вычтите позиции и увеличьте замороженную сумму.

  2. Подтвердить этап

    update position  set frozen= frozen - #{money} where id = #{id};

    Заморозить замороженные средства.

  3. Отменить этап

    update position  set amount=amount + #{money} ,frozen= frozen - #{money}
where id =#{id} and frozen > #{money};

    Увеличение позиций и освобождение замороженных средств.

4. Ненормальный

1. Пустой откат - попытка не выполнена отменить выполнение

  1. Попробуйте время ожидания истекло
  2. Вызываемый абонент временно отстранен

2. Проблема идемпотента

  1. сетевой джиттер
  2. Восстановление транзакции несколько раз

3. Подвеска

  1. Истечет время ожидания интерфейса попытки, выполните отмену, и интерфейс попытки возобновится.

Пять, ненормальный контроль

 create table tcc_transaction_xxx(
   `id`              INT UNSIGNED AUTO_INCREMENT,
   `app`             char(20) comment '业务模块',
   `tx_id`           varchar(100) not null comment '全局事务id',
   `branch_id`       varchar(100) not null comment '分支事务id',
   `create_time`     datetime not null comment '创建时间',
   `update_time`     datetime not null comment '更新时间',
   `content`         varbinary(8000)  default null comment '事务内容',
   `status`          tinyint      not null comment '状态<>try=0=已发送&confirm=1=已提交&cancel=已回滚',
   `version`         int(11) default 0 comment '版本',
   `retried_content` int(11) default 0 comment '重试次数',
   PRIMARY KEY (`id`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8;
  1. Пробный этап

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

  1. подтвердить этап

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

  1. отменить фазу

Справочная статья

Глубокий анализ распределенных транзакций в режиме Seata TCC | Прямая трансляция SOFAChannel#4 — статьи о распределенной архитектуре финансового уровняzhuanlan.zhihu.com/p/63552935

Анализ исходного кода распределенных транзакций Seata TCC — статья Янга Чена — Ищут программистаzhuanlan.zhihu.com/p/64484721

Анализ исходного кода распределенных транзакций Seata TCC — статья Янга Чена — Ищут программистаzhuanlan.zhihu.com/p/64484721

Категории