1.概述

我們都知道隨著業(yè)務(wù)系統(tǒng)的發(fā)展和使用，數(shù)據(jù)庫(kù)存儲(chǔ)的業(yè)務(wù)數(shù)據(jù)量會(huì)越來(lái)越大，逐漸成為了業(yè)務(wù)系統(tǒng)的瓶頸。在阿里巴巴開(kāi)發(fā)手冊(cè)中也建議：?jiǎn)伪硇袛?shù)超過(guò)500萬(wàn)行或者單表容量超過(guò)2GB才推薦進(jìn)行分庫(kù)分表，如果預(yù)計(jì)三年后數(shù)據(jù)量根本達(dá)不到這個(gè)級(jí)別，請(qǐng)不要在創(chuàng)建表時(shí)就分庫(kù)分表。數(shù)據(jù)庫(kù)最終都是存儲(chǔ)在磁盤(pán)上，隨著數(shù)據(jù)量變大，會(huì)導(dǎo)致數(shù)據(jù)操作變得緩慢，無(wú)論是計(jì)算還是IO，但是話(huà)又說(shuō)回來(lái)，單表數(shù)據(jù)量大就一定要進(jìn)行分庫(kù)分表操作嗎？答案是否定的，因?yàn)榉謳?kù)分表本身是一個(gè)“很重”的操作，這里就不賣(mài)關(guān)子了，直接來(lái)看看分庫(kù)分表帶來(lái)的以下問(wèn)題和挑戰(zhàn)：

• 重構(gòu)適配系統(tǒng)  本身我們的業(yè)務(wù)系統(tǒng)不可能一開(kāi)始開(kāi)發(fā)上線(xiàn)的時(shí)候就會(huì)分庫(kù)分表，都是隨著系統(tǒng)使用和時(shí)間推移數(shù)據(jù)量日益膨脹才考慮的，進(jìn)行分庫(kù)分表我們業(yè)務(wù)服務(wù)項(xiàng)目代碼需要從單一數(shù)據(jù)庫(kù)表適配成多庫(kù)多表，這是一次極其繁重的重構(gòu)任務(wù)，還涉及到數(shù)據(jù)遷移、備份、擴(kuò)容等操作問(wèn)題，該任務(wù)上線(xiàn)鏈路之長(zhǎng)、風(fēng)險(xiǎn)之大不言而喻，這也是很多小公司即使數(shù)據(jù)量上來(lái)了也不會(huì)馬上分庫(kù)分表的原因吧。
• 事務(wù)問(wèn)題  目前數(shù)據(jù)庫(kù)只能夠?qū)崿F(xiàn)本地事務(wù)，也就是在同一個(gè)數(shù)據(jù)庫(kù)中，可以允許一組操作要么全都正確執(zhí)行，要么都不執(zhí)行，從而確保數(shù)據(jù)庫(kù)的一致性。單從分區(qū)角度出發(fā)，實(shí)際上仍然是一張表，一個(gè)庫(kù)中，它不會(huì)存在事務(wù)一致性的問(wèn)題，但是會(huì)使得事務(wù)變得非常復(fù)雜。而分庫(kù)分表會(huì)涉及到分布式事務(wù)，目前數(shù)據(jù)庫(kù)并不支持跨庫(kù)事務(wù)，所以在這一塊需要解決分布式事務(wù)可能帶來(lái)的不一致性
• 分頁(yè)、排序、聚合函數(shù)問(wèn)題   分頁(yè)需要按照?qǐng)?zhí)行的字段進(jìn)行排序，當(dāng)排序字段就是分片字段的時(shí)候，通過(guò)分片規(guī)則就比較容易定位到指定的分片；當(dāng)排序字段并非分片字段的時(shí)候，就需要在不同分區(qū)、分表中進(jìn)行排序并且返回，然后再將不同分區(qū)、分表中返回的結(jié)果集進(jìn)行匯總和再次排序，最終得到返回結(jié)果。取得頁(yè)數(shù)越多，性能受影響也就越大。因?yàn)樵诜謪^(qū)、分表的時(shí)候都已經(jīng)限定了分片字段，而其他字段是跟著分片的字段被分到不同的區(qū)域或者表中，這樣各個(gè)分區(qū)、分表中的數(shù)據(jù)可能是隨機(jī)的，為了排序的準(zhǔn)確性，需要將所有分區(qū)、分表節(jié)點(diǎn)的前的數(shù)據(jù)都排好序做合并，最后進(jìn)行整體排序，這樣的操作是非常耗費(fèi)CPU和內(nèi)存資源的，所以在分區(qū)、分表的情況下、分頁(yè)數(shù)越大，系統(tǒng)的性能也會(huì)越差。同樣、在使用聚合函數(shù)，如Max、Min、Sum、Count進(jìn)行計(jì)算的時(shí)候，也會(huì)像排序那樣在每個(gè)分區(qū)、分表執(zhí)行相應(yīng)的函數(shù)，然后再將各個(gè)分區(qū)、分表的結(jié)果集進(jìn)行匯總和再次計(jì)算，最終將結(jié)果返回。
• 全局主鍵避免重復(fù)  單表主鍵id自增能夠保證id不重復(fù)，但是分庫(kù)分表之后，多張表就不能保證主鍵id不重復(fù)了，這時(shí)候就要使用分布式id算法進(jìn)行生成。
• 數(shù)據(jù)遷移、擴(kuò)容問(wèn)題  隨著數(shù)據(jù)持續(xù)增加分表后還需要進(jìn)行動(dòng)態(tài)新增表時(shí)，這個(gè)時(shí)候就要考慮數(shù)據(jù)遷移以及擴(kuò)容問(wèn)題。一般做法是先讀出歷史數(shù)據(jù)，然后按照指定的分表規(guī)則再將數(shù)據(jù)寫(xiě)入各個(gè)分表中。這本身就是繁雜之事。

當(dāng)然以上問(wèn)題并不是說(shuō)分庫(kù)分表是一個(gè)不可取的方案，現(xiàn)在分庫(kù)分表方案在很多公司系統(tǒng)都有應(yīng)用的，這里想表達(dá)的是需要根據(jù)個(gè)人公司業(yè)務(wù)系統(tǒng)數(shù)據(jù)特點(diǎn)，綜合評(píng)估做權(quán)衡來(lái)選擇解決數(shù)據(jù)量大的實(shí)施方案。

項(xiàng)目推薦：基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba企業(yè)級(jí)系統(tǒng)架構(gòu)底層框架封裝，解決業(yè)務(wù)開(kāi)發(fā)時(shí)常見(jiàn)的非功能性需求，防止重復(fù)造輪子，方便業(yè)務(wù)快速開(kāi)發(fā)和企業(yè)技術(shù)棧框架統(tǒng)一管理。引入組件化的思想實(shí)現(xiàn)高內(nèi)聚低耦合并且高度可配置化，做到可插拔。嚴(yán)格控制包依賴(lài)和統(tǒng)一版本管理，做到最少化依賴(lài)。注重代碼規(guī)范和注釋?zhuān)浅＿m合個(gè)人學(xué)習(xí)和企業(yè)使用

Github地址：https://github.com/plasticene/plasticene-boot-starter-parent

Gitee地址：https://gitee.com/plasticene3/plasticene-boot-starter-parent

微信公眾號(hào)：Shepherd進(jìn)階筆記

交流探討qun：Shepherd_126

2.業(yè)務(wù)數(shù)據(jù)量大的解決方案

2.1 數(shù)據(jù)歸檔

來(lái)分析一個(gè)美團(tuán)業(yè)務(wù)場(chǎng)景：我們?nèi)粘Ｃ刻禳c(diǎn)外賣(mài)，平時(shí)會(huì)去查看一年前的訂單，看看一年前吃了什么嗎？答案是幾乎不會(huì)，或者說(shuō)這種查詢(xún)的請(qǐng)求量比較小，出現(xiàn)這種請(qǐng)求大概是有人問(wèn)你很早之前點(diǎn)的那家外賣(mài)好吃，但是你不喜歡記不得了，你幫她查找一下的場(chǎng)景吧~~。由此可見(jiàn)，我們可以根據(jù)這一特點(diǎn)進(jìn)行數(shù)據(jù)歷史歸檔，即數(shù)據(jù)做冷、熱區(qū)分存儲(chǔ)。當(dāng)然這個(gè)區(qū)分時(shí)限要根據(jù)自身系統(tǒng)數(shù)據(jù)特點(diǎn)來(lái)指定時(shí)限是一年還是半年....這樣就能保證我們高頻查詢(xún)的熱數(shù)據(jù)量不大了。

在查詢(xún)歷史數(shù)據(jù)表時(shí)，可以限制查詢(xún)條件如必須選擇日期范圍，日期范圍不能超過(guò)N個(gè)月等等從而減輕查詢(xún)壓力。處理歷史存量數(shù)據(jù)比較簡(jiǎn)單，因?yàn)闅v史數(shù)據(jù)一般不會(huì)變更了，所以一般只需要兩個(gè)步驟進(jìn)行歸檔：

• 遷移滿(mǎn)足限定數(shù)據(jù)到指定歷史歸檔表
• 根據(jù)主鍵分批刪除業(yè)務(wù)原表數(shù)據(jù)，從而降低業(yè)務(wù)數(shù)據(jù)量

這里需要強(qiáng)調(diào)一下，不能一次性刪除所有數(shù)據(jù)，因?yàn)閿?shù)據(jù)量太大可能會(huì)引發(fā)超時(shí)，鎖表，長(zhǎng)事務(wù)等問(wèn)題，而是應(yīng)該根據(jù)ID分批刪除，例如每次刪除500或1000條數(shù)據(jù)。操作步驟如下：

SELECT MAX(id) AS maxId FROM t WHERE create_time < '指定時(shí)間'

查出滿(mǎn)足歸檔條件的數(shù)據(jù)最大id，接下來(lái)就可以分批歸檔和刪除了，初始化 startId=0，每次歸檔500條

select * into t_bak from t where id > startId and id <= maxId limit 500

查詢(xún)歸檔表獲取最大id：maxBakId，賦值給startId方便下次分批歸檔刪除

select max(id) from t_bak

數(shù)據(jù)刪除：

delete from t where id <= maxBakId

重復(fù)上面的歸檔刪除操作，直至startId到maxId結(jié)束

2.2 讀寫(xiě)分離和熱點(diǎn)緩存

大部分的業(yè)務(wù)系統(tǒng)場(chǎng)景都是讀多寫(xiě)少，讀寫(xiě)比一般都在幾十左右，平均每發(fā)生幾十次查詢(xún)請(qǐng)求，才有一次更新請(qǐng)求。換句話(huà)來(lái)說(shuō)，數(shù)據(jù)庫(kù)需要應(yīng)對(duì)的絕大部分請(qǐng)求都是只讀查詢(xún)請(qǐng)求。針對(duì)這種情況我們可以通過(guò)讀寫(xiě)分離方案來(lái)降低數(shù)據(jù)庫(kù)壓力。

圖片

主庫(kù)負(fù)責(zé)執(zhí)行應(yīng)用程序發(fā)來(lái)的所有數(shù)據(jù)更新請(qǐng)求，然后異步將數(shù)據(jù)變更實(shí)時(shí)同步到所有的從庫(kù)中去，這樣，主庫(kù)和所有從庫(kù)中的數(shù)據(jù)是完全一樣的。多個(gè)從庫(kù)共同分擔(dān)應(yīng)用的查詢(xún)請(qǐng)求。

對(duì)于一些高頻訪(fǎng)問(wèn)的熱點(diǎn)數(shù)據(jù)，我們可以提前預(yù)處理使用redis緩存，這樣也可以有效降低數(shù)據(jù)庫(kù)的壓力。

2.3 同步異構(gòu)數(shù)據(jù)源

我們知道MySQL會(huì)隨著數(shù)據(jù)量增大而查詢(xún)變慢，那么我們換成其他數(shù)據(jù)源來(lái)完成OLAP查詢(xún)場(chǎng)景不就得了。特別是在當(dāng)下大數(shù)據(jù)時(shí)代，現(xiàn)在互聯(lián)網(wǎng)公司一般都具備與之規(guī)模相對(duì)應(yīng)的大數(shù)據(jù)服務(wù)或者平臺(tái)，那么作為業(yè)務(wù)開(kāi)發(fā)者要善于應(yīng)用公司大數(shù)據(jù)能力，減輕業(yè)務(wù)數(shù)據(jù)庫(kù)壓力。比如我們可以把數(shù)據(jù)同步到ES、HBASE等平臺(tái)。

使用elasticsearch來(lái)實(shí)現(xiàn)海量數(shù)據(jù)搜索就是一個(gè)不錯(cuò)的選擇，elasticsearch是一個(gè)基于Lucene的搜索服務(wù)器。它提供了一個(gè)分布式多用戶(hù)能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java開(kāi)發(fā)的，并作為Apache許可條款下的開(kāi)放源碼發(fā)布，是當(dāng)前流行的企業(yè)級(jí)搜索引擎。能夠達(dá)到實(shí)時(shí)搜索，穩(wěn)定，可靠，快速，安裝使用方便。但是如何實(shí)現(xiàn)MySQL數(shù)據(jù)同步elasticsearch呢？

答案是阿里的開(kāi)源項(xiàng)目Canal，就是用來(lái)解決異構(gòu)數(shù)據(jù)源數(shù)據(jù)同步這個(gè)問(wèn)題的，Canal項(xiàng)目利用了MySQL數(shù)據(jù)庫(kù)主從同步的原理，將Canal Server模擬成一臺(tái)需要同步的從庫(kù)，從而讓主庫(kù)將binlog日志流發(fā)送到Canal Server接口。Canal項(xiàng)目對(duì)binlog日志的解析進(jìn)行了封裝，我們可以直接得到解析后的數(shù)據(jù)，而不需要理會(huì)binlog的日志格式。而且Canal項(xiàng)目整合了zookeeper，整體實(shí)現(xiàn)了高可用，可伸縮性強(qiáng)

圖片

2.4 分庫(kù)分表

如果通過(guò)以上：歷史數(shù)據(jù)歸檔、數(shù)據(jù)同步異構(gòu)數(shù)據(jù)源、讀寫(xiě)分離、熱點(diǎn)緩存都不能解決MySQL單表數(shù)據(jù)壓力的，這時(shí)我們只能拆分?jǐn)?shù)據(jù)表，即把單庫(kù)單表數(shù)據(jù)遷移到多庫(kù)多表中。這也是一線(xiàn)流量互聯(lián)網(wǎng)公司需要面對(duì)的，你試想一下淘寶雙11那幾天要上架多少商品，產(chǎn)生多少訂單，這已經(jīng)不是前面的方案所能解決了，只能分庫(kù)分表了。當(dāng)然分庫(kù)分表是一個(gè)復(fù)雜的操作，也不是三言?xún)烧Z(yǔ)就能全面講清楚的，且也不是我們今天主要議題，所以我這里粗略概述一下，感興趣的可自行查閱相關(guān)資料。

垂直拆分

垂直拆分就是按照業(yè)務(wù)拆分，我們將電商數(shù)據(jù)庫(kù)拆分成三個(gè)庫(kù)，訂單庫(kù)、商品庫(kù)。支付庫(kù)，訂單表在訂單庫(kù)，商品表在商品庫(kù)，支付表在支付庫(kù)。這樣每個(gè)庫(kù)只需要存儲(chǔ)本業(yè)務(wù)數(shù)據(jù)，物理隔離不會(huì)互相影響。

水平拆分

按照垂直拆分方案，現(xiàn)在我們已經(jīng)有三個(gè)庫(kù)了，平穩(wěn)運(yùn)行了一段時(shí)間。但是隨著業(yè)務(wù)增長(zhǎng)，每個(gè)單庫(kù)單表的數(shù)據(jù)量也越來(lái)越大，逐漸到達(dá)瓶頸。

這時(shí)我們就要對(duì)數(shù)據(jù)表進(jìn)行水平拆分，所謂水平拆分就是根據(jù)某種規(guī)則將單庫(kù)單表數(shù)據(jù)分散到多庫(kù)多表，從而減小單庫(kù)單表的壓力。

水平拆分策略有很多方案，最重要的一點(diǎn)是選好ShardingKey，也就是按照哪一列進(jìn)行拆分，怎么分取決于我們?cè)L問(wèn)數(shù)據(jù)的方式。

比如我們可以根據(jù)時(shí)間范圍分片，根據(jù)創(chuàng)建時(shí)間分配到不同的表中。也可以根據(jù)哈希分表，哈希分片可以較為均勻?qū)?shù)據(jù)分散在數(shù)據(jù)庫(kù)中。我們現(xiàn)在將訂單庫(kù)拆分為4個(gè)庫(kù)編號(hào)為[0,3]，每個(gè)庫(kù)4張表編號(hào)為[0,3]，根據(jù)分布式id%編號(hào)落庫(kù)，當(dāng)然也有其他分片方案，這取決于你們公司業(yè)務(wù)數(shù)據(jù)特點(diǎn)。

3.如何實(shí)時(shí)同步數(shù)據(jù)到elasticsearch支持海量查詢(xún)

我一開(kāi)始就強(qiáng)調(diào)了分庫(kù)分表帶來(lái)的問(wèn)題，可見(jiàn)今天的重點(diǎn)肯定不是采用分庫(kù)分表來(lái)解決數(shù)據(jù)量大的問(wèn)題的，所以我接下來(lái)來(lái)講講我司的解決方案：數(shù)據(jù)歸檔+讀寫(xiě)分離+同步異構(gòu)數(shù)據(jù)源

數(shù)據(jù)歸檔可以有效降低數(shù)據(jù)庫(kù)數(shù)據(jù)量，讀寫(xiě)分離可以降低單數(shù)據(jù)庫(kù)的讀寫(xiě)壓力，異構(gòu)數(shù)據(jù)源es滿(mǎn)足日常查詢(xún)性能要求。

數(shù)據(jù)歸檔的操作步驟前面說(shuō)過(guò)了，至于數(shù)據(jù)庫(kù)讀寫(xiě)分離實(shí)現(xiàn)方案等后續(xù)有時(shí)間再分析一波，今天主要講講如何高效實(shí)時(shí)同步elasticsearch滿(mǎn)足查詢(xún)要求。直接看架構(gòu)圖：

圖片

數(shù)據(jù)同步elasticsearch大概有兩種：

1.針對(duì)代碼中進(jìn)行數(shù)據(jù)庫(kù)的增刪改操作時(shí)，同時(shí)進(jìn)行elasticsearch的增刪改操作。這種方式代碼侵入性強(qiáng)，耦合度高，實(shí)時(shí)性高，改造起來(lái)比較痛苦，因?yàn)槟悴荒苠e(cuò)過(guò)任何一個(gè)增刪改的地方同步操作es，否則就會(huì)出現(xiàn)數(shù)據(jù)不一致問(wèn)題。

2.利用監(jiān)聽(tīng)mysql binlog同步，實(shí)時(shí)性強(qiáng)，對(duì)于應(yīng)用無(wú)任何侵入性，且性能更好，不會(huì)造成資源浪費(fèi)。正好阿里巴巴開(kāi)源的canal就是干這個(gè)的，完美解決問(wèn)題。通過(guò)上面的架構(gòu)圖知道可以通過(guò)canal client拿到canal server對(duì)binlog的解析直接同步到es，但是這種方式處理比較慢，等于我們是一條一條的去同步，很多情況下es的索引表是一張大寬表，是來(lái)自MySQL幾張表join的信息，這要求我們同步的時(shí)候還要根據(jù)主鍵通過(guò)join sql語(yǔ)句查出數(shù)據(jù)再同步，自然就更慢了。所以要使用消息隊(duì)列kafka進(jìn)行數(shù)據(jù)削峰填谷，批量操作是保證實(shí)時(shí)性的關(guān)鍵。

4.總結(jié)

以上全部就是我們對(duì)海量數(shù)據(jù)實(shí)時(shí)搜索的解決方案淺析，各有利弊。我們可以根據(jù)自身的業(yè)務(wù)數(shù)據(jù)情況選擇合適的方案即可，切勿動(dòng)不動(dòng)就來(lái)分庫(kù)分表，顯得有點(diǎn)不知深淺。

本文轉(zhuǎn)載自微信公眾號(hào)「Shepherd進(jìn)階筆記」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系公眾號(hào)。