整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
日常編程中，我們經(jīng)常會(huì)遇到數(shù)組去重的問題。今天，我們就來聊聊如何用JavaScript來優(yōu)雅地解決這個(gè)問題。
給定一個(gè)包含重復(fù)元素的數(shù)組，我們希望創(chuàng)建一個(gè)新的數(shù)組，其中只包含原始數(shù)組中的唯一值。例如，如果我們有一個(gè)數(shù)組 [1, 2, 3, 2, 4, 1, 5]，期望的輸出應(yīng)該是 [1, 2, 3, 4, 5]。
我們可以使用最簡單的方法——嵌套循環(huán)來解決這個(gè)問題。遍歷每一個(gè)元素，檢查它是否已經(jīng)存在于新數(shù)組中，如果不存在則添加進(jìn)去。
function removeDuplicates(arr) {
const result=[];
for (let i=0; i < arr.length; i++) {
let isDuplicate=false;
for (let j=0; j < result.length; j++) {
if (arr[i]===result[j]) {
isDuplicate=true;
break;
}
}
if (!isDuplicate) {
result.push(arr[i]);
}
}
return result;
}
const myArray=[1, 2, 3, 2, 4, 1, 5];
const uniqueArray=removeDuplicates(myArray);
console.log(uniqueArray); // 輸出: [1, 2, 3, 4, 5]這個(gè)方法雖然直觀，但當(dāng)數(shù)組很大時(shí)，效率會(huì)變得非常低，因?yàn)闀r(shí)間復(fù)雜度是 O(n2)。
我們還可以使用 indexOf 方法配合 filter 方法來去重，這樣看起來會(huì)簡潔不少。
function removeDuplicates(arr) {
return arr.filter((item, pos)=> arr.indexOf(item)===pos);
}
const myArray=[1, 2, 3, 2, 4, 1, 5];
const uniqueArray=removeDuplicates(myArray);
console.log(uniqueArray); // 輸出: [1, 2, 3, 4, 5]在這個(gè)方法中，我們使用 filter 方法創(chuàng)建了一個(gè)新數(shù)組，只有滿足條件的元素才會(huì)被包含進(jìn)來。條件是當(dāng)前元素的索引應(yīng)該等于該元素在數(shù)組中第一次出現(xiàn)的位置。這種方法代碼看起來更簡潔，但是它的時(shí)間復(fù)雜度依然是 O(n2)，因?yàn)?indexOf 需要遍歷整個(gè)數(shù)組來查找元素的位置。
使用對(duì)象特性優(yōu)化
在處理大數(shù)組去重時(shí)，我們可以利用對(duì)象的特性來提升性能。通過在對(duì)象中記錄數(shù)組元素，可以有效減少重復(fù)元素的檢查次數(shù)。
function removeDuplicates(arr) {
const seen={};
return arr.filter((item)=> {
if (seen[item]) {
return false;
} else {
seen[item]=true;
return true;
}
});
}
const myArray=[1, 2, 3, 2, 4, 1, 5];
const uniqueArray=removeDuplicates(myArray);
console.log(uniqueArray); // 輸出: [1, 2, 3, 4, 5]這個(gè)方法創(chuàng)建了一個(gè)空對(duì)象 seen，然后通過 filter 方法遍歷數(shù)組。每個(gè)元素都會(huì)檢查是否已存在于 seen 對(duì)象中。如果存在，則跳過；否則，加入 seen 對(duì)象并保留在新數(shù)組中。這種方法對(duì)于大數(shù)組更高效，但存在一些缺點(diǎn)：
如果你的數(shù)組只包含基本類型，并且不需要區(qū)分類型，這可以放心使用這個(gè)方法。
結(jié)合對(duì)象和數(shù)組的線性搜索
我們可以結(jié)合對(duì)象和數(shù)組的線性搜索方法來解決上述問題。
function removeDuplicates(arr) {
const prims={ boolean: {}, number: {}, string: {} };
const objs=[];
return arr.filter((item)=> {
const type=typeof item;
if (type in prims) {
if (prims[type].hasOwnProperty(item)) {
return false;
} else {
prims[type][item]=true;
return true;
}
} else {
if (objs.indexOf(item) >=0) {
return false;
} else {
objs.push(item);
return true;
}
}
});
}
const myArray=[1, 2, 3, 2, 4, 1, 5, { foo: 1 }, { foo: 2 }];
const uniqueArray=removeDuplicates(myArray);
console.log(uniqueArray); // 輸出: [1, 2, 3, 4, 5, { foo: 1 }, { foo: 2 }]主要優(yōu)點(diǎn)
存在的問題
最終方案：編寫深度比較函數(shù)
編寫深度比較函數(shù) isDeepDataStructureEquality，用來比較兩個(gè)對(duì)象的內(nèi)容是否相同。
function isDeepDataStructureEquality(a, b) {
let isEqual=Object.is(a, b);
if (!isEqual) {
if (Array.isArray(a) && Array.isArray(b)) {
isEqual=(a.length===b.length) && a.every(
(item, idx)=> isDeepDataStructureEquality(item, b[idx])
);
} else if (
a && b
&& (typeof a==='object')
&& (typeof b==='object')
) {
const aKeys=Object.keys(a);
const bKeys=Object.keys(b);
isEqual=(aKeys.length===bKeys.length) && aKeys.every(
(key, idx)=> isDeepDataStructureEquality(a[key], b[key])
);
}
}
return isEqual;
}
function removeDuplicates(arr) {
const primitives={ boolean: {}, number: {}, string: {} };
const objs=[];
return arr.filter(item=> {
const type=typeof item;
if (type in primitives) {
if (primitives[type].hasOwnProperty(item)) {
return false;
} else {
primitives[type][item]=true;
return true;
}
} else {
if (objs.some(obj=> isDeepDataStructureEquality(obj, item))) {
return false;
} else {
objs.push(item);
return true;
}
}
});
}另一種去重方法是先排序數(shù)組，然后去除連續(xù)重復(fù)的元素。
function removeDuplicates(arr) {
return arr.sort().filter((item, pos, ary)=> !pos || item !==ary[pos - 1]);
}
const myArray=[1, 2, 3, 2, 4, 1, 5];
const uniqueArray=removeDuplicates(myArray);
console.log(uniqueArray); // 輸出: [1, 2, 3, 4, 5]這個(gè)方法首先使用 sort 方法對(duì)數(shù)組進(jìn)行排序，然后使用 filter 方法去除連續(xù)的重復(fù)元素。雖然對(duì)已排序的數(shù)組很有效，但無法處理對(duì)象數(shù)組。
對(duì)于包含對(duì)象的數(shù)組，我們可以利用 Set 數(shù)據(jù)結(jié)構(gòu)來高效去重。因?yàn)?Set 只存儲(chǔ)唯一值，我們可以將數(shù)組轉(zhuǎn)換為 Set，然后再轉(zhuǎn)換回?cái)?shù)組。
function removeDuplicates(arr) {
return [...new Set(arr)];
}
const myArray=[1, 2, 3, 2, 4, 1, 5, { foo: 1 }, { foo: 2 }];
const uniqueArray=removeDuplicates(myArray);
console.log(uniqueArray); // 輸出: [1, 2, 3, 4, 5, { foo: 1 }, { foo: 2 }]這個(gè)方法通過 new Set(arr) 創(chuàng)建一個(gè)新的集合，然后使用擴(kuò)展運(yùn)算符 ... 將集合展開為數(shù)組，去重過程簡單且高效。
在實(shí)際開發(fā)中，選擇合適的數(shù)組去重方法非常重要。如果數(shù)組主要包含基本類型，使用 Set 是一種簡潔高效的選擇。如果數(shù)組中包含復(fù)雜結(jié)構(gòu)的對(duì)象，可以結(jié)合深度比較函數(shù)來確保去重的準(zhǔn)確性。
無論你選擇哪種方法，都要根據(jù)具體的應(yīng)用場(chǎng)景和數(shù)據(jù)特點(diǎn)來決定。希望這些方法能幫助你在實(shí)際開發(fā)中更優(yōu)雅地解決數(shù)組去重問題。如果你有其他更好的方法或建議，歡迎在評(píng)論區(qū)分享哦！
如果你喜歡這篇文章，請(qǐng)點(diǎn)贊并關(guān)注，更多前端技巧和小妙招等著你哦！
各大公司面試中，我們經(jīng)常會(huì)被問到數(shù)組去重算法，這也是一道非常經(jīng)典的面試題，一般考官會(huì)讓你用自己擅長的語言，不管是C，C++，Java，PHP，Javascript都可以。今天我們就來看看，如何利用Javascript來完成數(shù)組去重算法。
Javascript的logo
遍歷數(shù)組算法
核心思想：在函數(shù)內(nèi)部新建一個(gè)數(shù)組，然后對(duì)傳入的數(shù)組進(jìn)行遍歷，值不在新數(shù)組中就添加進(jìn)去，如果存在就不添加。注意：本算法采用了ES5的indexOf方法，但是因?yàn)樵贗E8以下版本的瀏覽器中還不支持，因此需要寫一個(gè)polyfill，算法代碼如下所示
遍歷數(shù)組法
對(duì)象鍵值對(duì)方法
核心思想：新建一個(gè)JS對(duì)象以及一個(gè)新的數(shù)組，對(duì)傳入的數(shù)組進(jìn)行遍歷，判斷值是否為JS對(duì)象的鍵，如果不是，則給該JS對(duì)象插入該鍵，同時(shí)插入新的數(shù)組。該算法執(zhí)行速度最快，但是由于新建了額外的對(duì)象與數(shù)組，會(huì)占用比較的空間。算法代碼如下：
數(shù)組鍵值對(duì)方法
先排序，再去重
核心思想：首先借用原生sort方法進(jìn)行排序，然后對(duì)排序后的新數(shù)組進(jìn)行相鄰元素去重，代碼如下
先排序，再去重
優(yōu)先遍歷數(shù)組法
核心思想：雙層循環(huán)，找出最右邊的沒有重復(fù)的值加入新的數(shù)組中
優(yōu)先遍歷數(shù)組
運(yùn)行結(jié)果
運(yùn)行幾個(gè)方法的代碼如下
運(yùn)行方法
在chrome瀏覽器中運(yùn)行后，結(jié)果如下圖所示，
運(yùn)行結(jié)果
總結(jié)
今天我們講解了下Javascript中比較經(jīng)典的數(shù)組去重算法，希望能對(duì)大家有所幫助
如果喜歡的話，記得關(guān)注小編噢，小編后續(xù)會(huì)堅(jiān)持出更多技術(shù)性的文章，如果有任何問題，也歡迎提問，小編都會(huì)盡力解答的。
消息中間件是分布式系統(tǒng)常用的組件，無論是異步化、解耦、削峰等都有廣泛的應(yīng)用價(jià)值。我們通常會(huì)認(rèn)為，消息中間件是一個(gè)可靠的組件——這里所謂的可靠是指，只要我把消息成功投遞到了消息中間件，消息就不會(huì)丟失，即消息肯定會(huì)至少保證消息能被消費(fèi)者成功消費(fèi)一次，這是消息中間件最基本的特性之一，也就是我們常說的“AT LEAST ONCE”，即消息至少會(huì)被“成功消費(fèi)一遍”。
舉個(gè)例子，一個(gè)消息M發(fā)送到了消息中間件，消息投遞到了消費(fèi)程序A，A接受到了消息，然后進(jìn)行消費(fèi)，但在消費(fèi)到一半的時(shí)候程序重啟了，這時(shí)候這個(gè)消息并沒有標(biāo)記為消費(fèi)成功，這個(gè)消息還會(huì)繼續(xù)投遞給這個(gè)消費(fèi)者，直到其消費(fèi)成功了，消息中間件才會(huì)停止投遞。
然而這種可靠的特性導(dǎo)致，消息可能被多次地投遞。舉個(gè)例子，還是剛剛這個(gè)例子，程序A接受到這個(gè)消息M并完成消費(fèi)邏輯之后，正想通知消息中間件“我已經(jīng)消費(fèi)成功了”的時(shí)候，程序就重啟了，那么對(duì)于消息中間件來說，這個(gè)消息并沒有成功消費(fèi)過，所以他還會(huì)繼續(xù)投遞。這時(shí)候?qū)τ趹?yīng)用程序A來說，看起來就是這個(gè)消息明明消費(fèi)成功了，但是消息中間件還在重復(fù)投遞。
這在RockectMQ的場(chǎng)景來看，就是同一個(gè)messageId的消息重復(fù)投遞下來了。
基于消息的投遞可靠（消息不丟）是優(yōu)先級(jí)更高的，所以消息不重的任務(wù)就會(huì)轉(zhuǎn)移到應(yīng)用程序自我實(shí)現(xiàn)，這也是為什么RocketMQ的文檔里強(qiáng)調(diào)的，消費(fèi)邏輯需要自我實(shí)現(xiàn)冪等。背后的邏輯其實(shí)就是：不丟和不重是矛盾的（在分布式場(chǎng)景下），但消息重復(fù)是有解決方案的，而消息丟失是很麻煩的。
例如：假設(shè)我們業(yè)務(wù)的消息消費(fèi)邏輯是：插入某張訂單表的數(shù)據(jù)，然后更新庫存：
insert into t_order values .....
update t_inv set count=count-1 where good_id='good123';
要實(shí)現(xiàn)消息的冪等，我們可能會(huì)采取這樣的方案：
select * from t_order where order_no='order123'
if(order !=null) {
return ;//消息重復(fù)，直接返回
}
這對(duì)于很多情況下，的確能起到不錯(cuò)的效果，但是在并發(fā)場(chǎng)景下，還是會(huì)有問題。
假設(shè)這個(gè)消費(fèi)的所有代碼加起來需要1秒，有重復(fù)的消息在這1秒內(nèi)（假設(shè)100毫秒）內(nèi)到達(dá)（例如生產(chǎn)者快速重發(fā)，Broker重啟等），那么很可能，上面去重代碼里面會(huì)發(fā)現(xiàn)，數(shù)據(jù)依然是空的（因?yàn)樯弦粭l消息還沒消費(fèi)完，還沒成功更新訂單狀態(tài)），
那么就會(huì)穿透掉檢查的擋板，最后導(dǎo)致重復(fù)的消息消費(fèi)邏輯進(jìn)入到非冪等安全的業(yè)務(wù)代碼中，從而引發(fā)重復(fù)消費(fèi)的問題（如主鍵沖突拋出異常、庫存被重復(fù)扣減而沒釋放等）
要解決上面并發(fā)場(chǎng)景下的消息冪等問題，一個(gè)可取的方案是開啟事務(wù)把select 改成 select for update語句，把記錄進(jìn)行鎖定。
select * from t_order where order_no='THIS_ORDER_NO' for update //開啟事務(wù)
if(order.status !=null) {
return ;//消息重復(fù)，直接返回
}
但這樣消費(fèi)的邏輯會(huì)因?yàn)橐肓耸聞?wù)包裹而導(dǎo)致整個(gè)消息消費(fèi)可能變長，并發(fā)度下降。
當(dāng)然還有其他更高級(jí)的解決方案，例如更新訂單狀態(tài)采取樂觀鎖，更新失敗則消息重新消費(fèi)之類的。但這需要針對(duì)具體業(yè)務(wù)場(chǎng)景做更復(fù)雜和細(xì)致的代碼開發(fā)、庫表設(shè)計(jì)，不在本文討論的范圍。
但無論是select for update， 還是樂觀鎖這種解決方案，實(shí)際上都是基于業(yè)務(wù)表本身做去重，這無疑增加了業(yè)務(wù)開發(fā)的復(fù)雜度， 一個(gè)業(yè)務(wù)系統(tǒng)里面很大部分的請(qǐng)求處理都是依賴MQ的，如果每個(gè)消費(fèi)邏輯本身都需要基于業(yè)務(wù)本身而做去重/冪等的開發(fā)的話，這是繁瑣的工作量。本文希望探索出一個(gè)通用的消息冪等處理的方法，從而抽象出一定的工具類用以適用各個(gè)業(yè)務(wù)場(chǎng)景。
在消息中間件里，有一個(gè)投遞語義的概念，而這個(gè)語義里有一個(gè)叫”Exactly Once”，即消息肯定會(huì)被成功消費(fèi)，并且只會(huì)被消費(fèi)一次。以下是阿里云里對(duì)Exactly Once的解釋：
Exactly-Once 是指發(fā)送到消息系統(tǒng)的消息只能被消費(fèi)端處理且僅處理一次，即使生產(chǎn)端重試消息發(fā)送導(dǎo)致某消息重復(fù)投遞，該消息在消費(fèi)端也只被消費(fèi)一次。
在我們業(yè)務(wù)消息冪等處理的領(lǐng)域內(nèi)，可以認(rèn)為業(yè)務(wù)消息的代碼肯定會(huì)被執(zhí)行，并且只被執(zhí)行一次，那么我們可以認(rèn)為是Exactly Once。
但這在分布式的場(chǎng)景下想找一個(gè)通用的方案幾乎是不可能的。不過如果是針對(duì)基于數(shù)據(jù)庫事務(wù)的消費(fèi)邏輯，實(shí)際上是可行的。
假設(shè)我們業(yè)務(wù)的消息消費(fèi)邏輯是：更新MySQL數(shù)據(jù)庫的某張訂單表的狀態(tài)：
update t_order set status='SUCCESS' where order_no='order123';
要實(shí)現(xiàn)Exaclty Once即這個(gè)消息只被消費(fèi)一次（并且肯定要保證能消費(fèi)一次），我們可以這樣做：在這個(gè)數(shù)據(jù)庫中增加一個(gè)消息消費(fèi)記錄表，把消息插入到這個(gè)表，并且把原來的訂單更新和這個(gè)插入的動(dòng)作放到同一個(gè)事務(wù)中一起提交，就能保證消息只會(huì)被消費(fèi)一遍了。
說明：
事實(shí)上，阿里云ONS的EXACTLY-ONCE語義的實(shí)現(xiàn)上，就是類似這個(gè)方案基于數(shù)據(jù)庫的事務(wù)特性實(shí)現(xiàn)的。更多詳情可參考：https://help.aliyun.com/document_detail/102777.html
基于這種方式，的確這是有能力拓展到不同的應(yīng)用場(chǎng)景，因?yàn)樗膶?shí)現(xiàn)方案與具體業(yè)務(wù)本身無關(guān)——而是依賴一個(gè)消息表。
但是這里有它的局限性
注：業(yè)務(wù)上，消息表的設(shè)計(jì)不應(yīng)該以消息ID作為標(biāo)識(shí)，而應(yīng)該以業(yè)務(wù)的業(yè)務(wù)主鍵作為標(biāo)識(shí)更為合理，以應(yīng)對(duì)生產(chǎn)者的重發(fā)。阿里云上的消息去重只是RocketMQ的messageId，在生產(chǎn)者因?yàn)槟承┰蚴謩?dòng)重發(fā)（例如上游針對(duì)一個(gè)交易重復(fù)請(qǐng)求了）的場(chǎng)景下起不到去重/冪等的效果（因消息id不同）。
如上所述，這種方式Exactly Once語義的實(shí)現(xiàn)，實(shí)際上有很多局限性，這種局限性使得這個(gè)方案基本不具備廣泛應(yīng)用的價(jià)值。并且由于基于事務(wù)，可能導(dǎo)致鎖表時(shí)間過長等性能問題。
例如我們以一個(gè)比較常見的一個(gè)訂單申請(qǐng)的消息來舉例，可能有以下幾步（以下統(tǒng)稱為步驟X）：
這種情況下，我們?nèi)绻扇∠⒈?本地事務(wù)的實(shí)現(xiàn)方式，消息消費(fèi)過程中很多子過程是不支持回滾的，也就是說就算我們加了事務(wù)，實(shí)際上這背后的操作并不是原子性的。怎么說呢，就是說有可能第一條小在經(jīng)歷了第二步鎖庫存的時(shí)候，服務(wù)重啟了，這時(shí)候?qū)嶋H上庫存是已經(jīng)在另外的服務(wù)里被鎖定了，這并不能被回滾。當(dāng)然消息還會(huì)再次投遞下來，要保證消息能至少消費(fèi)一遍，換句話說，鎖庫存的這個(gè)RPC接口本身依舊要支持“冪等”。
再者，如果在這個(gè)比較耗時(shí)的長鏈條場(chǎng)景下加入事務(wù)的包裹，將大大的降低系統(tǒng)的并發(fā)。所以通常情況下，我們處理這種場(chǎng)景的消息去重的方法還是會(huì)使用一開始說的業(yè)務(wù)自己實(shí)現(xiàn)去重邏輯的方式，如前面加select for update，或者使用樂觀鎖。
那我們有沒有方法抽取出一個(gè)公共的解決方案，能兼顧去重、通用、高性能呢？
其中一個(gè)思路是把上面的幾步，拆解成幾個(gè)不同的子消息，例如：
注：上述步驟需要保證本地事務(wù)和消息是一個(gè)事務(wù)的（至少是最終一致性的），這其中涉及到分布式事務(wù)消息相關(guān)的話題，不在本文論述。
可以看到這樣的處理方法會(huì)使得每一步的操作都比較原子，而原子則意味著是小事務(wù)，小事務(wù)則意味著使用消息表+事務(wù)的方案顯得可行。
然而，這太復(fù)雜了！這把一個(gè)本來連續(xù)的代碼邏輯割裂成多個(gè)系統(tǒng)多次消息交互！那還不如業(yè)務(wù)代碼層面上加鎖實(shí)現(xiàn)呢。
上面消息表+本地事務(wù)的方案之所以有其局限性和并發(fā)的短板，究其根本是因?yàn)樗蕾囉陉P(guān)系型數(shù)據(jù)庫的事務(wù)，且必須要把事務(wù)包裹于整個(gè)消息消費(fèi)的環(huán)節(jié)。
如果我們能不依賴事務(wù)而實(shí)現(xiàn)消息的去重，那么方案就能推廣到更復(fù)雜的場(chǎng)景例如：RPC、跨庫等。
例如，我們依舊使用消息表，但是不依賴事務(wù)，而是針對(duì)消息表增加消費(fèi)狀態(tài)，是否可以解決問題呢？
以上是去事務(wù)化后的消息冪等方案的流程，可以看到，此方案是無事務(wù)的，而是針對(duì)消息表本身做了狀態(tài)的區(qū)分：消費(fèi)中、消費(fèi)完成。只有消費(fèi)完成的消息才會(huì)被冪等處理掉。而對(duì)于已有消費(fèi)中的消息，后面重復(fù)的消息會(huì)觸發(fā)延遲消費(fèi)（在RocketMQ的場(chǎng)景下即發(fā)送到RETRY TOPIC），之所以觸發(fā)延遲消費(fèi)是為了控制并發(fā)場(chǎng)景下，第二條消息在第一條消息沒完成的過程中，去控制消息不丟（如果直接冪等，那么會(huì)丟失消息（同一個(gè)消息id的話），因?yàn)樯弦粭l消息如果沒有消費(fèi)完成的時(shí)候，第二條消息你已經(jīng)告訴broker成功了，那么第一條消息這時(shí)候失敗broker也不會(huì)重新投遞了）
上面的流程不再細(xì)說，后文有g(shù)ithub源碼的地址，讀者可以參考源碼的實(shí)現(xiàn)，這里我們回頭看看我們一開始想解決的問題是否解決了：
關(guān)于第一個(gè)問題已經(jīng)很明顯已經(jīng)解決了，在此就不討論了。
關(guān)于第二個(gè)問題是如何解決的？主要是依靠插入消息表的這個(gè)動(dòng)作做控制的，假設(shè)我們用MySQL作為消息表的存儲(chǔ)媒介（設(shè)置消息的唯一ID為主鍵），那么插入的動(dòng)作只有一條消息會(huì)成功，后面的消息插入會(huì)由于主鍵沖突而失敗，走向延遲消費(fèi)的分支，然后后面延遲消費(fèi)的時(shí)候就會(huì)變成上面第一個(gè)場(chǎng)景的問題。
關(guān)于第三個(gè)問題，只要我們?cè)O(shè)計(jì)去重的消息鍵讓其支持業(yè)務(wù)的主鍵（例如訂單號(hào)、請(qǐng)求流水號(hào)等），而不僅僅是messageId即可。所以也不是問題。
如果細(xì)心的讀者可能會(huì)發(fā)現(xiàn)這里實(shí)際上是有邏輯漏洞的，問題出在上面聊到的個(gè)三問題中的第2個(gè)問題（并發(fā)場(chǎng)景），在并發(fā)場(chǎng)景下我們依賴于消息狀態(tài)是做并發(fā)控制使得第2條消息重復(fù)的消息會(huì)不斷延遲消費(fèi)（重試）。但如果這時(shí)候第1條消息也由于一些異常原因（例如機(jī)器重啟了、外部異常導(dǎo)致消費(fèi)失敗）沒有成功消費(fèi)成功呢？也就是說這時(shí)候延遲消費(fèi)實(shí)際上每次下來看到的都是消費(fèi)中的狀態(tài)，最后消費(fèi)就會(huì)被視為消費(fèi)失敗而被投遞到死信Topic中（RocketMQ默認(rèn)可以重復(fù)消費(fèi)16次）。
有這種顧慮是正確的！對(duì)于此，我們解決的方法是，插入的消息表必須要帶一個(gè)最長消費(fèi)過期時(shí)間，例如10分鐘，意思是如果一個(gè)消息處于消費(fèi)中超過10分鐘，就需要從消息表中刪除（需要程序自行實(shí)現(xiàn)）。所以最后這個(gè)消息的流程會(huì)是這樣的：
我們這個(gè)方案實(shí)際上沒有事務(wù)的，只需要一個(gè)存儲(chǔ)的中心媒介，那么自然我們可以選擇更靈活的存儲(chǔ)媒介，例如Redis。使用Redis有兩個(gè)好處：
當(dāng)然Redis存儲(chǔ)的數(shù)據(jù)可靠性、一致性等方面是不如MySQL的，需要用戶自己取舍。
以上方案針對(duì)RocketMQ的Java實(shí)現(xiàn)已經(jīng)開源放到Github中，具體的使用文檔可以參考https://github.com/Jaskey/RocketMQDedupListener ，
以下僅貼一個(gè)Readme中利用Redis去重的使用樣例，用以意業(yè)務(wù)中如果使用此工具加入消息去重冪等的是多么簡單：
//利用Redis做冪等表
DefaultMQPushConsumer consumer=new DefaultMQPushConsumer("TEST-APP1");
consumer.subscribe("TEST-TOPIC", "*");
String appName=consumer.getConsumerGroup();// 大部分情況下可直接使用consumer group名
StringRedisTemplate stringRedisTemplate=null;// 這里省略獲取StringRedisTemplate的過程
DedupConfig dedupConfig=DedupConfig.enableDedupConsumeConfig(appName, stringRedisTemplate);
DedupConcurrentListener messageListener=new SampleListener(dedupConfig);
consumer.registerMessageListener(messageListener);
consumer.start();
以上代碼大部分是原始RocketMQ的必須代碼，唯一需要修改的僅僅是創(chuàng)建一個(gè)DedupConcurrentListener示例，在這個(gè)示例中指明你的消費(fèi)邏輯和去重的業(yè)務(wù)鍵（默認(rèn)是messageId）。
更多使用詳情請(qǐng)參考Github上的說明。
實(shí)現(xiàn)到這里，似乎方案挺完美的，所有的消息都能快速的接入去重，且與具體業(yè)務(wù)實(shí)現(xiàn)也完全解耦。那么這樣是否就完美的完成去重的所有任務(wù)呢？
很可惜，其實(shí)不是的。原因很簡單：因?yàn)橐ＷC消息至少被成功消費(fèi)一遍，那么消息就有機(jī)會(huì)消費(fèi)到一半的時(shí)候失敗觸發(fā)消息重試的可能。還是以上面的訂單流程X：
檢查庫存（RPC）
鎖庫存（RPC）
開啟事務(wù)，插入訂單表（MySQL）
調(diào)用某些其他下游服務(wù)（RPC）
更新訂單狀態(tài)
commit 事務(wù)（MySQL）
當(dāng)消息消費(fèi)到步驟3的時(shí)候，我們假設(shè)MySQL異常導(dǎo)致失敗了，觸發(fā)消息重試。因?yàn)樵谥卦嚽拔覀儠?huì)刪除冪等表的記錄，所以消息重試的時(shí)候就會(huì)重新進(jìn)入消費(fèi)代碼，那么步驟1和步驟2就會(huì)重新再執(zhí)行一遍。如果步驟2本身不是冪等的，那么這個(gè)業(yè)務(wù)消息消費(fèi)依舊沒有做好完整的冪等處理。
那么既然這個(gè)并不能完整的完成消息冪等，還有什么價(jià)值呢？價(jià)值可就大了！雖然這不是解決消息冪等的銀彈（事實(shí)上，軟件工程領(lǐng)域里基本沒有銀彈），但是他能以便捷的手段解決：
1.各種由于Broker、負(fù)載均衡等原因?qū)е碌南⒅赝哆f的重復(fù)問題
2.各種上游生產(chǎn)者導(dǎo)致的業(yè)務(wù)級(jí)別消息重復(fù)問題
3.重復(fù)消息并發(fā)消費(fèi)的控制窗口問題，就算重復(fù)，重復(fù)也不可能同一時(shí)間進(jìn)入消費(fèi)邏輯
也就是說，使用這個(gè)方法能保證正常的消費(fèi)邏輯場(chǎng)景下（無異常，無異常退出），消息的冪等工作全部都能解決，無論是業(yè)務(wù)重復(fù)，還是rocketmq特性帶來的重復(fù)。
事實(shí)上，這已經(jīng)能解決99%的消息重復(fù)問題了，畢竟異常的場(chǎng)景肯定是少數(shù)的。那么如果希望異常場(chǎng)景下也能處理好冪等的問題，可以做以下工作降低問題率：
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
