Product Advantages
Features | CMQ | RabbitMQ | RocketMQ |
---|---|---|---|
Flush Mechanism
|
Sync flush with data persistence at 99.999999% |
Sync flush |
Returning confirmation to the client is allowed without flushing, so messages may get lost during server downtime |
Message Retention Limit
|
No limit on message retention, so tens of billions of messages can be retained |
The limit depends on the disk capacity |
The limit depends on the disk capacity |
Strong Consistency Algorithm
|
Raft algorithm |
Guaranteed Multicast (GM) algorithm with complicated locating |
Strong consistency cannot be guaranteed |
Availability
|
High availability. The service is available as long as broker has two nodes |
The GB algorithm returns success only if all online nodes succeed, which is not friendly to network partitioning. Availability is average |
Auto-switch is not supported, so manual operation is required on the slave when the master fails |
Scale-out
|
Smooth scale-out with one single cluster able to process 100,000+ QPS. Logically, one single queue can provide services across multiple clusters |
Cluster expansion depends on scheduling such as frontend LSV load balancing |
Scale-out is not supported |
Consumption Model
|
Push / Pull |
Push / Pull |
Pull |
Batch Production
|
Yes |
No |
Yes |
Data Check
|
Checksum |
None |
CRC |
Message Rollback
|
Yes |
No |
No |
Message Filtering Through Routing Key Matching
|
Yes |
Yes |
Yes |
Message Delaying
|
Yes |
No |
Yes |
Message Retrying
|
Yes |
Yes |
Yes |
Dead Letter Queue
|
Yes |
Yes |
No |
Performance (stress testing on servers with dual-core and 4 GB memory)
|
Read/write at 120,000 QPS |
Read/write at 100,000 QPS |
Read/write at 100,000 QPS |
Product Features
Async Communication Protocol
Tencent CMQ provides an async communication protocol. After sending the message to the message queue, the sender can return immediately without waiting for the recipient's response. The message will be saved in the queue until retrieved by the recipient.
Guaranteed Message Delivery
If the recipient is not available when the message is sent, the message queue will retain the message until it is successfully delivered.
Decoupling
Tencent CMQ reduces the coupling between two processes. As long as the message format remains the same, no changes will be made to the sender even if the API, location or configuration of the recipient is changed. Furthermore, the sender does not need to know who the recipient is, so the system design is simplified. On the contrary, for example, if the connection is established by a remote procedure call (RPC) or between services through a socket, when the API, IP or port of one end is changed, the other end is required to modify the code or configuration accordingly.
Message Routing
A connection is not required between the sender and the recipient as CMQ ensures that messages are routed from the sender to the receiver. Message routing is even available between two services that are essentially difficult to communicate with each other through the network.
Application Scenarios
The issue with the distributed transactions of the red packet system is critical. The WeChat architecture group proactively introduces CMQ to the system to prevent the distributed transactions from consuming too many system resources. The CMQ red packet queue ensures reliable storage and delivery of red packet message. Plus, CMQ writes the messages in triplicate to the disk in real time to prevent data loss. Payment will be retried multiple times in order to prevent rollback and frequent polling of the database if the payment fails to be credited into the recipient's account.
Learn more >>
Related products: Cloud Virtual Machines, VPC