SOFAStack Message Queue (SOFAMQ) is a distributed message middleware built on Apache RocketMQ. It is deeply integrated with the Scalable Open Financial Architecture (SOFAStack) to provide asynchronous decoupling and peak-load shifting for distributed applications. SOFAMQ supports various message types, such as transactional, ordered, and scheduled messages, and provides financial-grade features, including high reliability, high throughput, and low latency.
Scenarios
Asynchronous decouplingThe publish/subscribe pattern of a message queue can decouple upstream and downstream business systems. It also supports multiple downstream consumers that process the same message. For example, in a financial scenario, the payment center is the core system of the Alipay primary site. Each payment transaction triggers hundreds of downstream business systems, such as the account center, user center, rights center, and stream computing analysis systems. The overall business system is large and complex. If applications are tightly coupled, a failure in any single application can affect the entire business. Using a message queue for asynchronous communication and application decoupling improves business continuity.
Peak-load shiftingIn a distributed architecture, different applications often have different performance capacities. During large-scale events, such as the Double 11 shopping festival, anniversary sales, or flash sales, high traffic spikes can occur. These spikes can overload or even crash systems and affect the user experience. A message queue enables peak-load shifting by handling large message backlogs. After a producer sends a message, consumers can process it at a rate that matches their own system capacity.
Ordered sending and receivingThis means that consumers process messages in the same order that they were sent, which ensures First-In, First-Out (FIFO). Many financial scenarios require ordered processing. For example, the time-priority principle in securities trading applies to processes such as order creation, payment, and refunds in a trading system.
Distributed transactional consistencyApplication decoupling often introduces challenges with transactional consistency across multiple applications. For example, after a successful payment transfer, a bill must be generated and user points must be updated. The distributed transaction feature of a message queue can decouple these systems while ensuring eventual data consistency.
For more information, see Application Scenarios.
Core concepts
Topic: A message subject that categorizes messages. Producers send messages to topics.
Producer: Also known as a publisher. It creates and sends messages to a topic.
Consumer: Also known as a subscriber. It receives and processes messages from a topic.
Message: The data and optional attributes that a producer sends to a topic and that is eventually delivered to a consumer.
Message attribute: An attribute that a producer can define for a message, such as a Message Key or a Tag.
Group: A set of producers or consumers that typically produce or consume the same category of messages and have consistent publishing or subscription logic.
For more definitions, see Glossary.
Message sending and receiving model
MSMQ supports the publish/subscribe pattern. A producer application creates a topic and sends messages to it. A consumer application creates a subscription to that topic to receive messages from it. Communication can be one-to-many (fan-out), many-to-one (fan-in), or many-to-many.
Producer cluster
A producer cluster represents an application that sends messages and contains multiple producer instances. These instances can be located on different machines, run as multiple processes on a single machine, or exist as multiple producer objects within a single process.
A single producer cluster can send messages to multiple topics. When sending a transactional message, if a producer instance unexpectedly goes down, the broker performs a callback to any available instance in the producer cluster to confirm the transaction resolution.
Consumer cluster
A consumer cluster represents an application that consumes messages and contains multiple consumer instances. These instances can be located on different machines, run as multiple processes on a single machine, or exist as multiple consumer objects within a single process.
By default, multiple consumers within a single consumer cluster consume messages in a load-balancing mode. If the broadcast mode is set, each instance in the consumer cluster consumes the full data.
A consumer cluster corresponds to one Group ID. A Group ID can subscribe to multiple topics, as shown for Group 2 in the preceding figure. You can set the subscription relationship between a group and a topic directly in the program.