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

做程序時，如果某個查詢方法應當返回一條記錄，但是查出來多條，是拋異常好還是從多條中取第一條好？

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

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

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

我認為這不是一個完美的解決方案。

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

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

所以我們應該從根本上解決問題！為什么會產(chǎn)生多個數(shù)據(jù)？如果要手動檢查數(shù)據(jù)，則需要手動檢查。如果要鎖定它，應該盡最大努力確保輸入?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)用順序，也可以引入消息隊列，鎖定仍然是必要的。無論是使用樂觀鎖還是悲觀鎖，redis分布式鎖還是zookeeper分布式鎖都應該與業(yè)務(wù)相結(jié)合。

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

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

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