Reprinted from http://blog.csdn.net/kongqz/article/details/8912000
1. Why do we need reliable information? Or want messages with transactions?
(1) Some of our business scenarios hope that the sending of messages and database operations are bound together - "- transactional messages are required
(2) Some of our business scenarios do not want the loss of external message sending, resulting in the inability to continue the business -- "Messages must be reliable
2. The news is reliable, what will we lose?
(1), the order of the message
Because some messages may not be sent at the time due to network and other reasons, subsequent messages are sent first to be consumed. subsequent network
(2), the real-time nature of the news
some news
(3), the business must be idempotent -- "additional workload of repeatedly receiving message processing
3. What problems will occur with an activemq message server?
(1), the message is lost
If it is not sent to the broker, it must be lost. The message is lost on the broker, and it is lost in the process from the broker to the subscriber.
(2) When the amount of concurrency is large, it cannot be accepted, and the server feigns death
When a single mq server has a large amount of concurrency, network io and other bottlenecks will occur, and the CPU will be full.
(3) The failover of the cluster fails
Some messages are very large. When the master feigns death, the slave does not know. So failover is not possible.
4. How to solve the large concurrency?
(1) Create multiple clusters and create the same queue on multiple clusters. The cluster uses the failover method to do ha
(2) Encapsulate the producer client and send message polling to the queues of multiple groups of clusters.
(3) Encapsulate the subscriber client, monitor the same queues of multiple groups of clusters, and consume messages.
5. How to solve these problems
(1) Lost if it is not sent to the broker: Before sending the broker, the message is stored locally. Remove the local file after receiving the successful sending feedback. Retrieve the local file in real time, and find that it has not been sent after a certain period of time and re-send it directly.
(2) Lost on the broker: Change the persistence of the broker to the database, and make the database master and slave
(3) From the broker to the loss of the subscriber: When the subscriber does not receive the successful receipt, the persistent data of the broker is not removed. In fact, this seems to have transaction support
(4) Failover of the cluster: establish a test queue and send messages regularly to test whether each node is in normal service. Only through such heartbeat monitoring methods to confirm whether the server is normal.
6. What solutions are there on the market at this stage?
Ali's notify strategy is similar. metaq focuses more on data pull on the subscription side