Thao tác Liên chuỗi (2PC)

Tổng quan

Coordinator chuẩn bị cả hai participant DomainChain, sau đó fsync và đọc lại quyết định COMMIT từ journal riêng trước khi yêu cầu bất kỳ participant nào commit. Participant chỉ xác nhận khi cả hai event thao tác có gắn mã giao dịch đọc lại được từ ordering journal của chain đó; việc hoàn thiện block vẫn chạy bất đồng bộ. Bản ghi committed cuối cùng cũng phải đọc lại được trước khi báo COMMITTED. Sau khi COMMIT đã bền vững, quá trình phục hồi luôn retry theo hướng commit và không rollback participant.

Trước khi COMMIT bền vững, coordinator yêu cầu cả hai participant abort. Trạng thái chỉ là ROLLED_BACK khi cả hai xác nhận. Nếu không thể xác nhận một trong hai lệnh abort, giao dịch giữ trạng thái IN_DOUBT; coordinator retry abort khi cả hai participant khả dụng.

Khi khởi động, các bản ghi coordinator chưa hoàn tất xác định những chain đã lưu cần participant DomainChain. Các chain đã lưu khác vẫn là SubChain chung. Có thể chủ động thay placeholder chung bằng cách gọi create_sub_chain() với cùng tên và domain type; chain cũ chỉ được dừng sau khi chain thay thế kết nối thành công.

Luồng thành công

sequenceDiagram
    autonumber
    participant Client
    participant TM as CrossChainTransactionManager
    participant SRC as Source DomainChain
    participant DST as Destination DomainChain
    participant CJ as Coordinator journal

    Client->>TM: initiate_transaction(src, dst, payload)
    TM->>CJ: fsync and read back begin
    TM->>SRC: prepare_transaction(tx_id, payload, true)
    SRC-->>TM: prepared
    TM->>DST: prepare_transaction(tx_id, payload, false)
    DST-->>TM: prepared
    TM->>CJ: fsync and read back prepared
    TM->>CJ: fsync and read back COMMIT decision
    TM->>SRC: commit_transaction(tx_id)
    SRC-->>TM: ordering events read back
    TM->>DST: commit_transaction(tx_id)
    DST-->>TM: ordering events read back
    TM->>CJ: fsync and read back committed
    TM-->>Client: tx_id

Lỗi và phục hồi

flowchart TD
    PENDING --> PREPARED
    PENDING --> ABORTING
    PREPARED --> ABORTING
    ABORTING -->|both abort acks| ROLLED_BACK
    ABORTING -->|an abort is unconfirmed| IN_DOUBT
    IN_DOUBT -->|no durable COMMIT| ABORTING
    PREPARED -->|fsynced COMMIT decision| COMMITTING
    COMMITTING -->|both participant acks| COMMITTED
    COMMITTING -->|an ack is missing| IN_DOUBT
    IN_DOUBT -->|durable COMMIT| COMMITTING
    PENDING --> FAILED

Cam kết và giới hạn

• Coordinator journal được lưu riêng với OrderingService event journal, vì vậy các bản ghi của nó không bị replay như ledger event.
• Giao dịch COMMITTED nghĩa là đã đọc lại được hai cặp event của participant và bản ghi cuối cùng của coordinator từ các journal bền vững. Điều đó không có nghĩa block đã được hoàn thiện.
• Marker event của participant chứa transaction ID và bước thao tác. Khi retry, participant bỏ qua start hoặc completion event đã được chấp nhận, kể cả sau khi khởi động lại.
• Sau COMMIT bền vững, phục hồi participant dùng payload đã được coordinator xác thực trước đó và marker event đã nhận; không chạy lại xác thực nghiệp vụ dựa trên entity registry chỉ tồn tại trong bộ nhớ.
• IN_DOUBT là trạng thái có thể phục hồi, không phải thất bại cuối cùng. Gọi transaction_manager.retry_pending() để retry sau lỗi participant trong lúc chạy; khởi động lại và đăng ký participant cũng kích hoạt retry.
• Recovery chiếm quyền xử lý từng giao dịch trong khi luồng coordinator đang hoạt động. Lần gọi retry_pending() đồng thời sẽ bỏ qua giao dịch đó và có thể retry sau khi luồng đang chạy nhả quyền. Coordinator cũng từ chối abort sau quyết định COMMIT bền vững hoặc chưa xác định.

Method chính

Liên quan

• Gửi Sự kiện: operation event được đưa vào ordering journal của từng chain trước khi block hoàn thiện bất đồng bộ.
• Giảm thiểu Lỗi: xử lý lỗi cấp hệ thống và phục hồi journal.