mysql查詢表里的重復數(shù)據(jù)方法？MySQL里去查詢表里的反復重復數(shù)據(jù)記錄：先欄里點再重復一遍的原始數(shù)據(jù)：如何設計每秒十萬查詢的高并發(fā)架構？簡單重新回顧看看，整個架構右側部分自然演進到的那個程度，總之

mysql查詢表里的重復數(shù)據(jù)方法？

MySQL里去查詢表里的反復重復數(shù)據(jù)記錄：

先欄里點再重復一遍的原始數(shù)據(jù)：

如何設計每秒十萬查詢的高并發(fā)架構？

簡單重新回顧看看，整個架構右側部分自然演進到的那個程度，總之早就太的比較好了，因為百億流量，一秒內十萬級并發(fā)中寫入的場景，可以使用MQ限流控制削峰、分布式系統(tǒng)KV集群給抗住了。緊接著可以使用了可以計算與存儲只是分離的架構，每個Slave算出節(jié)點會共同負責提純數(shù)據(jù)到內存中，實現(xiàn)自研的SQL內存可以計算引擎成功可以計算。另外采用了數(shù)據(jù)動靜分離的架構，靜態(tài)數(shù)據(jù)全部緩存，閃圖數(shù)據(jù)自動啟動再提取，保證了盡很可能把網(wǎng)絡幫忙開銷減低到最少。

另，實際自研的分布式系統(tǒng)架構，以及數(shù)據(jù)分片和計算任務分布式執(zhí)行、韌度資源調度、分布式高容錯機制、主備自動切換機制，都能能保證整套系統(tǒng)的不可以按需快速擴容，高性能、高可用的的運行。

下一步怎么辦，咱們得來研究什么研究架構里左側的部分了。

二、日趨膨脹的離線計算結果

其實大家會盡量到，在左側另外一個MySQL，那個MySQL就是用處支撐起實時計算結果和離線模式可以計算結果放進里面信息匯總的。

終端的商家用戶就可以不隨手的查詢MySQL里的數(shù)據(jù)分析結果，勉力支撐自己的決策，他可以不看當天的數(shù)據(jù)分析報告，也可以不看歷史上任何一段時期內的數(shù)據(jù)分析報告。

可是那個MySQL在早期很有可能而且有一些，只不過當然貯放在這個MySQL里的數(shù)據(jù)量相對于要小一點，雖說是計算后的一些結果罷了。但到了中后期，這個MySQL不過也危機重重了。

給大家舉一個例子，不聯(lián)網(wǎng)計算鏈路里，如果不是每天增量數(shù)據(jù)是1000萬，這樣每天晚上換算完以后的結果大概僅有50萬，每天晚上50萬新增加數(shù)據(jù)放入后MySQL，總之我還是這個可以接受的。

可是如果每天晚上增量數(shù)據(jù)是10億，那你早上計算完以后的結果大概會是千萬級，你也可以算他是算出結果有5000萬條數(shù)據(jù)吧，每天晚上5000萬增量數(shù)據(jù)寫入到左側的MySQL中，你都覺得是啥感覺？

可以不給大家說說系統(tǒng)當時的情況，大部分那就是，單臺MySQL服務器的磁盤存儲空間馬上現(xiàn)在就要距離滿掉，但單表數(shù)據(jù)量大都幾億、甚至于十億的級別。

這種量級的單表數(shù)據(jù)量，你覺得用戶去查詢數(shù)據(jù)分析報告的時候，可以體驗能好么？基本都當時三次去查詢都是幾秒鐘的級別。很慢。

倒也罷了，會出現(xiàn)過用戶一次查詢要十秒的級別，哪怕幾十秒，上分鐘的級別。很混亂，用戶體驗非常差，遠遠的達不到免費的產品的級別。

所以我?guī)兔鉀Q了右側的存儲和計算的問題之后，左側的網(wǎng)上查詢的問題也迫在眉睫。新一輪的重構，勢在必行！

三、分庫分表讀寫分離

首先是新瓶裝舊酒，分庫分表讀寫分離，這個都差不多是基于MySQL的架構中，必經(jīng)之路了，不過可以實行站了起來難度并非特別的高，并且速度較快，效果都很特別顯著。

整個的思路和之前第一篇文章（《大型系統(tǒng)架構演進之如何支撐百億級數(shù)據(jù)的存儲與計算》）講的基本是一致。

說白了，那就是分庫后，每臺主庫是可以承載部分寫入到壓力，單庫的寫并發(fā)會降低；其次是單個主庫的磁盤空間也可以減少負載的數(shù)據(jù)量，不當然了迅速就滿了；

而分表之后，單個數(shù)據(jù)表的數(shù)據(jù)量這個可以減低到百萬級別，這個是抵擋海量數(shù)據(jù)和能保證更高性能的最佳實踐，基本是兩三百萬的單表數(shù)據(jù)量級我還是比較合理的。

然后讀寫分離之后，就這個可以將單庫的讀寫負載壓力分離的過程到主庫和從庫多臺機器上去，主庫就喚起寫負載，從庫就容納讀負載端，這樣的話盡量減少單庫原先機器的讀寫負載過熱，可能導致CPU負載、IO電流值、網(wǎng)絡負載過低，結果搞得數(shù)據(jù)庫機器宕機。

簡單的方法這么說全面重構看看數(shù)據(jù)庫層面的架構之后，效果就好的多了。而且單表數(shù)據(jù)量會降低了，那你用戶網(wǎng)站查詢的性能能夠得到很大的提升，基本可以不提升到1秒以內的效果。

四、一秒內10萬網(wǎng)站查詢的高并發(fā)挑戰(zhàn)

上面那套正式的分庫分表讀寫分離的架構確實抵擋了一段時間，但是漸漸地的那套架構又不暴漏不出來了弊端出來了，是因為商家用戶是開了數(shù)據(jù)分析頁面之后，頁面上有js腳本會每隔幾秒鐘就發(fā)送中兩次只是請求到后端來讀取比較新的數(shù)據(jù)分析結果。

此時就有一個問題了，慢慢的的查詢MySQL的壓力越來越大，大部分可預見的范圍是朝著遠處速度1010級別去走。

可是我們總結了再看看，總之99%的查詢，是頁面JS腳本自動啟動嘶嘶刷新當日數(shù)據(jù)的查詢。唯有1%的查詢是針對昨天以前的歷史數(shù)據(jù)，用戶不自動重新指定去查詢范圍后來網(wǎng)上查詢的。

只不過現(xiàn)在的這個架構之下，我們是把當日實時數(shù)據(jù)計算結果（屬於了熱數(shù)據(jù)）和歷史離線狀態(tài)算出結果（代表了冷數(shù)據(jù)）都放在互相的，所以大家可以想像之中幫一下忙，熱數(shù)據(jù)和冷數(shù)據(jù)放到在一起，然后對熱數(shù)據(jù)的高并發(fā)網(wǎng)上查詢占到了99%，那這樣的架構還合不合理嗎？

肯定不合理不，我們要又一次重構軟件架構。

五、數(shù)據(jù)的冷熱只是分離架構

因為上列說過的問題，很的確做好的一個架構重構是冷熱數(shù)據(jù)只是分離。也就是說，將今日實時計算進去的熱數(shù)據(jù)放進一個MySQL集群里，將離線可以計算出來的冷數(shù)據(jù)裝在另外一個MySQL集群里。

后再變更土地性質一個數(shù)據(jù)查詢平臺，標準封裝底層的多個MySQL集群，參照去查詢條件動態(tài)路由到熱數(shù)據(jù)存儲或者是冷數(shù)據(jù)存儲。

按照這個步驟的重構，我們就可以不有效的將熱數(shù)據(jù)存儲中單表的數(shù)據(jù)量減少到更少更少，有的單表數(shù)據(jù)量很有可能就幾十萬，而且將不聯(lián)網(wǎng)算出的大量數(shù)據(jù)結果從表里剝離出去后了，放另外一個集群里去。此時大家可想而知，效果不過是要好了。

是因為熱數(shù)據(jù)的單表數(shù)據(jù)量減少了很多，當時的一個最明顯的效果，那就是用戶99%的查詢都是根據(jù)熱數(shù)據(jù)存儲率先發(fā)動的，性能從原先的1秒左右降底到了200毫秒以內，用戶體驗提升到，大家覺得更好了。

六、自研ElasticsearchHBase純內存的查詢引擎

架構實踐到這里，感覺起來好像聽說還比較不錯，但是其實問題我還是很多。而且到了這個階段，系統(tǒng)碰上另一個少見相當嚴重的問題：冷數(shù)據(jù)存儲，如果沒有已經(jīng)用MySQL來喚起是很不可靠的。冷數(shù)據(jù)的數(shù)據(jù)量是日增長不斷增強，而且增速一下子，每隔一天都新增加幾千萬。

而你的MySQL服務器城就會遭遇不斷地的需要內存量的問題，并且要是替能支撐這1%的冷數(shù)據(jù)查詢各位，不時的快速擴容提升高配置的MySQL服務器，大家感覺靠譜不么？

估計是不合適的！

要很清楚，大量分庫分表后，MySQL大量的庫和表以維護出聲是相當麻煩的，可以修改個字段？加個索引？這全是場麻煩您事兒。

當然了，是因為對冷數(shù)據(jù)的查詢，一般大都因為大量數(shù)據(jù)的查詢，諸如用戶會中,選擇過去幾個月，甚至于一年的數(shù)據(jù)進行分析查詢，此時要是純用MySQL我還是挺災難性的。

而且當時明顯發(fā)現(xiàn)，是對海量數(shù)據(jù)場景下，頓時查詢總結幾個月或則幾年的數(shù)據(jù)，性能是極差的，應該非常容易搞成幾秒鐘甚至幾十秒才出結果。

因此針對這個冷數(shù)據(jù)的存儲和網(wǎng)站查詢的問題，我們最終你選了自研一套基于組件NoSQL來存儲，然后把基于條件NoSQL內存的SQL計算引擎。

具體來說，我們會將冷數(shù)據(jù)所有常規(guī)ESHBase來通過存儲，ES中比較多貯存要對冷數(shù)據(jù)接受再次篩選的各種條件索引，比如日期和各種維度的數(shù)據(jù)，然后HBase中會貯存全量的數(shù)據(jù)字段。

因為ES和HBase的原生SQL意見都不是太好，并且我們就自研了另外一套SQL引擎，一類允許這種特定的事件的場景，那就是都差不多沒有多表關聯(lián)，應該是對單個數(shù)據(jù)集通過查詢和分析，然后接受NoSQL存儲內存計算出。

這里有一個先決條件，那就是如果不是要能做到對冷數(shù)據(jù)徹底是單表類的數(shù)據(jù)集查詢，可以要在冷數(shù)據(jù)進入NoSQL存儲文件的時候，全部基于組件ES和HBase的特性能夠做到多表入庫時關聯(lián)，進數(shù)據(jù)存儲就全部可以做成大寬表的狀態(tài)，將數(shù)據(jù)關聯(lián)所有上推到入庫時能完成，而不是在查詢時并且。

對冷數(shù)據(jù)的查詢，我們自研的SQL引擎簡單會依據(jù)什么各種where條件先走ES的分布式低功耗索引可以查詢，ES可以不針對海量數(shù)據(jù)低性能的檢索系統(tǒng)出去不需要的那部分數(shù)據(jù)，這個過程用ES做是最合適的。

而后是將檢索系統(tǒng)出的數(shù)據(jù)對應的完整的各個數(shù)據(jù)字段，從HBase里再提取出來，拼接成完成的數(shù)據(jù)。

后再是將這份數(shù)據(jù)集放在內存里，并且急切的函數(shù)計算、分組情況聚合這些排序等操作。

上述事項操作，完全實現(xiàn)自研的根據(jù)這個場景的查詢引擎結束，底層設計和實現(xiàn)Elasticsearch、HBase、純內存來實現(xiàn)方法。

七、實時動態(tài)數(shù)據(jù)存儲化入緩存集群

好了，告一段落，冷數(shù)據(jù)的海量數(shù)據(jù)存儲、集高性能網(wǎng)站查詢的問題，就能解決了。接著回過頭來看一下當日實時數(shù)據(jù)的查詢，總之實時數(shù)據(jù)的每月十五算出結果肯定不會太多，并且中寫入并發(fā)應該不會特別尤其的高，每秒鐘上萬也就也差不多了。

所以這個背景下，是用MySQL分庫分表來抵擋數(shù)據(jù)的寫入、存儲和查詢，都沒問題啊。

可是有一個小問題，那就是說每個商家的實時數(shù)據(jù)總之不是什么正常的變更的，在一段時間內，可能壓根就不知道沒變化，而不不需要高并發(fā)請求，每秒鐘10萬級別的全部落地之前到數(shù)據(jù)庫層面吧？要全部落地之前到數(shù)據(jù)庫層面，那很可能要給每個主庫武器掛架很多從庫來能支撐高并發(fā)讀。

而這里我們化入了一個緩存集群，實時數(shù)據(jù)每次自動更新后中寫入的時候，大都寫數(shù)據(jù)庫集群另外還寫緩存集群的，是雙寫的。

然后再可以查詢的時候是不優(yōu)先從緩存集群來走，此時大部分90的高并發(fā)去查詢都走緩存集群了，然后再只有10%的查詢會落地后到數(shù)據(jù)庫集群。

八、階段性總結

那樣最好，此事到此為止，這個架構基本都左邊也都重新架構之后：

熱數(shù)據(jù)實現(xiàn)緩存集群數(shù)據(jù)庫集群來盛載高并發(fā)的每秒十萬級別的查詢冷數(shù)據(jù)基于ESHBase內存換算的自研去查詢引擎來勉力支撐海量數(shù)據(jù)存儲包括高性能網(wǎng)站查詢。經(jīng)實踐，整個效果非常的好。用戶對熱數(shù)據(jù)的查詢基本是多是幾十毫秒的響應速度，對冷數(shù)據(jù)的查詢基本大都200毫秒以內的響應速度。

九、下一階段的展望

當然系統(tǒng)架構到這里也很不大容易了，而且本是這么說兩張圖，里面涉及到無數(shù)的細節(jié)和技術方案的落地，要一個團隊極耗起碼1年的時間才能能做到這個程度。

不過這一次，我們要對于的，就是高可用的問題，是因為付費級的產品，我們必須要只要暴高的可用性，99.99%的可用性，甚至連是99.999%的可用性。

但是越是復雜的系統(tǒng)，越容易直接出現(xiàn)問題，對應的高可用架構就越是急切至極