訊息總是從生產者傳送到中介軟體再有中介軟體傳送給消費者。

傳送端特性分析：

producer預設是非同步傳送訊息。在沒有開啟事務的情況下，producer傳送持久化訊息是同步的，呼叫send會阻塞直到broker把訊息儲存到磁碟並返回確認。

訊息設定為持久：

MessageProducer producer = session.createProducer(destination);
producer.setDeliveryMode(DeliveryMode.PERSISTENT);

訊息設定為非持久：

MessageProducer producer = session.createProducer(destination);
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
 

官方提示非同步傳送有三種配置方式：

Configuring Async Send using a Connection URI
You can use the Connection Configuration URI to configure async sends as follows

cf = new ActiveMQConnectionFactory("tcp://locahost:61616?jms.useAsyncSend=true");
Configuring Async Send at the ConnectionFactory Level
You can enable this feature on the ActiveMQConnectionFactory object using the property.

((ActiveMQConnectionFactory)connectionFactory).setUseAsyncSend(true);
Configuring Async Send at the Connection Level
Configuring the dispatchAsync setting at this level overrides the settings at the connection factory level.

You can enable this feature on the ActiveMQConnection object using the property.

((ActiveMQConnection)connection).setUseAsyncSend(true);
 

非同步傳送丟失訊息的場景是：生產者設定UseAsyncSend=true，使用producer.send(msg)持續傳送訊息。由於訊息不阻塞，生產者會認為所有send的訊息均被成功傳送至MQ。如果服務端突然宕機，此時生產者端記憶體中尚未被髮送至MQ的訊息都會丟失。

alwaysSyncSend/useAsyncSend

    用來設定producer(或者session)傳送訊息的方式：同步/非同步。

    alwaysSyncSend表示訊息將總會被同步傳送(request<->response),即訊息通過底層transport連結傳送之後，將會阻塞直到收到broker端的ProducerAck或者sentTimeout。同步傳送，是一種擔保能力強但傳送效率較低的方式，如果訊息傳送失敗，client端可以立即獲得異常。如果alwaysSyncSend值為true，則producer將使用同步傳送所有訊息(同時忽略useAsyncSend選項

    useAsyncSend表示訊息可以被非同步傳送(oneway)，非同步傳送並不是訊息在client快取起來，而是訊息也將立即被transport傳送給broker，只是不會阻塞等待broker的ACK。訊息傳送給broker之後，producer.send方法將會立即返回。非同步傳送，通常配合broker端“Flow Control”手段使用，它可以最大化produer端的傳送效率。我們通常在訊息量比較密集的情況下使用非同步傳送，它可以很大的提升Producer效能；不過這也帶來了額外的問題，就是需要消耗較多的Client端記憶體，同時也會導致broker端效能消耗增加；此外它不能有效的確保訊息的傳送成功。在useAsyncSend的情況下，客戶端需要容忍訊息丟失的可能。

在不考慮事務的情況下：

producer傳送持久化訊息是同步傳送，傳送是阻塞的，直到收到確認。同步傳送肯定是有流量控制的。

producer預設是非同步傳送，非同步傳送不會等待broker的確認， 所以就需要考慮流量控制了：

ActiveMQConnectionFactory.setProducerWindowSize(int producerWindowSize)

ProducerWindowSize的含義：producer每傳送一個訊息，統計一下發送的位元組數，當位元組數達到ProducerWindowSize值時，需要等待broker的確認，才能繼續傳送。

windowSize(非同步傳送)

    視窗尺寸，用來約束在非同步傳送時producer端允許積壓的(尚未ACK)的訊息的尺寸，且只對非同步傳送有意義。每次傳送訊息之後，都將會導致memoryUsage尺寸增加(+message.size)，當broker返回producerAck時，memoryUsage尺寸減少(producerAck.size，此size表示先前傳送訊息的大小)。可以通過如下2種方式設定:

• 在brokerUrl中設定: "tcp://localhost:61616?jms.producerWindowSize=1048576",這種設定將會對所有的producer生效。

• 在destinationUri中設定: "test-queue?producer.windowSize=1048576",此引數只會對使用此Destination例項的producer失效，將會覆蓋brokerUrl中的producerWindowSize值。

     此值越大，意味著消耗Client端的記憶體就越大。

    至此我們已經清楚，任何傳送到broker端的訊息，broker總會在儲存成功後回傳ProducerAck資訊，並且在ACK中包含訊息的size。當producer傳送訊息時，會首先檢測memoryUsage中是否有足夠的空間(根據message.size判斷)，如果空間足夠，則訊息正常傳送；否則將會阻塞，直到收到producerACK且memoryUsage空間釋放足夠多。(注意，對於持久化訊息，只要broker儲存訊息成功即立即傳送ProcuerAck)

sendTimeout

    訊息傳送最大阻塞(等到ACK)時間。這個引數和syncSend方式配合使用，在同步傳送方式中，send方法將會阻塞直到broker反饋ACK，不過這種阻塞的時長無法預期，我們需要使用sendTimeout來設定最大的阻塞時間，如果阻塞超時，將會丟擲RequestTimedOutIOException。此值預設為0，表示永不超時。

• 在brokerUrl中設定

//在brokerUrl中指定,單位:毫秒
jms.sendTimeout=30000

• connection.setSendTimeout(long) 

    此外需要注意，如果指定了sendTimeout值 >0,無論何時，所有的訊息都將同步傳送。(忽略alwaysSyncSend、useAsyncSend、訊息持久化方式等)。如果sendTimeout <0,則效果和=0一致。

    這是一個非常重要而且有效的調優引數之一；它在producer端訊息傳送比較密集時，或者producer傳送速率與consumer消費速度失衡嚴重時，對維護broker例項效能穩定具有重要意義。比如，當producer短時間內大批量傳送訊息，而consumer消費速度相對較低時，會對broker端的儲存造成巨大沖擊，在極端情況下，可能導致OOM或者broker宕機。所以，我們通常開啟此引數，且指定相對合理的值。

    僅僅在producer指定windowSize，可以在Client端避免這些問題，不過這只是一個方面；但是從全域性來看，還不夠全面，我們還需要在broker端使用“Flow Control”策略來避免上述情況的發生。不過對於"持久化"型別的訊息，當broker儲存成功之後，總是立即傳送ack，所以我們不需要擔心會帶來潛在的危險。因為“windowSize”、“Flow Control”通常是針對“非持久化”訊息。

    “Flow Control”通常稱為“流量控制”，它的核心理念就是“按需交付”。如果每個Producer指定的windowSize為64M，但是我們有10個這樣的producer，那麼意味著broker端在最壞的情況下，需要承載640M資料，不過很不幸的是broker上可供cache的空間只有512M，那麼此後broker可能因為記憶體不足而強制掛起Producer的物理連線(connection),從而導致在connection上無法繼續傳送任何訊息。這會引入另外一個問題，當connection上還有當前通道(Queue或者Topic)的consumer時，會帶來死鎖；這導致consumer的ACK無法傳送-->進而導致訊息繼續消費，以致於形成“訊息無法消費”“也無法傳送”的死鎖情況。所以通常情況下，我們不能讓Consumer和Producer共享一個物理Connection。

  “Flow Control”所能做的就是：當broker記憶體不足時，讓producer暫停一下，直到訊息消費之後騰出足夠的空間。可以讓訊息密集傳送時，broker能夠協調Producer傳送的“頻率”，同時確保自己的效能處於可控範圍

參考文獻：