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

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

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

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

如何設(shè)計(jì)每秒十萬查詢的高并發(fā)架構(gòu)？

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

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

下一步怎么辦，咱們得來研究什么研究架構(gòu)里左側(cè)的部分了。

二、日趨膨脹的離線計(jì)算結(jié)果

其實(shí)大家會(huì)盡量到，在左側(cè)另外一個(gè)MySQL，那個(gè)MySQL就是用處支撐起實(shí)時(shí)計(jì)算結(jié)果和離線模式可以計(jì)算結(jié)果放進(jìn)里面信息匯總的。

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

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

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

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

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

這種量級(jí)的單表數(shù)據(jù)量，你覺得用戶去查詢數(shù)據(jù)分析報(bào)告的時(shí)候，可以體驗(yàn)?zāi)芎妹矗炕径籍?dāng)時(shí)三次去查詢都是幾秒鐘的級(jí)別。很慢。

倒也罷了，會(huì)出現(xiàn)過用戶一次查詢要十秒的級(jí)別，哪怕幾十秒，上分鐘的級(jí)別。很混亂，用戶體驗(yàn)非常差，遠(yuǎn)遠(yuǎn)的達(dá)不到免費(fèi)的產(chǎn)品的級(jí)別。

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

三、分庫分表讀寫分離

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

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

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

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

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

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

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

上面那套正式的分庫分表讀寫分離的架構(gòu)確實(shí)抵擋了一段時(shí)間，但是漸漸地的那套架構(gòu)又不暴漏不出來了弊端出來了，是因?yàn)樯碳矣脩羰情_了數(shù)據(jù)分析頁面之后，頁面上有js腳本會(huì)每隔幾秒鐘就發(fā)送中兩次只是請(qǐng)求到后端來讀取比較新的數(shù)據(jù)分析結(jié)果。

此時(shí)就有一個(gè)問題了，慢慢的的查詢MySQL的壓力越來越大，大部分可預(yù)見的范圍是朝著遠(yuǎn)處速度1010級(jí)別去走。

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

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

肯定不合理不，我們要又一次重構(gòu)軟件架構(gòu)。

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

因?yàn)樯狭姓f過的問題，很的確做好的一個(gè)架構(gòu)重構(gòu)是冷熱數(shù)據(jù)只是分離。也就是說，將今日實(shí)時(shí)計(jì)算進(jìn)去的熱數(shù)據(jù)放進(jìn)一個(gè)MySQL集群里，將離線可以計(jì)算出來的冷數(shù)據(jù)裝在另外一個(gè)MySQL集群里。

后再變更土地性質(zhì)一個(gè)數(shù)據(jù)查詢平臺(tái)，標(biāo)準(zhǔn)封裝底層的多個(gè)MySQL集群，參照去查詢條件動(dòng)態(tài)路由到熱數(shù)據(jù)存儲(chǔ)或者是冷數(shù)據(jù)存儲(chǔ)。

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

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

六、自研ElasticsearchHBase純內(nèi)存的查詢引擎

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

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

估計(jì)是不合適的！

要很清楚，大量分庫分表后，MySQL大量的庫和表以維護(hù)出聲是相當(dāng)麻煩的，可以修改個(gè)字段？加個(gè)索引？這全是場(chǎng)麻煩您事兒。

當(dāng)然了，是因?yàn)閷?duì)冷數(shù)據(jù)的查詢，一般大都因?yàn)榇罅繑?shù)據(jù)的查詢，諸如用戶會(huì)中,選擇過去幾個(gè)月，甚至于一年的數(shù)據(jù)進(jìn)行分析查詢，此時(shí)要是純用MySQL我還是挺災(zāi)難性的。

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

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

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

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

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

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

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

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

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

七、實(shí)時(shí)動(dòng)態(tài)數(shù)據(jù)存儲(chǔ)化入緩存集群

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

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

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

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

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

八、階段性總結(jié)

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

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

九、下一階段的展望

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

不過這一次，我們要對(duì)于的，就是高可用的問題，是因?yàn)楦顿M(fèi)級(jí)的產(chǎn)品，我們必須要只要暴高的可用性，99.99%的可用性，甚至連是99.999%的可用性。

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