ACTIVEMQ Use Experience

ACTIVEMQ is an open source JMS server in Apache that features not only standard JMS but also many additional features. The company introduced ACTIVEMQ, ACTIVEMQ into the company's business system in the most important part. All applications are integrated through JMS, and if the ACTIVEMQ fails, the entire system is paralyzed. Therefore, the head on the ACTIVEMQ performance, reliability, and how to use correctly, is very concerned about, and I was assigned to do research on ACTIVEMQ, this article made some summary. 1 issues to be aware of using JMS

The problem described is not just for ACTIVEMQ, but for other JMS as well. 1.1 do not establish and close the connection frequently

JMS uses a long connection, a program, as long as the JMS server to maintain a connection on it, do not frequently establish and close the connection. Frequent establishment and shutdown of the connection, the performance of the program has a great impact. This is not the same as JDBC. 1.2 Connection's start () and Stop () methods are expensive

The connection start () and Stop () methods of JMS are expensive and cannot be invoked frequently. When we tried it, we wrote a JMS connection pool, called the start () method each time the connection was taken out of the pool, and called the Stop () method when it was returned, but later found with Jprofiler, The average CPU time is consumed by both methods. 1.3 Start () to receive messages

Connection the start () method call to receive a JMS message. If you do not call this method, you can send a message, but you cannot receive the message. I don't know about other JMS servers, either. 1.4 Show Close session

If you forget to close the connection or Session object at the end, you will cause a memory leak. This was discovered when I was testing it. Originally thought closed connection, the session generated by this connection will also be automatically closed, the result is not the case, the session did not close, resulting in memory leaks. So be sure to show off the connection and session. 1.5 to the session to do object pool

Do object pooling for session, not connection. Session is also an expensive object, and each use is new and closed, at a very high price. And then we found that the original connection is thread-safe, and the session is not, so later changed to the session to do object pool, but only to keep a connection. 2 Cluster

ACTIVEMQ has a powerful and flexible cluster function, but there are still many pitfalls to use. 2.1 Broker cluster and Master-slave

ACTIVEMQ can do the cluster of broker, also can do master-slave way of cluster. The former can fail-over and load-balance before multiple broker, but when a node fails, it can cause message loss, while the latter is able to back up messages and fail-over in real time, but not load-balance. Broker Cluser, messages sent on a broker can be received on other broker. When a broker fails, the client can automatically run to another broker, and multiple broker can provide the service, but the message is stored only on a broker, and if that broker fails, Then the client will not receive the message on the broker until it restarts, and if it is unfortunate that the broker's storage media is broken, the message is lost.
In the Master-slave mode, only master provides the service, slave only real-time backup master data, so the message is not lost. When Master fails, the slave automatically rises to master, and the client automatically turns to slave to work, so it can fail-over. Because only master provides services, you cannot divide the load across multiple broker.
In fact, the performance of individual broker is already quite amazing, in our company's machine can send and receive 4,000 messages per second, no message 4K bytes Such speed, enough for the company's current needs, and the company does not want to lose any data, so we chose to use the Master-slave mode. more than 2.2 kinds of Master-slave mode

Master-slave can also be implemented in a variety of ways. They differ only in the shared data and lock mechanisms. 2.2.1 Pure Master-slave

Pure Master-slave, shows the slave that specifies a broker as another broker in the configuration file. At run time, the slave network automatically replicates data from master and automatically upgrades to master when it loses connection to master. When master fails, slave becomes master, and if you want to get the original master back into operation, you need to stop the running slave (now upgraded to master) and manually copy the data from the slave into master. Restart Master and slave. This method is the simplest, the efficiency is also good, but can only have two units to do the cluster, only fail-over once, and need to stop back master-slave structure. 2.2.2 JDBC Master-slave

This approach does not require a special configuration, as long as all nodes have the data stored in the same database. The node that first gets the lock of the database table becomes master, and once it is invalidated, the other nodes acquire the lock and can become master. Because the data is shared by the database, it is placed in one place and no downtime is required to restore master-slave. In this way, additional database servers are required, and if the database fails, it is completely ineffective and not fast. We are using MySQL test, and did not succeed, Master failed, the other nodes have not been upgraded to slave, may be the problem of database configuration. 2.2.3 Share file Master-slave

This approach is similar to the former, and does not require a special configuration, but only by sharing the file system to share data, the file lock to achieve only one to become master. There are many ways to share a file system, and we tested NFS V4 (V3 bugs, no), ultimately not very satisfying in terms of stability, efficiency, and possibly too slow through the network.

After testing many master-slave patterns, found that the pure way to manage trouble, JDBC way expensive, inefficient, share file mode requires high-performance shared files, have shortcomings. In view of the single activemq is very reliable, and our base platform group is willing to use hardware backup, and ultimately decided not to Master-slave, nor broker cluster, use a single, through hardware redundancy to ensure that data will not be lost, and find another blade to do Lengbei, Replace when the primary server fails.