"Section VII Distributed Message Middleware Design" and "Section VIII Activemq" in "Chapter Three [Supplementary Information] Detailed Explanation of Common Message Middleware Applications" in "Special Topic Four Service Transformation"

"3.7.1 Message Middleware Design"

• 13 27 Commonly used protocols for message middleware:
  
  Why not use HTTP protocol? 1. The HTTP format is more complicated and does not need to be; 2. HTTP is a short connection, and MQ is basically a long connection

• 23 points of commonly used persistence methods:
  

• 26 49 Commonly used message middleware distribution strategies:
  

• 29 4 High-availability solutions:
  1) Master-slave sharing:
  
  2) Master-slave synchronization:
  Usually the producer writes to the master; it can be load balanced
  3) Multi-master cluster synchronization
  4) Multi-master cluster forwarding
  5) Combination of master-slave and Broker-cluster:
  

"3.8.1 Getting Started with ActiveMQ"

• JMS corresponds to different MQs and can correspond to different database drivers similar to JDBC:
  
• 4 43 JMS message structure:
  

"3.8.2 Message Protocol Supported by ActiveMQ"

• 12 18 NIO:
  
• 35 10 Automatically discover servers in the form of multicast
• 38 50 MQTT protocol is mostly used in the Internet of Things:
  
• 40 30 Quality of Service (QoS):
  

"3.8.3 Activemq High-Availability Cluster Solution"

• Delay and scheduling messages http://activemq.apache.org/delay-and-schedule-message-delivery.html
  need to be configured in the broker node of activemq.xmlschedulerSupport="true"

• 4 39 Several clustering methods of ActiveMQ:
  

• • The deployment method of Shared filesystem/database Master-Slave is shown in the figure below. What solves is the Broker single point of failure/failover problem, that is, for high availability.
    
• • The Broker-Cluster deployment method is as shown in the figure below. The principle is that Broker can also act as a consumer to read other Broker's messages. It can be deployed by static or multicast. The main purpose is to load balance
    
• • 32 30 The combination of Master-Slave and Broker-Cluster is shown in the figure below. Both high availability and load balancing
    

"3.8.4 Persistence and Transaction Mechanism"

• kahaDb
• 13 35+ transaction mechanism
• 17 45 When the transaction is started on the consumer side, rollback will cause MQ to resend the message, and the number of retransmissions is 6 by default
• 20 35 There is no need to use transactions, and the consumer sets the confirmation mode to manual confirmation by the client: session = conn.createSession(false, Session.CLIENT_ACKNOWLEDGE);it can also be carried out without an acknowledgement

// 消息重发
                            finalSession.recover();

• 21 49 Permanent subscriber: Even if the client is offline, when it connects again, it will get all the messages sent to the topic when it is offline
• 32 points Consumer can filter messages by attributes