讀寫(xiě)分離

什么是讀寫(xiě)分離

讀寫(xiě)分離主要是為了將對(duì)數(shù)據(jù)庫(kù)的讀寫(xiě)操作分散到不同的數(shù)據(jù)庫(kù)節(jié)點(diǎn)上。 這樣的話，就能夠小幅提升寫(xiě)性能，大幅提升讀性能。一般情況下，我們都會(huì)選擇一主多從，也就是一臺(tái)主數(shù)據(jù)庫(kù)負(fù)責(zé)寫(xiě)，其他的從數(shù)據(jù)庫(kù)負(fù)責(zé)讀。主庫(kù)和從庫(kù)之間會(huì)進(jìn)行數(shù)據(jù)同步，以保證從庫(kù)中數(shù)據(jù)的準(zhǔn)確性。這樣的架構(gòu)實(shí)現(xiàn)起來(lái)比較簡(jiǎn)單，并且也符合系統(tǒng)的寫(xiě)少讀多的特點(diǎn)。

如何實(shí)現(xiàn)讀寫(xiě)分離

不論是使用哪一種讀寫(xiě)分離的實(shí)現(xiàn)方案，想要實(shí)現(xiàn)讀寫(xiě)分離一般包含如下幾步：

1. 部署多臺(tái)數(shù)據(jù)庫(kù)，選擇其中的一臺(tái)作為主數(shù)據(jù)庫(kù)，其他的一臺(tái)或者多臺(tái)作為從數(shù)據(jù)庫(kù)。
2. 保證主數(shù)據(jù)庫(kù)和從數(shù)據(jù)庫(kù)之間的數(shù)據(jù)是實(shí)時(shí)同步的，這個(gè)過(guò)程也就是我們常說(shuō)的主從復(fù)制。
3. 系統(tǒng)將寫(xiě)請(qǐng)求交給主數(shù)據(jù)庫(kù)處理，讀請(qǐng)求交給從數(shù)據(jù)庫(kù)處理。

落實(shí)到項(xiàng)目本身的話，常用的方式有兩種：

1. 代理方式

我們可以在應(yīng)用和數(shù)據(jù)中間加了一個(gè)代理層。應(yīng)用程序所有的數(shù)據(jù)請(qǐng)求都交給代理層處理，代理層負(fù)責(zé)分離讀寫(xiě)請(qǐng)求，將它們路由到對(duì)應(yīng)的數(shù)據(jù)庫(kù)中。提供類(lèi)似功能的中間件有MySQL Router（官方， MySQL Proxy 的替代方案）、Atlas（基于 MySQL Proxy）、MaxScale、MyCat。

2. 組件方式

這也是比較推薦的一種方式，可以通過(guò)引入第三方組件來(lái)幫助我們讀寫(xiě)請(qǐng)求。推薦使用sharding-jdbc ，直接引入jar包即可使用，非常方便。同時(shí)，也節(jié)省了很多運(yùn)維的成本。

主從復(fù)制原理是什么

binlog主要記錄了MySQL數(shù)據(jù)庫(kù)中數(shù)據(jù)的所有變化(所有DDL和DML語(yǔ)句)。因此，我們根據(jù)主庫(kù)的binlog就能夠?qū)⒅鲙?kù)的數(shù)據(jù)同步到從庫(kù)中。

1. 主庫(kù)將數(shù)據(jù)庫(kù)中數(shù)據(jù)的變化寫(xiě)入到binlog
2. 從庫(kù)連接主庫(kù)
3. 從庫(kù)會(huì)創(chuàng)建一個(gè)I/O線程向主庫(kù)請(qǐng)求更新的binlog
4. 主庫(kù)會(huì)創(chuàng)建一個(gè)binlog dump線程來(lái)發(fā)送binlog，從庫(kù)中的I/O線程負(fù)責(zé)接收
5. 從庫(kù)的I/O線程將接收的binlog寫(xiě)入到relay log中
6. 從庫(kù)的SQL線程讀取relay log同步數(shù)據(jù)到本地，也就是再執(zhí)行一遍 SQL

如何避免主從延遲

讀寫(xiě)分離對(duì)于提升數(shù)據(jù)庫(kù)的并發(fā)非常有效，但是，同時(shí)也會(huì)引來(lái)一個(gè)問(wèn)題：主庫(kù)和從庫(kù)的數(shù)據(jù)同步存在延遲，比如你寫(xiě)完主庫(kù)之后，主庫(kù)的數(shù)據(jù)同步到從庫(kù)是需要時(shí)間的，這個(gè)時(shí)間差就導(dǎo)致了主庫(kù)和從庫(kù)的數(shù)據(jù)不一致性問(wèn)題 。如果我們的業(yè)務(wù)場(chǎng)景無(wú)法容忍主從同步延遲的話，應(yīng)該如何避免呢？

強(qiáng)制將讀請(qǐng)求路由到主庫(kù)處理

這種方案雖然會(huì)增加主庫(kù)的壓力，但是，實(shí)現(xiàn)起來(lái)比較簡(jiǎn)單，也是我了解到的使用最多的一種方式。比如Sharding-JDBC就是采用的這種方案。通過(guò)使用Sharding-JDBC的HintManager分片鍵值管理器，我們可以強(qiáng)制使用主庫(kù)。

延遲讀取

如果業(yè)務(wù)上允許的話，既然主從同步存在延遲，那就在延遲之后讀取，比如主從同步延遲0.5s，那我就1s之后再讀取數(shù)據(jù)。

不過(guò)對(duì)于一些對(duì)數(shù)據(jù)比較敏感的場(chǎng)景，可以在完成寫(xiě)請(qǐng)求之后避免立即進(jìn)行請(qǐng)求操作。比如你支付成功之后，跳轉(zhuǎn)到一個(gè)支付成功的頁(yè)面，當(dāng)你點(diǎn)擊返回之后才返回自己的賬戶(hù)。

什么情況下會(huì)出現(xiàn)主從延遲？如何盡量減少延遲

要搞懂什么情況下會(huì)出現(xiàn)主從延遲，我們需要先搞懂什么是主從延遲。

MySQL主從同步延時(shí)是指從庫(kù)的數(shù)據(jù)落后于主庫(kù)的數(shù)據(jù)，這種情況可能由以下兩個(gè)原因造成：

1. 從庫(kù)I/O線程接收binlog的速度跟不上主庫(kù)寫(xiě)入binlog的速度，導(dǎo)致從庫(kù)relay log的數(shù)據(jù)滯后于主庫(kù)binlog的數(shù)據(jù)；
2. 從庫(kù)SQL線程執(zhí)行relay log的速度跟不上從庫(kù)I/O線程接收binlog的速度，導(dǎo)致從庫(kù)的數(shù)據(jù)滯后于從庫(kù)relay log的數(shù)據(jù)。

與主從同步有關(guān)的時(shí)間點(diǎn)主要有3個(gè)：

1. 主庫(kù)執(zhí)行完一個(gè)事務(wù)，寫(xiě)入binlog，將這個(gè)時(shí)刻記為T(mén)1；
2. 從庫(kù)I/O線程接收到binlog并寫(xiě)入relay log的時(shí)刻記為T(mén)2；
3. 從庫(kù)SQL線程讀取relay log同步數(shù)據(jù)本地的時(shí)刻記為T(mén)3。

可以得出：

• T2和T1的差值反映了從庫(kù)I/O線程的性能和網(wǎng)絡(luò)傳輸?shù)男?#xff0c;這個(gè)差值越小說(shuō)明從庫(kù)I/O線程的性能和網(wǎng)絡(luò)傳輸效率越高。
• T3和T2的差值反映了從庫(kù)SQL線程執(zhí)行的速度，這個(gè)差值越小，說(shuō)明從庫(kù)SQL線程執(zhí)行速度越快。

那什么情況下會(huì)出現(xiàn)出從延遲呢？這里列舉幾種常見(jiàn)的情況：

• 從庫(kù)機(jī)器性能比主庫(kù)差：從庫(kù)接收binlog并寫(xiě)入relay log以及執(zhí)行SQL語(yǔ)句的速度會(huì)比較慢，進(jìn)而導(dǎo)致延遲。解決方法是選擇與主庫(kù)一樣規(guī)格或更高規(guī)格的機(jī)器作為從庫(kù)，或者對(duì)從庫(kù)進(jìn)行性能優(yōu)化，比如調(diào)整參數(shù)、增加緩存、使用SSD等。
• 從庫(kù)處理的讀請(qǐng)求過(guò)多：從庫(kù)需要執(zhí)行主庫(kù)的所有寫(xiě)操作，同時(shí)還要響應(yīng)讀請(qǐng)求，如果讀請(qǐng)求過(guò)多，會(huì)占用從庫(kù)的CPU、內(nèi)存、網(wǎng)絡(luò)等資源，影響從庫(kù)的復(fù)制效率。解決方法是引入緩存（推薦）、使用一主多從的架構(gòu)，將讀請(qǐng)求分散到不同的從庫(kù)，或者使用其他系統(tǒng)來(lái)提供查詢(xún)的能力，比如將binlog接入到Hadoop、Elasticsearch等系統(tǒng)中。
• 大事務(wù)：運(yùn)行時(shí)間比較長(zhǎng)，長(zhǎng)時(shí)間未提交的事務(wù)就可以稱(chēng)為大事務(wù)。由于大事務(wù)執(zhí)行時(shí)間長(zhǎng)，并且從庫(kù)上的大事務(wù)會(huì)比主庫(kù)上的大事務(wù)花費(fèi)更多的時(shí)間和資源，因此非常容易造成主從延遲。解決辦法是避免大批量修改數(shù)據(jù)，盡量分批進(jìn)行。類(lèi)似的情況還有執(zhí)行時(shí)間較長(zhǎng)的慢SQL ，實(shí)際項(xiàng)目遇到慢SQL應(yīng)該進(jìn)行優(yōu)化。
• 從庫(kù)太多：主庫(kù)需要將binlog同步到所有的從庫(kù)，如果從庫(kù)數(shù)量太多，會(huì)增加同步的時(shí)間和開(kāi)銷(xiāo)。解決方案是減少?gòu)膸?kù)的數(shù)量，或者將從庫(kù)分為不同的層級(jí)，讓上層的從庫(kù)再同步給下層的從庫(kù)，減少主庫(kù)的壓力。
• 網(wǎng)絡(luò)延遲：如果主從之間的網(wǎng)絡(luò)傳輸速度慢，或者出現(xiàn)丟包、抖動(dòng)等問(wèn)題，那么就會(huì)影響binlog的傳輸效率，導(dǎo)致從庫(kù)延遲。解決方法是優(yōu)化網(wǎng)絡(luò)環(huán)境，比如提升帶寬、降低延遲、增加穩(wěn)定性等。
• 單線程復(fù)制：MySQL5.5 及之前，只支持單線程復(fù)制。為了優(yōu)化復(fù)制性能，MySQL 5.6 引入了 多線程復(fù)制，MySQL 5.7 還進(jìn)一步完善了多線程復(fù)制。
• 復(fù)制模式：MySQL默認(rèn)的復(fù)制是異步的，必然會(huì)存在延遲問(wèn)題。全同步復(fù)制不存在延遲問(wèn)題，但性能太差了。半同步復(fù)制是一種折中方案，相對(duì)于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，減少了主從延遲。MySQL 5.5 開(kāi)始，MySQL 以插件的形式支持semi-sync半同步復(fù)制。并且，MySQL 5.7 引入了 增強(qiáng)半同步復(fù)制 。

分庫(kù)分表

什么是分庫(kù)

分庫(kù)就是將數(shù)據(jù)庫(kù)中的數(shù)據(jù)分散到不同的數(shù)據(jù)庫(kù)上，可以垂直分庫(kù)，也可以水平分庫(kù)。

垂直分庫(kù)就是把單一數(shù)據(jù)庫(kù)按照業(yè)務(wù)進(jìn)行劃分，不同的業(yè)務(wù)使用不同的數(shù)據(jù)庫(kù)，進(jìn)而將一個(gè)數(shù)據(jù)庫(kù)的壓力分擔(dān)到多個(gè)數(shù)據(jù)庫(kù)。

水平分庫(kù)是把同一個(gè)表按一定規(guī)則拆分到不同的數(shù)據(jù)庫(kù)中，每個(gè)庫(kù)可以位于不同的服務(wù)器上，這樣就實(shí)現(xiàn)了水平擴(kuò)展，解決了單表的存儲(chǔ)和性能瓶頸的問(wèn)題。

什么是分表

分表就是對(duì)單表的數(shù)據(jù)進(jìn)行拆分，可以是垂直拆分，也可以是水平拆分。

垂直分表是對(duì)數(shù)據(jù)表列的拆分，把一張列比較多的表拆分為多張表。

水平分表是對(duì)數(shù)據(jù)表行的拆分，把一張行比較多的表拆分為多張表，可以解決單一表數(shù)據(jù)量過(guò)大的問(wèn)題。

水平拆分只能解決單表數(shù)據(jù)量大的問(wèn)題，為了提升性能，我們通常會(huì)選擇將拆分后的多張表放在不同的數(shù)據(jù)庫(kù)中。也就是說(shuō)，水平分表通常和水平分庫(kù)同時(shí)出現(xiàn)。

什么情況下需要分庫(kù)分表

遇到下面幾種場(chǎng)景可以考慮分庫(kù)分表：

• 單表的數(shù)據(jù)達(dá)到千萬(wàn)級(jí)別以上，數(shù)據(jù)庫(kù)讀寫(xiě)速度比較緩慢。
• 數(shù)據(jù)庫(kù)中的數(shù)據(jù)占用的空間越來(lái)越大，備份時(shí)間越來(lái)越長(zhǎng)。
• 應(yīng)用的并發(fā)量太大（應(yīng)該優(yōu)先考慮其他性能優(yōu)化方法，而非分庫(kù)分表）。

不過(guò)，分庫(kù)分表的成本太高，如非必要盡量不要采用。而且，并不一定是單表千萬(wàn)級(jí)數(shù)據(jù)量就要分表，畢竟每張表包含的字段不同，它們?cè)诓诲e(cuò)的性能下能夠存放的數(shù)據(jù)量也不同，還是要具體情況具體分析。

常見(jiàn)的分片算法有哪些

分片算法主要解決了數(shù)據(jù)被水平分片之后，數(shù)據(jù)究竟該存放在哪個(gè)表的問(wèn)題。

常見(jiàn)的分片算法有：

• 哈希分片：求指定分片鍵的哈希，然后根據(jù)哈希值確定數(shù)據(jù)應(yīng)被放置在哪個(gè)表中。哈希分片比較適合隨機(jī)讀寫(xiě)的場(chǎng)景，不太適合經(jīng)常需要范圍查詢(xún)的場(chǎng)景。哈希分片可以使每個(gè)表的數(shù)據(jù)分布相對(duì)均勻，但對(duì)動(dòng)態(tài)伸縮（例如新增一個(gè)表或者庫(kù)）不友好。
• 范圍分片：按照特定的范圍區(qū)間（比如時(shí)間區(qū)間、ID 區(qū)間）來(lái)分配數(shù)據(jù)，比如 將id為1~299999的記錄分到第一個(gè)表，300000~599999的分到第二個(gè)表。范圍分片適合需要經(jīng)常進(jìn)行范圍查找且數(shù)據(jù)分布均勻的場(chǎng)景，不太適合隨機(jī)讀寫(xiě)的場(chǎng)景（數(shù)據(jù)未被分散，容易出現(xiàn)熱點(diǎn)數(shù)據(jù)的問(wèn)題）。
• 映射表分片：使用一個(gè)單獨(dú)的表（稱(chēng)為映射表）來(lái)存儲(chǔ)分片鍵和分片位置的對(duì)應(yīng)關(guān)系。映射表分片策略可以支持任何類(lèi)型的分片算法，如哈希分片、范圍分片等。映射表分片策略是可以靈活地調(diào)整分片規(guī)則，不需要修改應(yīng)用程序代碼或重新分布數(shù)據(jù)。不過(guò)，這種方式需要維護(hù)額外的表，還增加了查詢(xún)的開(kāi)銷(xiāo)和復(fù)雜度。
• 一致性哈希分片：將哈?？臻g組織成一個(gè)環(huán)形結(jié)構(gòu)，將分片鍵和節(jié)點(diǎn)（數(shù)據(jù)庫(kù)或表）都映射到這個(gè)環(huán)上，然后根據(jù)順時(shí)針的規(guī)則確定數(shù)據(jù)或請(qǐng)求應(yīng)該分配到哪個(gè)節(jié)點(diǎn)上，解決了傳統(tǒng)哈希對(duì)動(dòng)態(tài)伸縮不友好的問(wèn)題。
• 地理位置分片：很多 NewSQL 數(shù)據(jù)庫(kù)都支持地理位置分片算法，也就是根據(jù)地理位置（如城市、地域）來(lái)分配數(shù)據(jù)。
• 融合算法分片：靈活組合多種分片算法，比如將哈希分片和范圍分片組合。

分片鍵如何選擇

分片鍵（Sharding Key）是數(shù)據(jù)分片的關(guān)鍵字段。分片鍵的選擇非常重要，它關(guān)系著數(shù)據(jù)的分布和查詢(xún)效率。一般來(lái)說(shuō)，分片鍵應(yīng)該具備以下特點(diǎn)：

• 具有共性，即能夠覆蓋絕大多數(shù)的查詢(xún)場(chǎng)景，盡量減少單次查詢(xún)所涉及的分片數(shù)量，降低數(shù)據(jù)庫(kù)壓力；
• 具有離散性，即能夠?qū)?shù)據(jù)均勻地分散到各個(gè)分片上，避免數(shù)據(jù)傾斜和熱點(diǎn)問(wèn)題；
• 具有穩(wěn)定性，即分片鍵的值不會(huì)發(fā)生變化，避免數(shù)據(jù)遷移和一致性問(wèn)題；
• 具有擴(kuò)展性，即能夠支持分片的動(dòng)態(tài)增加和減少，避免數(shù)據(jù)重新分片的開(kāi)銷(xiāo)。

實(shí)際項(xiàng)目中，分片鍵很難滿足上面提到的所有特點(diǎn)，需要權(quán)衡一下。并且，分片鍵可以是表中多個(gè)字段的組合，例如取用戶(hù)ID后四位作為訂單ID后綴。

分庫(kù)分表會(huì)帶來(lái)什么問(wèn)題呢

引入分庫(kù)分表之后，會(huì)給系統(tǒng)帶來(lái)什么挑戰(zhàn)呢？

• join操作：同一個(gè)數(shù)據(jù)庫(kù)中的表分布在了不同的數(shù)據(jù)庫(kù)中，導(dǎo)致無(wú)法使用 join 操作。這樣就導(dǎo)致我們需要手動(dòng)進(jìn)行數(shù)據(jù)的封裝，比如你在一個(gè)數(shù)據(jù)庫(kù)中查詢(xún)到一個(gè)數(shù)據(jù)之后，再根據(jù)這個(gè)數(shù)據(jù)去另外一個(gè)數(shù)據(jù)庫(kù)中找對(duì)應(yīng)的數(shù)據(jù)。不過(guò)建議盡量不要使用join操作，因?yàn)閖oin的效率低，并且會(huì)對(duì)分庫(kù)分表造成影響。對(duì)于需要用到j(luò)oin操作的地方，可以采用多次查詢(xún)業(yè)務(wù)層進(jìn)行數(shù)據(jù)組裝的方法。不過(guò)，這種方法需要考慮業(yè)務(wù)上多次查詢(xún)的事務(wù)性的容忍度。
• 事務(wù)問(wèn)題：同一個(gè)數(shù)據(jù)庫(kù)中的表分布在了不同的數(shù)據(jù)庫(kù)中，如果單個(gè)操作涉及到多個(gè)數(shù)據(jù)庫(kù)，那么數(shù)據(jù)庫(kù)自帶的事務(wù)就無(wú)法滿足我們的要求了。這個(gè)時(shí)候，我們就需要引入分布式事務(wù)了。
• 分布式 ID：分庫(kù)之后， 數(shù)據(jù)遍布在不同服務(wù)器上的數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)的自增主鍵已經(jīng)沒(méi)辦法滿足生成的主鍵唯一了。我們?nèi)绾螢椴煌臄?shù)據(jù)節(jié)點(diǎn)生成全局唯一主鍵呢？這個(gè)時(shí)候，我們就需要為我們的系統(tǒng)引入分布式ID了。
• 跨庫(kù)聚合查詢(xún)問(wèn)題：分庫(kù)分表會(huì)導(dǎo)致常規(guī)聚合查詢(xún)操作，如group by，order by等變得異常復(fù)雜。這是因?yàn)檫@些操作需要在多個(gè)分片上進(jìn)行數(shù)據(jù)匯總和排序，而不是在單個(gè)數(shù)據(jù)庫(kù)上進(jìn)行。為了實(shí)現(xiàn)這些操作，需要編寫(xiě)復(fù)雜的業(yè)務(wù)代碼，或者使用中間件來(lái)協(xié)調(diào)分片間的通信和數(shù)據(jù)傳輸。這樣會(huì)增加開(kāi)發(fā)和維護(hù)的成本，以及影響查詢(xún)的性能和可擴(kuò)展性。

分庫(kù)分表有沒(méi)有什么比較推薦的方案

Apache ShardingSphere是一款分布式的數(shù)據(jù)庫(kù)生態(tài)系統(tǒng)， 可以將任意數(shù)據(jù)庫(kù)轉(zhuǎn)換為分布式數(shù)據(jù)庫(kù)，并通過(guò)數(shù)據(jù)分片、彈性伸縮、加密等能力對(duì)原有數(shù)據(jù)庫(kù)進(jìn)行增強(qiáng)。

ShardingSphere絕對(duì)可以說(shuō)是當(dāng)前分庫(kù)分表的首選！ShardingSphere的功能完善，除了支持讀寫(xiě)分離和分庫(kù)分表，還提供分布式事務(wù)、數(shù)據(jù)庫(kù)治理、影子庫(kù)、數(shù)據(jù)加密和脫敏等功能。ShardingSphere提供的功能如下：

分庫(kù)分表后，數(shù)據(jù)怎么遷移呢

比較簡(jiǎn)單同時(shí)也是非常常用的方案就是停機(jī)遷移，寫(xiě)個(gè)腳本老庫(kù)的數(shù)據(jù)寫(xiě)到新庫(kù)中。比如你在凌晨2點(diǎn)，系統(tǒng)使用的人數(shù)非常少的時(shí)候，掛一個(gè)公告說(shuō)系統(tǒng)要維護(hù)升級(jí)預(yù)計(jì)1小時(shí)。

然后，你寫(xiě)一個(gè)腳本將老庫(kù)的數(shù)據(jù)都同步到新庫(kù)中。如果你不想停機(jī)遷移數(shù)據(jù)的話，也可以考慮雙寫(xiě)方案。雙寫(xiě)方案是針對(duì)那種不能停機(jī)遷移的場(chǎng)景，實(shí)現(xiàn)起來(lái)要稍微麻煩一些。

具體原理是：

• 對(duì)老庫(kù)的更新操作（增刪改）同時(shí)也要寫(xiě)入新庫(kù)（雙寫(xiě)）。如果操作的數(shù)據(jù)不存在于新庫(kù)的話，需要插入到新庫(kù)中。 這樣就能保證，咱們新庫(kù)里的數(shù)據(jù)是最新的。
• 在遷移過(guò)程，雙寫(xiě)只會(huì)讓被更新操作過(guò)的老庫(kù)中的數(shù)據(jù)同步到新庫(kù)，我們還需要自己寫(xiě)腳本將老庫(kù)中的數(shù)據(jù)和新庫(kù)的數(shù)據(jù)做比對(duì)。如果新庫(kù)中沒(méi)有，那咱們就把數(shù)據(jù)插入到新庫(kù)。如果新庫(kù)有，舊庫(kù)沒(méi)有，就把新庫(kù)對(duì)應(yīng)的數(shù)據(jù)刪除（冗余數(shù)據(jù)清理）。
• 重復(fù)上一步的操作，直到老庫(kù)和新庫(kù)的數(shù)據(jù)一致為止。

想要在項(xiàng)目中實(shí)施雙寫(xiě)還是比較麻煩的，很容易會(huì)出現(xiàn)問(wèn)題。我們可以借助上面提到的數(shù)據(jù)庫(kù)同步工具Canal做增量數(shù)據(jù)遷移（還是依賴(lài) binlog，開(kāi)發(fā)和維護(hù)成本較低）。

總結(jié)

• 讀寫(xiě)分離主要是為了將對(duì)數(shù)據(jù)庫(kù)的讀寫(xiě)操作分散到不同的數(shù)據(jù)庫(kù)節(jié)點(diǎn)上。 這樣的話，就能夠小幅提升寫(xiě)性能，大幅提升讀性能。
• 讀寫(xiě)分離基于主從復(fù)制，MySQL主從復(fù)制是依賴(lài)于binlog。
• 分庫(kù)就是將數(shù)據(jù)庫(kù)中的數(shù)據(jù)分散到不同的數(shù)據(jù)庫(kù)上。分表就是對(duì)單表的數(shù)據(jù)進(jìn)行拆分，可以是垂直拆分，也可以是水平拆分。
• 引入分庫(kù)分表之后，需要系統(tǒng)解決事務(wù)、分布式id、無(wú)法join操作問(wèn)題。
• 現(xiàn)在很多公司都是用的類(lèi)似于TiDB這種分布式關(guān)系型數(shù)據(jù)庫(kù)，不需要我們手動(dòng)進(jìn)行分庫(kù)分表，也不需要解決手動(dòng)分庫(kù)分表引入的各種問(wèn)題，直接一步到位，內(nèi)置很多實(shí)用的功能（如無(wú)感擴(kuò)容和縮容、冷熱存儲(chǔ)分離）！如果公司條件允許的話，個(gè)人也是比較推薦這種方式！
• 如果必須要手動(dòng)分庫(kù)分表的話，ShardingSphere是首選！ShardingSphere的功能完善，除了支持讀寫(xiě)分離和分庫(kù)分表，還提供分布式事務(wù)、數(shù)據(jù)庫(kù)治理等功能。另外，ShardingSphere的生態(tài)體系完善，社區(qū)活躍，文檔完善，更新和發(fā)布比較頻繁。

數(shù)據(jù)冷熱分離

什么是數(shù)據(jù)冷熱分離

數(shù)據(jù)冷熱分離是指根據(jù)數(shù)據(jù)的訪問(wèn)頻率和業(yè)務(wù)重要性，將數(shù)據(jù)分為冷數(shù)據(jù)和熱數(shù)據(jù)，冷數(shù)據(jù)一般存儲(chǔ)在存儲(chǔ)在低成本、低性能的介質(zhì)中，熱數(shù)據(jù)高性能存儲(chǔ)介質(zhì)中。

冷數(shù)據(jù)和熱數(shù)據(jù)

熱數(shù)據(jù)是指經(jīng)常被訪問(wèn)和修改且需要快速訪問(wèn)的數(shù)據(jù)，冷數(shù)據(jù)是指不經(jīng)常訪問(wèn)，對(duì)當(dāng)前項(xiàng)目?jī)r(jià)值較低，但需要長(zhǎng)期保存的數(shù)據(jù)。

冷熱數(shù)據(jù)到底如何區(qū)分呢？有兩個(gè)常見(jiàn)的區(qū)分方法：

1. 時(shí)間維度區(qū)分：按照數(shù)據(jù)的創(chuàng)建時(shí)間、更新時(shí)間、過(guò)期時(shí)間等，將一定時(shí)間段內(nèi)的數(shù)據(jù)視為熱數(shù)據(jù)，超過(guò)該時(shí)間段的數(shù)據(jù)視為冷數(shù)據(jù)。例如，訂單系統(tǒng)可以將1年前的訂單數(shù)據(jù)作為冷數(shù)據(jù)，1年內(nèi)的訂單數(shù)據(jù)作為熱數(shù)據(jù)。這種方法適用于數(shù)據(jù)的訪問(wèn)頻率和時(shí)間有較強(qiáng)的相關(guān)性的場(chǎng)景。
2. 訪問(wèn)頻率區(qū)分：將高頻訪問(wèn)的數(shù)據(jù)視為熱數(shù)據(jù)，低頻訪問(wèn)的數(shù)據(jù)視為冷數(shù)據(jù)。例如，內(nèi)容系統(tǒng)可以將瀏覽量非常低的文章作為冷數(shù)據(jù)，瀏覽量較高的文章作為熱數(shù)據(jù)。這種方法需要記錄數(shù)據(jù)的訪問(wèn)頻率，成本較高，適合訪問(wèn)頻率和數(shù)據(jù)本身有較強(qiáng)的相關(guān)性的場(chǎng)景。

幾年前的數(shù)據(jù)并不一定都是熱數(shù)據(jù)，例如一些優(yōu)質(zhì)文章發(fā)表幾年后依然有很多人訪問(wèn)，大部分普通用戶(hù)新發(fā)表的文章卻基本沒(méi)什么人訪問(wèn)。這兩種區(qū)分冷熱數(shù)據(jù)的方法各有優(yōu)劣，

實(shí)際項(xiàng)目中，可以將兩者結(jié)合使用。

冷熱分離的思想

冷熱分離的思想非常簡(jiǎn)單，就是對(duì)數(shù)據(jù)進(jìn)行分類(lèi)，然后分開(kāi)存儲(chǔ)。冷熱分離的思想可以應(yīng)用到很多領(lǐng)域和場(chǎng)景中，而不僅僅是數(shù)據(jù)存儲(chǔ)，例如：

• 郵件系統(tǒng)中，可以將近期的比較重要的郵件放在收件箱，將比較久遠(yuǎn)的不太重要的郵件存入歸檔。
• 日常生活中，可以將常用的物品放在顯眼的位置，不常用的物品放入儲(chǔ)藏室或者閣樓。
• 圖書(shū)館中，可以將最受歡迎和最常借閱的圖書(shū)單獨(dú)放在一個(gè)顯眼的區(qū)域，將較少借閱的書(shū)籍放在不起眼的位置。

數(shù)據(jù)冷熱分離的優(yōu)缺點(diǎn)

• 優(yōu)點(diǎn)：熱數(shù)據(jù)的查詢(xún)性能得到優(yōu)化（用戶(hù)的絕大部分操作體驗(yàn)會(huì)更好）、節(jié)約成本（可以冷熱數(shù)據(jù)的不同存儲(chǔ)需求，選擇對(duì)應(yīng)的數(shù)據(jù)庫(kù)類(lèi)型和硬件配置，比如將熱數(shù)據(jù)放在 SSD 上，將冷數(shù)據(jù)放在HDD上）
• 缺點(diǎn)：系統(tǒng)復(fù)雜性和風(fēng)險(xiǎn)增加（需要分離冷熱數(shù)據(jù)，數(shù)據(jù)錯(cuò)誤的風(fēng)險(xiǎn)增加）、統(tǒng)計(jì)效率低（統(tǒng)計(jì)的時(shí)候可能需要用到冷庫(kù)的數(shù)據(jù)）。

冷數(shù)據(jù)如何遷移

1. 業(yè)務(wù)層代碼實(shí)現(xiàn)：當(dāng)有對(duì)數(shù)據(jù)進(jìn)行寫(xiě)操作時(shí)，觸發(fā)冷熱分離的邏輯，判斷數(shù)據(jù)是冷數(shù)據(jù)還是熱數(shù)據(jù)，冷數(shù)據(jù)就入冷庫(kù)，熱數(shù)據(jù)就入熱庫(kù)。這種方案會(huì)影響性能且冷熱數(shù)據(jù)的判斷邏輯不太好確定，還需要修改業(yè)務(wù)層代碼，因此一般不會(huì)使用。
2. 任務(wù)調(diào)度：可以利用xxl-job或者其他分布式任務(wù)調(diào)度平臺(tái)定時(shí)去掃描數(shù)據(jù)庫(kù)，找出滿足冷數(shù)據(jù)條件的數(shù)據(jù)，然后批量地將其復(fù)制到冷庫(kù)中，并從熱庫(kù)中刪除。這種方法修改的代碼非常少，非常適合按照時(shí)間區(qū)分冷熱數(shù)據(jù)的場(chǎng)景。
3. 監(jiān)聽(tīng)數(shù)據(jù)庫(kù)的變更日志binlog ：將滿足冷數(shù)據(jù)條件的數(shù)據(jù)從binlog中提取出來(lái)，然后復(fù)制到冷庫(kù)中，并從熱庫(kù)中刪除。這種方法可以不用修改代碼，但不適合按照時(shí)間維度區(qū)分冷熱數(shù)據(jù)的場(chǎng)景。

冷數(shù)據(jù)如何存儲(chǔ)

冷數(shù)據(jù)的存儲(chǔ)要求主要是容量大，成本低，可靠性高，訪問(wèn)速度可以適當(dāng)犧牲。

冷數(shù)據(jù)存儲(chǔ)方案：

• 中小廠：直接使用 MySQL/PostgreSQL 即可（不改變數(shù)據(jù)庫(kù)選型和項(xiàng)目當(dāng)前使用的數(shù)據(jù)庫(kù)保持一致），比如新增一張表來(lái)存儲(chǔ)某個(gè)業(yè)務(wù)的冷數(shù)據(jù)或者使用單獨(dú)的冷庫(kù)來(lái)存放冷數(shù)據(jù)（涉及跨庫(kù)查詢(xún)，增加了系統(tǒng)復(fù)雜性和維護(hù)難度）
• 大廠：Hbase（常用）、RocksDB、Doris、Cassandra

如果公司成本預(yù)算足的話，也可以直接上TiDB這種分布式關(guān)系型數(shù)據(jù)庫(kù)，直接一步到位。TiDB6.0 正式支持?jǐn)?shù)據(jù)冷熱存儲(chǔ)分離，可以降低SSD使用成本。使用TiDB 6.0的數(shù)據(jù)放置

功能，可以在同一個(gè)集群實(shí)現(xiàn)海量數(shù)據(jù)的冷熱存儲(chǔ)，將新的熱數(shù)據(jù)存入SSD，歷史冷數(shù)據(jù)存入HDD。