投遞狀態(tài)
發(fā)送消息時(shí)，將得到包含SendStatus的SendResult缤削。首先瘦棋，我們假設(shè)消息的isWaitStoreMsgOK = true(默認(rèn)是true)。如果不是鲜棠，我們將總會(huì)得到SEND_OK肌厨，如果沒有拋出異常。下面是關(guān)于每個(gè)狀態(tài)的描述列表:
-
FLUSH_DISK_TIMEOUT
如果 Broker 設(shè)置
MessageStoreConfig的FlushDiskType=SYNC_FLUSH(默認(rèn)是ASYNC_FLUSH)豁陆，并且代理沒有在MessageStoreConfig的syncFlushTimeout(默認(rèn)是5秒)時(shí)間內(nèi)完成刷盤柑爸，您將獲得這個(gè)狀態(tài)。 -
FLUSH_SLAVE_TIMEOUT
如果 Broker 的角色是
SYNC_MASTER(默認(rèn)是ASYNC_MASTER)盒音，并且 Slave Broker 沒有在MessageStoreConfig的syncFlushTimeout(默認(rèn)是5秒)時(shí)間內(nèi)完成同步表鳍，您將得到這個(gè)狀態(tài)馅而。 -
SLAVE_NOT_AVAILABLE
如果代理的角色是
SYNC_MASTER(默認(rèn)是ASYNC_MASTER)，但是沒有配置 Slave Broker 进胯，您將獲得這個(gè)狀態(tài)用爪。 -
SEND_OK
SEND_OK 并不意味著它是可靠的。為了確保沒有信息會(huì)丟失胁镐，應(yīng)啟用 SYNC_MASTER 或 SYNC_FLUSH
重復(fù)或者丟失消息
如果您得到FLUSH_DISK_TIMEOUT偎血、FLUSH_SLAVE_TIMEOUT并且 Broker 恰好在此時(shí)意外宕機(jī)，您會(huì)發(fā)現(xiàn)你的消息丟失盯漂。此時(shí)颇玷，您有兩個(gè)選擇，一個(gè)是不管它就缆，這可能導(dǎo)致這個(gè)消息丟失帖渠；另一個(gè)是重新發(fā)送消息，這可能會(huì)導(dǎo)致消息重復(fù)竭宰。我們經(jīng)常建議重新發(fā)送空郊，然后再消費(fèi)時(shí)使用某個(gè)方法移除重復(fù)的消息。除非你覺得一些信息丟失并不重要切揭。但是請(qǐng)記住狞甚，當(dāng)您得到 SLAVE_NOT_AVAILABLE 狀態(tài)時(shí)，重新發(fā)送是沒有用的廓旬。如果出現(xiàn)這種情況哼审，您應(yīng)該保存場(chǎng)景并通知集群管理
超時(shí)
客戶端發(fā)送請(qǐng)求到 Broker ，并等待響應(yīng)孕豹，但如果最大等待時(shí)間過去了涩盾，沒有返回響應(yīng)，客戶端就會(huì)拋出一個(gè)RemotingTimeoutException励背。默認(rèn)的等待時(shí)間是3秒春霍。您還可以使用 send(msg, timeout) 代替 send(msg) 來傳遞超時(shí)參數(shù)。注意椅野，我們不建議等待時(shí)間過小终畅，因?yàn)?Broker 需要一些時(shí)間來刷新磁盤或與 Slave 進(jìn)行同步。而且竟闪，如果它超過 syncFlushTimeout，那么它的值可能不會(huì)有多大的影響杖狼，因?yàn)樵诔瑫r(shí)之前炼蛤，代理可能會(huì)以FLUSH_SLAVE_TIMEOUT或FLUSH_SLAVE_TIMEOUT返回響應(yīng)。
消息大小
我們建議的消息的大小應(yīng)該不超過 512 K蝶涩。
異步發(fā)送
默認(rèn) send(msg) 將阻塞直到返回的響應(yīng)理朋。所以如果你關(guān)心的是性能絮识，我們建議你使用 send(msg, callback) ，這將會(huì)以異步方式發(fā)送嗽上。
生產(chǎn)者組
正常情況下次舌，生產(chǎn)者組沒有影響。但如果你開啟了事物兽愤，你應(yīng)該注意它彼念。默認(rèn)情況下，您只能在同一個(gè)JVM中只創(chuàng)建同一個(gè)生產(chǎn)者組浅萧，這通常是足夠的逐沙。
線程安全
生產(chǎn)者是線程安全的，您可以在業(yè)務(wù)解決方案中使用它洼畅。
性能
如果您希望在一個(gè)JVM中有多個(gè)生產(chǎn)者進(jìn)行大數(shù)據(jù)處理吩案，我們建議：
- 與一些生產(chǎn)者一起使用異步發(fā)送(3 ~ 5就足夠了)
- 為每個(gè)生產(chǎn)者setInstanceName
