做程序時(shí)，如果某個(gè)查詢方法應(yīng)當(dāng)返回一條記錄，但是查出來多條，是拋異常好還是從多條中取第一條好？我有10年的開發(fā)和培訓(xùn)經(jīng)驗(yàn)。在此期間，我經(jīng)歷了Java、web、Android、H5、大數(shù)據(jù)、PHP等不同

做程序時(shí)，如果某個(gè)查詢方法應(yīng)當(dāng)返回一條記錄，但是查出來多條，是拋異常好還是從多條中取第一條好？

我有10年的開發(fā)和培訓(xùn)經(jīng)驗(yàn)。在此期間，我經(jīng)歷了Java、web、Android、H5、大數(shù)據(jù)、PHP等不同的發(fā)展方向。我也是軟件培訓(xùn)公司的金牌講師。我對(duì)回答這個(gè)問題很感興趣。

您已經(jīng)清楚地解釋了這個(gè)問題中的要求，“一個(gè)查詢方法應(yīng)該返回一條記錄，但是可以找到多條記錄”！也就是說，您的查詢應(yīng)該只有一個(gè)結(jié)果，但此時(shí)或某個(gè)時(shí)候，會(huì)有多個(gè)結(jié)果，這意味著您的業(yè)務(wù)接口可能不滿足冪等性的要求。根據(jù)冪等設(shè)計(jì)原理，無論怎樣查找，只要參數(shù)相同，返回的結(jié)果應(yīng)該是相同的。

那么如何解決這個(gè)問題并拋出異常呢？返回到幾個(gè)中的第一個(gè)？

我認(rèn)為這不是一個(gè)完美的解決方案。

這對(duì)某些人來說是一個(gè)解決方案，但是問題解決了嗎？一點(diǎn)也不！問題仍然存在。下次觸發(fā)此條件時(shí)，仍將引發(fā)異常。就像說森林里有一只老虎。有一天，它吃人，然后你不解決老虎的問題。你只是在森林里掛了一塊牌子，上面寫著：小心，里面有老虎！這…

事實(shí)上，這不是一個(gè)好辦法。也許只有一件東西應(yīng)該被退回。為什么要查詢多個(gè)項(xiàng)目？您是否檢查了數(shù)據(jù)庫中數(shù)據(jù)的唯一性？你不覺得每次查詢多個(gè)結(jié)果然后得到第一個(gè)數(shù)據(jù)效率很低嗎？

所以我們應(yīng)該從根本上解決問題！為什么會(huì)產(chǎn)生多個(gè)數(shù)據(jù)？如果要手動(dòng)檢查數(shù)據(jù)，則需要手動(dòng)檢查。如果要鎖定它，應(yīng)該盡最大努力確保輸入?yún)?shù)相同，結(jié)果相同

調(diào)用接口出現(xiàn)異常是怎么回事？

這種訂單狀態(tài)轉(zhuǎn)換是互聯(lián)網(wǎng)行業(yè)非常普遍的問題。這里有一些給你的建議。

1. 首先，訂單狀態(tài)的轉(zhuǎn)換不能丟失。在這種情況下，其中99%需要鎖定。您不能完全信任外部調(diào)用順序，也可以引入消息隊(duì)列，鎖定仍然是必要的。無論是使用樂觀鎖還是悲觀鎖，redis分布式鎖還是zookeeper分布式鎖都應(yīng)該與業(yè)務(wù)相結(jié)合。

2. 鎖定會(huì)影響效率，但訂單、付款、銀行流量等，往往在數(shù)據(jù)正確后才能進(jìn)行高效處理。我們需要做的是如何在保證數(shù)據(jù)正確的基礎(chǔ)上提高效率……”接口調(diào)用的數(shù)量仍然很大，許多接口正在等待并發(fā)訪問”。你把鎖調(diào)到需要鎖的地方了嗎。代碼優(yōu)化，將不必要的操作移到鎖外，縮小了鎖代碼的范圍，這是效率的又一提高。

3. 最后，當(dāng)你提到并發(fā)隊(duì)列時(shí)，我不知道你指的是“并發(fā)隊(duì)列”還是“消息隊(duì)列”。不管你的意思是什么，使用這些東西的前提是冪等，解決無序的問題。這基本上涉及到鎖定、狀態(tài)機(jī)和補(bǔ)償機(jī)制。

5. 在大中型分布式系統(tǒng)中，所設(shè)計(jì)的系統(tǒng)和接口應(yīng)防止重復(fù)調(diào)用和無序調(diào)用。