Distributed Transaction Solutions and Message Queue Reliability

Distributed transactions arise when a system evolves from a single machine to multiple nodes, requiring data consistency across services.

Common solutions include 2PC (two‑phase commit), 3PC (three‑phase commit), TCC (Try‑Confirm‑Cancel), Saga, local message tables, and MQ‑based approaches.

Using a local message table ensures that business logic and message insertion occur in the same transaction, preventing mismatched success/failure states such as 业务处理成功 + 事务消息发送失败 or 业务处理失败 + 事务消息发送成功 .

MQ‑based implementations provide transactional messaging:

RocketMQ uses half messages and a transaction coordinator to decide commit or rollback, with a compensation flow when the server does not receive a commit/rollback.

Kafka relies on a transaction coordinator, transaction logs, and a two‑phase commit similar to RocketMQ, ensuring atomic writes across partitions.

RabbitMQ offers transactional channels ( channel.txSelect , channel.txCommit , channel.txRollback ) and confirm modes to guarantee delivery.

Message loss prevention strategies differ per MQ:

RocketMQ can use synchronous sending (SYNC) to wait for broker acknowledgment.

Kafka requires broker acknowledgments and replication (e.g., write to at least two replicas) to avoid loss.

RabbitMQ provides persistent messages, durable exchanges/queues, and confirm mechanisms (synchronous, batch, asynchronous) to ensure messages are not lost.

To handle duplicate messages, idempotent processing is essential. Techniques include using database unique constraints, conditional updates, or attaching a unique ID to each message and recording it in a separate table.

Each approach has trade‑offs: local message tables are simple but tightly coupled to business data and may consume database resources; MQ transactions reduce coupling but can impact performance due to additional network round‑trips and coordination.