rocketmq重試機(jī)制。

• producer端推送消息到broker失敗重試：
  有很多種情況會(huì)影響生產(chǎn)端重試發(fā)送消息。
  1，網(wǎng)絡(luò)不可達(dá)造成的重試：如果在生產(chǎn)者發(fā)送消息到broker或者broker向生產(chǎn)者發(fā)送結(jié)果時(shí)，因?yàn)榫W(wǎng)絡(luò)原因，生產(chǎn)者沒有獲取成功響應(yīng)，在這中情況下，生產(chǎn)者會(huì)無(wú)限次重試。
  2，broker存儲(chǔ)過程中出現(xiàn)異常，會(huì)導(dǎo)致生產(chǎn)者重試。

• consumer端消費(fèi)消息失敗重試。
  1，網(wǎng)絡(luò)不可達(dá)，這種情況和生產(chǎn)者一樣，不可達(dá)造成的重試（相當(dāng)于瀏覽器訪問一個(gè)請(qǐng)求沒有返回200響應(yīng)碼，都算網(wǎng)絡(luò)不可達(dá)）會(huì)是無(wú)限次的。
  2，由于業(yè)務(wù)業(yè)務(wù)處理的原因?qū)е庐惓５某霈F(xiàn)，導(dǎo)致給broker的響應(yīng)不是成功的結(jié)果（相當(dāng)于瀏覽器請(qǐng)求返回200，成功結(jié)果，但是業(yè)務(wù)code是非成功的code），這種失敗時(shí)有次數(shù)限時(shí)的重試，每次重試會(huì)延遲發(fā)送消費(fèi)信息，避免短時(shí)間內(nèi)消費(fèi)端沒有解決bug或者服務(wù)沒有啟動(dòng)，所以有個(gè)延遲重試。

rocket的集群模式

1，單機(jī)模式：在測(cè)試環(huán)境的時(shí)候，由于資源的限制，可以選擇單機(jī)，執(zhí)行或者學(xué)習(xí)rocketmq的功能。

2，多master；只有master沒有salve；rocketmq每個(gè)master之間是互不通信，所以，如果某個(gè)mater宕機(jī)，該臺(tái)機(jī)器上的數(shù)據(jù)是無(wú)法被消費(fèi)的，只有等到master重新啟動(dòng)才可以被消費(fèi)端消費(fèi)。如果宕機(jī)的master磁盤有問題，且無(wú)法恢復(fù)，會(huì)導(dǎo)致master的數(shù)據(jù)丟失，即消息丟失。

3，多master多slave；這種模式即每個(gè)master至少會(huì)有slave（master和slave的集群名稱和接單名稱一樣，只是節(jié)點(diǎn)的id不同，而且master的id必須為0，slave的id大于0，可以是一臺(tái)也可以多臺(tái)slave，1，2，3，4，5標(biāo)示不同的slave）。這種方式雖然需要的資源比較多，但是可以保證在master掛掉的時(shí)候，不影響消費(fèi)者的消費(fèi)，可以減小對(duì)消費(fèi)端的影響。master和slave之間是有聯(lián)系的，在配置的時(shí)候，master和slave可以配置不同的數(shù)據(jù)同步模式，可以異步復(fù)制，也可以同步雙寫；異步復(fù)制效率更高，但是如果master掛掉，磁盤損壞的情況下，會(huì)有少量數(shù)據(jù)丟失，但是不會(huì)想多master模式下，master掛掉并且磁盤順壞導(dǎo)致這個(gè)節(jié)點(diǎn)下的所有的數(shù)據(jù)丟失。同步雙寫，是說producer發(fā)送消息的時(shí)候，只有master和slave都保存成功的時(shí)候，才告訴producer發(fā)送成功，這樣即使master掛掉，slave也有完整的數(shù)據(jù)，可以保證消息不丟失，但是效率較異步復(fù)制差，這種情況一般適用于和錢相關(guān)的，不能允許丟消息的情況。

rocketmq的發(fā)布-訂閱

rocketmq支持廣播和發(fā)布-訂閱兩種消息模式。發(fā)布-訂閱模式，嚴(yán)格意義上說必須是先啟動(dòng)consumer端，再啟動(dòng)producer端。如果先啟動(dòng)生產(chǎn)端并生產(chǎn)消息，之后在啟動(dòng)消費(fèi)端，會(huì)有一些意想不到的結(jié)果?？赡軙?huì)導(dǎo)致大量的重復(fù)消費(fèi)的情況。

rocketmq消費(fèi)端冪等性設(shè)計(jì)。

集群模式下，生產(chǎn)端如果消息發(fā)送失敗，生產(chǎn)端會(huì)重試。但是有時(shí)候，生產(chǎn)端發(fā)送消息broker保存成功，但是在向producer反饋的時(shí)候，網(wǎng)絡(luò)異常，導(dǎo)致生產(chǎn)端誤以為失敗。重復(fù)發(fā)送消息?；蛘咴谙M(fèi)端，消費(fèi)成功，但是網(wǎng)絡(luò)原因ack的時(shí)候失敗。導(dǎo)致broker重復(fù)發(fā)送消息到消費(fèi)端?；蛘邉倖?dòng)的consumer，會(huì)消費(fèi)到另一個(gè)consumer正在消費(fèi)，但是還沒有反饋給broker結(jié)果的消息。等等情況都會(huì)導(dǎo)致消費(fèi)端消費(fèi)的重復(fù)的消息。
這個(gè)時(shí)候，為了保證數(shù)據(jù)的一致性，必須在消費(fèi)端要保證消費(fèi)的冪等性。即，如果有重復(fù)的消息，直接反饋上一次消費(fèi)成功的結(jié)果。如果沒有消費(fèi)成功，再繼續(xù)消費(fèi)?？傊?，消息只能被成功消費(fèi)一次。

如何保證rocketmq消費(fèi)的冪等性

在生產(chǎn)端發(fā)送消息的時(shí)候，message可以傳遞key，這個(gè)key必須是全局唯一的（可以是時(shí)間毫秒數(shù)），這樣消費(fèi)端在消費(fèi)的時(shí)候可以看是否有改key的成功消費(fèi)結(jié)果。如果有直接反饋成功結(jié)果給broker，如果沒有繼續(xù)消費(fèi)?；蛘咴谙⒅杏形ㄒ恍缘臉I(yè)務(wù)主鍵，這樣可以使用業(yè)務(wù)主鍵而不使用key來(lái)保證不重復(fù)消費(fèi)。