JMS Basics See: http://blog.csdn.net/zhangxs_3/article/category/625599 in practiceexisting problems (from "large Web site systems and Java Middleware practices", chapter sixth):
first, how to resolve message delivery consistency1. Message Delivery Consistency definitionMessage delivery consistency means that the business action that generates the message is consistent with the message being sent, that is, if the business operation succeeds, the message generated by the operation must be sent out or the message will be lost. On the other hand, if a business operation does not occur or fails, the message should not be sent out. 2. Message consistency is hard to guarantee?Solution One:The interface of the XA series defined in JMS is for the purpose of implementing distributed transaction support. Disadvantage:> introduces a distributed transaction, which brings some overhead and increases complexity. > For business operations, resources that require business operations must support the XA protocol in order to be able to do distributed transactions with sending messages. However, not all business operations that require a distributed transaction with a Send message support the XA protocol.
Solution Two:
(1) The Business processing application first sends the message to the message middleware, marking the message status as pending. (2) When the message middleware receives the message, it stores the message in the message store and does not post the message to destination (Queue/topic). (3) The message middleware returns the results of the received message processing (only inbound processing) to the business processing application, and the result is a success or failure (4) The business party receives the results returned by the message middleware and processes them:a) If the result received is a failure, then abandon the business process and end.
b) If the result received is successful, then the business itself is operated.
(5) Send business processing results to message middleware after business is completed. (6) The message middleware receives the result of the business processing and processes it according to the result:a) If the business fails, the message in the message store is deleted, ending.
b) If the business succeeds, the message status in the update message store is sent, dispatched, and the message is posted.
The above scheme, how to ensure the consistency of message delivery?? We analyze the anomalies that may occur in each step. Analysis simply depends on whether the business operation and message sending state are the same, that is, success or failure at the same time. (1) The business application sends messages to the message middleware. If this step fails, whether it is the cause of the network or the message middleware, or the business application itself, we will see that the business operation has not been done, the message has not yet been stored in the message middleware, the business operations and message delivery both state consistent, no problem. (2) The message middleware puts the message into storage. If this step fails,whether it's a problem with the message store, or if the message middleware has a problem with a business message, or a network problem, it can result in two results. One is the failure of the message middleware, then the business application will not receive the results returned by the message middleware, and the second is that the message middleware fails to insert the message and has the ability to return the results to the application, when there are no messages in the message store. (3) The business application received the message that the middleware returned the result exception. The cause of this anomaly may be the problem of network, message middleware, or the business application itself. If the business application itself is not a problem, then the business application does not know that the message in the message middleware processing results, will follow the message sent failure to deal with, if the message in the message middleware in the success of the storage, it will cause inconsistencies. If there is a problem with the business application, then if the message is handled successfully in the message middleware, it will be inconsistent, and if it is not successfully processed, it is consistent. (4) Business operations for operational applications. This step will not be too big a problem. (5) The business application sends the result of the business operation to the message middleware. If there is a problem with this step, then the message middleware will not know how to update the status of the message, which may cause inconsistencies. (6) Message middleware Update message status. If there is a problem with this step, it is similar to the result of the previous step. As can be seen from the above analysis, the two main control states and processes that need to be understood are the business application and message middleware.
From the above carding and analysis can be seen, for various anomalies we encountered the status of the following three kinds of:> business operations are not done, the message is not stored. > Business operations are not in progress, messages are stored and status is pending. > Business operation is successful, message is stored and status is pending. In three cases, the first one does not require additional processing because it is consistent in itself, and the second and third need to understand the results of business operations and then handle the messages that have been stored in the message store and that the status is pending. So how do you know the results of business operations? Shows the process.
The message middleware actively asks the business application to obtain the result of the business operation of the message to be processed, and then the business application needs to check the result of the business operation and send the result to the message middleware (the result of the business process has failed, succeeded, waited, wait is a state of the more, the business operation is still in process), The message middleware then updates the message state based on the returned business processing results. It can be said that this is a reverse process of sending messages. The forward process of sending messages together with the reverse flow of the results of business operations solves the problem of consistency between business operations and sending messages.
Two limitations of the program. 1. You need to determine the content of the message being sent. Because we will mark the status as pending before doing business operations, this requires that the message content be determined first, and here is a workaround where the main content-that is, the information that can mark the business operation characteristics-is sent, and then the completion of the business operation after the completion of the state needs to update the full content. This is, however, a requirement to be able to determine some index-nature information before a business operation. 2. There is a need to implement business checks. In order to support the work of the reverse process, the business application must be able to conduct business checks based on the message content sent by the reverse process, to determine whether the state of the business operation that the message points to is complete, pending, or in progress, otherwise the pending status message cannot be processed.
The impact of message model on message receptionIn JMS, there are two models of queue (Point-to-point) and topic (Publish/subscribe), and look at the characteristics of the two models. 1.JMS Queue Model
The characteristics of the model:> application 1 and application 2 send messages to the JMS server, which form a queue according to the order of arrival, Application 3, application 4 for the consumption of messages. Note that application 3 and app 4 receive different messages, that is, in JMS queue mode, if a message in the queue is consumed by one application, then another application connected to the JMS queue is not receiving the message. That is, each message in the JMS queue can be consumed by only one application and then deleted from JMS. > messages sent from the sender are not sure which application will eventually be consumed, but it is clear that only one application will consume the message. The number and order of messages received by Application 3 and app 4 are not fixed. Therefore, the JMS queue model is also a peer to peer (PTP) mode.
2.JMS Topic Model
As you can see from the part that sends the message and the logic inside the JMS topic message Server, the two models are the same, the biggest difference being the receiving part of the message. Inin the JMS topic model, both application 3 and application 4 receiving messages can receive all messages that arrive at topic independently. The JMS topic model is also a pub/sub way.
Processing and limitations of client connections in 3.JMS when using JMS, each connection has a unique ClientID, which is used to mark the uniqueness of the connection, that is, in the description of queue and topic, we are the default one for a receive app that uses only one connection. Now take a look at the multi-connection scenario, as shown in:
As you can see, the application 3 and the JMS server established two connections, and application 4 and JMS established a connection. You can see that the messages received by these three connections are completely different and not duplicated, and the number of message bars received by each connection and the order in which they were received are not fixed.
As you can see, application 3 and JMS server established a connection, and application 4 and JMS established two connections. Two applications have established a total of three connections, each of which receives all messages sent to topic.
4. What kind of message model do we need? Our needs for the model:. Both the message sender and the receiver are clustered. The receiver of the same message may have more than one cluster to handle the message. Different clusters do not interfere with the same message processing. Analysis: For the first requirement, JSM can be directly supported. For demand two and three, that is false with 8 messages and two clusters, each cluster has two machines, then the two clusters of machines need to dispose of 8 messages, can not be omitted and can not be duplicated. As shown,
The JMS we described earlier only provided two models of queue and topic, but the two models used directly in this scenario are problematic. We need to combine these two models to make improvements, to achieve the model that meets our needs. Such as:
Specifically, we can treat the consumption of messages between clusters and clusters as topic models, and each instance of the application within the cluster is treated as a queue model for the consumption of messages. We can introduce Clusterid, use this ID to identify different clusters, and the connection of each application instance within the cluster is also using the same clusterid. When the server is scheduled, the connection is grouped according to the Clusterid, and the message is delivered independently between different clusterid, and the same Clusterid connection is consumed together. This strategy is processed in two levels, combining the features of the queue and topic two models to achieve the goal of multiple different clusters for message subscriptions.
Message Middleware (i) JMS and ACTIVEMQ
