Notify is different from traditional MQ in design ideas. Its core design concept is
1. Design the system for message accumulation. It is a very common situation for consumers to have problems, and the message system must be able to ensure that the user writes normally and the TPS does not drop even when the backend consumption is unstable.
2. No single point, freely expandable design
MetaQ provides a queue service externally, and the internal implementation is also a complete queue model. The queue here is a persistent disk queue with very high reliability, and makes full use of the operating system cache to improve performance.
- It is a message middleware of a queue model with high performance, high reliability, high real-time and distributed characteristics.
- Producer, Consumer, and Queue can all be distributed.
- The Producer sends messages to some queues in turn. The set of queues is called a topic. If a Consumer is doing broadcast consumption, one Consumer instance consumes all the queues corresponding to this topic. If it is clustered consumption, multiple Consumer instances will consume the set of queues corresponding to this topic on average. .
- Able to guarantee strict message ordering
- Provides rich message pull mode
- Efficient subscriber horizontal scalability
- Real-time message subscription mechanism
- Billion-level message accumulation capability
n broadcast consumptionA message is consumed by multiple consumers. Even if these consumers belong to the same Consumer Group, the message will be consumed by each Consumer in the Consumer Group once.
In the CORBA Notification specification, the consumption methods are all broadcast consumption.
n cluster consumption
Consumer instances in a Consumer Group equally share consumption messages, similar to Point-to-Point Messaging in the JMS specification
Features are as follows:
u Each message has only one consumer.
u A sender and a receiver of a message have no timing dependencies. The receiver can fetch the message whether or not it was running when the client sent the message.
u The receiver acknowledges the successful processing of a message.
n Active consumption
The Consumer actively initiates a message acquisition request to the Broker, and the control lies entirely in the Consumer application.
Consume in a Synchronously manner similar to that described in the JMS specification
passive consumption
The Consumer registers a Callback interface, and the Metaq background automatically receives messages from the Broker and calls back the Callback interface.
Consume Asynchronously similar to that described in the JMS specification
n sequential messages
The order of consuming messages should be the same as the order of sending messages. In Metaq, it mainly refers to the local order, that is, in order to satisfy the order of a type of message, the Producer must send it in a single-threaded order, and send it to the same queue, so that the Consumer can Consume messages in the order they are sent by the Producer.
n Ordinary sequential messages
A type of sequential message. Under normal circumstances, complete sequential messages can be guaranteed. However, once a communication exception occurs, the broker restarts. Due to the change in the total number of queues, the queue located after the hash modulo is changed, resulting in temporary inconsistency in the order of messages.
n strictly sequential messages
A type of sequential message that guarantees order regardless of normal exceptions, but sacrifices the distributed Failover feature.