因此，必須對數(shù)據(jù)同步的結(jié)果做校驗(yàn)，保證業(yè)務(wù)邏輯改造正確、數(shù)據(jù)同步一致性正確。這一點(diǎn)非常非常重要。

在本次項(xiàng)目中，存在大量業(yè)務(wù)邏輯優(yōu)化以及字段變動，所以我們單獨(dú)做了一個(gè)校驗(yàn)服務(wù)，對數(shù)據(jù)的全量、增量進(jìn)行校驗(yàn)。

過程中提前發(fā)現(xiàn)了許多數(shù)據(jù)同步、業(yè)務(wù)邏輯的不一致問題，給我們本次項(xiàng)目平穩(wěn)上線提供了最重要的前提保障！！

3.4 最佳實(shí)踐

3.4.1 分庫分表引起的流量放大問題

在做容量評估的時(shí)候，需要關(guān)注一個(gè)重要問題。就是分表帶來的查詢流量放大。

這個(gè)流量放大有兩方面的原因：

• 索引表的二次查詢。比如根據(jù)pk2查詢的，需要先通過pk2查詢pk1，然后根據(jù)pk1查詢返回結(jié)果。
• in的分批查詢。如果一個(gè)select...in...的查詢，數(shù)據(jù)庫中間件會根據(jù)分表鍵，將查詢拆分落到對應(yīng)的物理分表上，相當(dāng)于原本的一次查詢，放大為多次查詢。（當(dāng)然，數(shù)據(jù)庫會將落在同一個(gè)分表的id作為一次批量查詢，而這是不穩(wěn)定的合并）

因此，我們需要注意：

• 業(yè)務(wù)層面盡量限制in查詢數(shù)量，避免流量過于放大；
• 容量評估時(shí)，需要考慮這部分放大因素，做適當(dāng)冗余，另外，后續(xù)會提到業(yè)務(wù)改造上線分批進(jìn)行，保證可以及時(shí)擴(kuò)容；
• 分64、128還是256張表有個(gè)合理預(yù)估，拆得越多，理論上會放大越多，因此不要無謂地分過多的表，根據(jù)業(yè)務(wù)規(guī)模做適當(dāng)估計(jì)；
• 對于映射表的查詢，由于存在明顯的冷熱數(shù)據(jù)，所以我們又在中間加了一層緩存，減少數(shù)據(jù)庫的壓力

3.4.2 分表鍵的變更方案

本項(xiàng)目中，存在一種業(yè)務(wù)情況會變更字段pk3，但是pk3作為分表鍵，在數(shù)據(jù)庫中間件中是不能修改的，因此，只能在中臺中修改對pk3的更新邏輯，采用先刪除、后添加的方式。

這里需要注意，刪除和添加操作的事務(wù)原子性。當(dāng)然，簡單處理也可以通過日志的方式，進(jìn)行告警和校準(zhǔn)。

3.4.3 數(shù)據(jù)同步一致性問題

我們都知道，數(shù)據(jù)同步中一個(gè)關(guān)鍵點(diǎn)就是（消息）數(shù)據(jù)的順序性，如果不能保證接受的數(shù)據(jù)和產(chǎn)生的數(shù)據(jù)的順序嚴(yán)格一致，就有可能因?yàn)椋ㄏⅲ?shù)據(jù)亂序帶來數(shù)據(jù)覆蓋，最終帶來不一致問題。

我們自研的數(shù)據(jù)同步工具底層使用的消息隊(duì)列是kakfa，，kafka對于消息的存儲，只能做到局部有序性（具體來說是每一個(gè)partition的有序）。我們可以把同一主鍵的消息路由至同一分區(qū)，這樣一致性一般可以保證。但是，如果存在一對多的關(guān)系，就無法保證每一行變更有序，見如下例子。

那么需要通過反查數(shù)據(jù)源獲取最新數(shù)據(jù)保證一致性。

但是，反查也不是“銀彈“，需要考慮兩個(gè)問題。

1）如果消息變更來源于讀寫實(shí)例，而反查 數(shù)據(jù)庫是查只讀實(shí)例，那就會存在讀寫實(shí)例延遲導(dǎo)致的數(shù)據(jù)不一致問題。因此，需要保證 消息變更來源 和 反查數(shù)據(jù)庫 的實(shí)例是同一個(gè)。

2）反查對數(shù)據(jù)庫會帶來額外性能開銷，需要仔細(xì)評估全量時(shí)候的影響。

3.4.4 數(shù)據(jù)實(shí)時(shí)性問題

延遲主要需要注意幾方面的問題，并根據(jù)業(yè)務(wù)實(shí)際情況做評估和衡量。

1）數(shù)據(jù)同步平臺的秒級延遲

2）如果消息訂閱和反查數(shù)據(jù)庫都是落在只讀實(shí)例上，那么除了上述數(shù)據(jù)同步平臺的秒級延遲，還會有數(shù)據(jù)庫主從同步的延遲

3）寬表到搜索平臺的秒級延遲

只有能夠滿足業(yè)務(wù)場景的方案，才是合適的方案。

3.4.5 分表后存儲容量優(yōu)化

由于數(shù)據(jù)同步過程中，對于單表而言，不是嚴(yán)格按照遞增插入的，因此會產(chǎn)生很多”存儲空洞“，使得同步完后的存儲總量遠(yuǎn)大于預(yù)估的容量。

因此，在新庫申請的時(shí)候，存儲容量多申請50%。

具體原因可以參考我的這篇文章 為什么MySQL分庫分表后總存儲大小變大了？

3.5 本章小結(jié)

至此，分庫分表的第二階段告一段落。

這一階段踩了非常多的坑。

一方面是設(shè)計(jì)高可用、易擴(kuò)展的存儲架構(gòu)。在項(xiàng)目進(jìn)展過程中，也做了多次的修改與討論，包括mysql數(shù)據(jù)冗余數(shù)量、搜索平臺的索引設(shè)計(jì)、流量放大、分表鍵修改等問題。

另一方面是“數(shù)據(jù)同步”本身是一個(gè)非常復(fù)雜的操作，正如本章最佳實(shí)踐中提及的實(shí)時(shí)性、一致性、一對多等問題，需要引起高度重視。

因此，更加依賴于數(shù)據(jù)校驗(yàn)對最終業(yè)務(wù)邏輯正確、數(shù)據(jù)同步正確的檢驗(yàn)！

在完成這一階段后，可以正式進(jìn)入業(yè)務(wù)切換的階段。需要注意的是，數(shù)據(jù)校驗(yàn)仍然會在下一階段發(fā)揮關(guān)鍵性作用。

4.第三階段：改造和上線（慎重）

前兩個(gè)階段完成后，開始業(yè)務(wù)切換流程，主要步驟如下：

1）中臺服務(wù)采用單讀 雙寫 的模式

2）舊表往新表開著數(shù)據(jù)同步

3） 所有服務(wù)升級依賴的projectDB版本，上線RPC，如果出現(xiàn)問題，降版本即可回滾（上線成功后，單讀新庫，雙寫新舊庫）

4）檢查監(jiān)控確保沒有 中臺服務(wù) 以外的其他服務(wù)訪問舊庫舊表

5）停止數(shù)據(jù)同步

6）刪除舊表

4.1 查詢改造

如何驗(yàn)證我們前兩個(gè)階段設(shè)計(jì)是否合理？能否完全覆蓋查詢的修改 是一個(gè)前提條件。

當(dāng)新表設(shè)計(jì)完畢后，就可以以新表為標(biāo)準(zhǔn)，修改老的查詢。

以本項(xiàng)目為例，需要將舊的sql在 新的中臺服務(wù)中 進(jìn)行改造。

1）讀查詢的改造

可能查詢會涉及以下幾個(gè)方面：

a）根據(jù)查詢條件，需要將pk1和pk2的inner join改為對應(yīng)分表鍵的新表表名

b）部分sql的廢棄字段處理

c）非分表鍵查詢改為走搜索平臺的查詢，注意保證語義一致

d）注意寫單測避免低級錯(cuò)誤，主要是DAO層面。

只有新表結(jié)構(gòu)和存儲架構(gòu)能完全適應(yīng)查詢改造，才能認(rèn)為前面的設(shè)計(jì)暫時(shí)沒有問題。

當(dāng)然，這里還有個(gè)前提條件，就是相關(guān)查詢已經(jīng)全部收攏，沒有遺漏。

2) 寫查詢的改造

除了相關(guān)字段的更改以外，更重要的是，需要改造為舊表、新表的雙寫模式。

這里可能涉及到具體業(yè)務(wù)寫入邏輯，本項(xiàng)目尤為復(fù)雜，需要改造過程中與業(yè)務(wù)方充分溝通，保證寫入邏輯正確。

可以在雙寫上各加一個(gè)配置開關(guān)，方便切換。如果雙寫中發(fā)現(xiàn)新庫寫入有問題，可以快速關(guān)閉。

同時(shí)，雙寫過程中不關(guān)閉 舊庫到新庫 的數(shù)據(jù)同步。

為什么呢？主要還是由于我們項(xiàng)目的特殊性。由于我們涉及到幾十個(gè)服務(wù)，為了降低風(fēng)險(xiǎn)，必須分批上線。因此，存在比較麻煩的中間態(tài)，一部分服務(wù)是老邏輯，一部分服務(wù)是新邏輯，必須保證中間態(tài)的數(shù)據(jù)正確性，具體見4.5.1的分析。

4.2 服務(wù)化改造

為什么需要新建一個(gè) 服務(wù)來 承載改造后的查詢呢？

一方面是為了改造能夠方便的升級與回滾切換，另一方面是為了將查詢收攏，作為一個(gè)中臺化的服務(wù)來提供相應(yīng)的查詢能力。

將改造后的新的查詢放在服務(wù)中，然后jar包中的原本查詢，全部替換成這個(gè)服務(wù)的client調(diào)用。

同時(shí)，升級jar包版本到3.0.0-SNAPSHOT。

4.3 服務(wù)分批上線

為了降低風(fēng)險(xiǎn)，需要安排從非核心服務(wù)到核心服務(wù)的分批上線。

注意，分批上線過程中，由于寫服務(wù)往往是核心服務(wù)，所以安排在后面。可能出現(xiàn)非核心的讀服務(wù)上線了，這時(shí)候會有讀新表、寫舊表的中間狀態(tài)。

1） 所有相關(guān)服務(wù)使用 重構(gòu)分支 升級projectdb版本到3.0.0-SNAPSHOT并部署內(nèi)網(wǎng)環(huán)境；

2） 業(yè)務(wù)服務(wù)依賴于 中臺服務(wù)，需要訂閱服務(wù)

3） 開重構(gòu)分支（不要與正常迭代分支合并），部署內(nèi)網(wǎng)，內(nèi)網(wǎng)預(yù)計(jì)測試兩周以上

使用一個(gè)新的 重構(gòu)分支 是為了在內(nèi)網(wǎng)測試兩周的時(shí)候，不影響業(yè)務(wù)正常迭代。每周更新的業(yè)務(wù)分支可以merge到重構(gòu)分支上部署內(nèi)網(wǎng)，然后外網(wǎng)使用業(yè)務(wù)分支merge到master上部署。

當(dāng)然，如果從線上線下代碼分支一致的角度，也可以重構(gòu)分支和業(yè)務(wù)分支一起測試上線，對開發(fā)和測試的壓力會較大。

4）分批上線過程中，如果碰到依賴沖突的問題，需要及時(shí)解決并及時(shí)更新到該文檔中

5）服務(wù)上線前，必須要求業(yè)務(wù)開發(fā)或者測試，明確評估具體api和風(fēng)險(xiǎn)點(diǎn)，做好回歸。

這里再次提醒，上線完成后，請不要漏掉離線的數(shù)據(jù)分析業(yè)務(wù)！請不要漏掉離線的數(shù)據(jù)分析業(yè)務(wù)！請不要漏掉離線的數(shù)據(jù)分析業(yè)務(wù)！

4.4 舊表下線流程

1）檢查監(jiān)控確保沒有中臺服務(wù)以外的其他服務(wù)訪問舊庫舊表

2）檢查數(shù)據(jù)庫上的sql審計(jì)，確保沒有其他服務(wù)仍然讀取舊表數(shù)據(jù)

3）停止數(shù)據(jù)同步

4）刪除舊表

4.5 最佳實(shí)踐

4.5.1 寫完立即讀可能讀不到

在分批上線過程中，遇到了寫完立即讀可能讀不到的情況。由于業(yè)務(wù)眾多，我們采用了分批上線的方式降低風(fēng)險(xiǎn)，存在一部分應(yīng)用已經(jīng)升級，一部分應(yīng)用尚未升級的情況。未升級的服務(wù)仍然往舊表寫數(shù)據(jù)，而升級后的應(yīng)用會從新表讀數(shù)據(jù)，當(dāng)延遲存在時(shí)，很多新寫入的記錄無法讀到，對具體業(yè)務(wù)場景造成了比較嚴(yán)重的影響。

延遲的原因主要有兩個(gè)：

1）寫服務(wù)還沒有升級，還沒有開始雙寫，還是寫舊表，這時(shí)候會有讀新表、寫舊表的中間狀態(tài)，新舊表存在同步延遲。

2）為了避免主庫壓力，新表數(shù)據(jù)是從舊表獲取變更、然后反查舊表只讀實(shí)例的數(shù)據(jù)進(jìn)行同步的，主從庫本身存在一定延遲。

解決方案一般有兩種：

1）數(shù)據(jù)同步改為雙寫邏輯。

2）在讀接口做補(bǔ)償，如果新表查不到，到舊表再查一次。

4.5.2 數(shù)據(jù)庫中間件唯一ID替換自增主鍵（劃重點(diǎn)，敲黑板）

由于分表后，繼續(xù)使用單表的自增主鍵，會導(dǎo)致全局主鍵沖突。因此，需要使用分布式唯一ID來代替自增主鍵。各種算法網(wǎng)上比較多，本項(xiàng)目采用的是數(shù)據(jù)庫自增sequence生成方式。

數(shù)據(jù)庫自增sequence的分布式ID生成器，是一個(gè)依賴Mysql的存在， 它的基本原理是在Mysql中存入一個(gè)數(shù)值， 每有一臺機(jī)器去獲取ID的時(shí)候，都會在當(dāng)前ID上累加一定的數(shù)量比如說2000， 然后把當(dāng)前的值加上2000返回給服務(wù)器。這樣每一臺機(jī)器都可以繼續(xù)重復(fù)此操作獲得唯一id區(qū)間。

但是僅僅有全局唯一ID就大功告成了嗎？顯然不是，因?yàn)檫@里還會存在新舊表的id沖突問題。

因?yàn)榉?wù)比較多，為了降低風(fēng)險(xiǎn)需要分批上線。因此，存在一部分服務(wù)還是單寫舊表的邏輯，一部分服務(wù)是雙寫的邏輯。

這樣的狀態(tài)中，舊表的id策略使用的是auto_increment。如果只有單向數(shù)據(jù)來往的話（舊表到新表），只需要給舊表的id預(yù)留一個(gè)區(qū)間段，sequence從一個(gè)較大的起始值開始就能避免沖突。

但該項(xiàng)目中，還有新表數(shù)據(jù)和舊表數(shù)據(jù)的雙寫，如果采用上述方案，較大的id寫入到舊表，舊表的auto_increment將會被重置到該值，這樣單鞋舊表的服務(wù)產(chǎn)生的遞增id的記錄必然會出現(xiàn)沖突。

所以這里交換了雙方的區(qū)間段，舊庫從較大的auto_increment起始值開始，新表選擇的id（也就是sequence的范圍）從大于舊表的最大記錄的id開始遞增，小于舊表auto_increment即將設(shè)置的起始值，很好的避免了id沖突問題。

1）切換前：

sequence的起始id設(shè)置為當(dāng)前舊表的自增id大小，然后舊表的自增id需要改大，預(yù)留一段區(qū)間，給舊表的自增id繼續(xù)使用，防止未升級業(yè)務(wù)寫入舊表的數(shù)據(jù)同步到新庫后產(chǎn)生id沖突；

2）切換后

無需任何改造，斷開數(shù)據(jù)同步即可

3）優(yōu)點(diǎn)

只用一份代碼；

切換可以使用開關(guān)進(jìn)行，不用升級改造；

如果萬一中途舊表的autoincrement被異常數(shù)據(jù)變大了，也不會造成什么問題。

4）缺點(diǎn)

如果舊表寫失敗了，新表寫成功了，需要日志輔助處理

4.6 本章小結(jié)

完成舊表下線后，整個(gè)分庫分表的改造就完成了。

在這個(gè)過程中，需要始終保持對線上業(yè)務(wù)的敬畏，仔細(xì)思考每個(gè)可能發(fā)生的問題，想好快速回滾方案（在三個(gè)階段提到了projectdb的jar包版本迭代，從1.0.0-SNAPSHOT到3.0.0-SNAPSHOT，包含了每個(gè)階段不同的變更，在不同階段的分批上線的過程中，通過jar包版本的方式進(jìn)行回滾，發(fā)揮了巨大作用），避免造成重大故障。

5.穩(wěn)定性保障

這一章主要再次強(qiáng)調(diào)穩(wěn)定性的保障手段。作為本次項(xiàng)目的重要目標(biāo)之一，穩(wěn)定性其實(shí)貫穿在整個(gè)項(xiàng)目周期內(nèi)，基本上在上文各個(gè)環(huán)節(jié)都已經(jīng)都有提到，每一個(gè)環(huán)節(jié)都要引起足夠的重視，仔細(xì)設(shè)計(jì)和評估方案，做到心中有數(shù)，而不是靠天吃飯：

1）新表設(shè)計(jì)必須跟業(yè)務(wù)方充分溝通、保證review。

2）對于“數(shù)據(jù)同步”，必須有數(shù)據(jù)校驗(yàn)保障數(shù)據(jù)正確性，可能導(dǎo)致數(shù)據(jù)不正確的原因上文已經(jīng)提到來很多，包括實(shí)時(shí)性、一致性的問題。保證數(shù)據(jù)正確是上線的大前提。

3）每一階段的變動，都必須做好快速回滾都預(yù)案。

4）上線過程，都以分批上線的形式，從非核心業(yè)務(wù)開始做試點(diǎn)，避免故障擴(kuò)大。

5）監(jiān)控告警要配置全面，出現(xiàn)問題及時(shí)收到告警，快速響應(yīng)。不要忽略，很重要，有幾次出現(xiàn)選過數(shù)據(jù)的小問題，都是通過告警及時(shí)發(fā)現(xiàn)和解決的

6）單測，業(yè)務(wù)功能測試等要充分

6.項(xiàng)目管理之跨團(tuán)隊(duì)協(xié)作

關(guān)于“跨團(tuán)隊(duì)協(xié)作”，本文專門拎出來作為一章。

因?yàn)樵谶@樣一個(gè)跨團(tuán)隊(duì)的大型項(xiàng)目改造過程中，科學(xué)的團(tuán)隊(duì)協(xié)作是保障整體項(xiàng)目按時(shí)、高質(zhì)量完成的不可缺少的因素。

下面，分享幾點(diǎn)心得與體會。

6.1 一切文檔先行

團(tuán)隊(duì)協(xié)作最忌“空口無憑”。

無論是團(tuán)隊(duì)分工、進(jìn)度安排或是任何需要多人協(xié)作的事情，都需要有一個(gè)文檔記錄，用于追蹤進(jìn)度，把控流程。

6.2 業(yè)務(wù)溝通與確認(rèn)

所有的表結(jié)構(gòu)改造，必須跟相關(guān)業(yè)務(wù)方溝通，對于可能存在的歷史邏輯，進(jìn)行全面梳理；

所有討論確定后的字段改造，必須由每個(gè)服務(wù)的Owner進(jìn)行確認(rèn)。

6.3 責(zé)任到位

對于多團(tuán)隊(duì)多人次的合作項(xiàng)目，每個(gè)團(tuán)隊(duì)都應(yīng)該明確一個(gè)對接人，由項(xiàng)目總負(fù)責(zé)人與團(tuán)隊(duì)唯一對接人溝通，明確團(tuán)隊(duì)完整進(jìn)度和完成質(zhì)量。

7.展望

其實(shí)，從全文的篇幅就能夠看出，本次的分庫分表項(xiàng)目由于復(fù)雜的業(yè)務(wù)邏輯改造，費(fèi)大量的時(shí)間和精力，并且非常容易在改造過程中，引起不穩(wěn)定的線上問題。

本文復(fù)盤了整個(gè)分庫分表從拆分、設(shè)計(jì)、上線的整體過程，希望能對大家有所幫助。

看到這里，我們會想問一句。所以，有沒有更好的方式呢？

也許，未來還是需要去結(jié)合業(yè)界新的數(shù)據(jù)庫中間件技術(shù)，能夠快速實(shí)現(xiàn)分庫分表。

也許，未來還可以引入新的數(shù)據(jù)存儲技術(shù)與方案（polardb、tidb、hbase），根本不再需要分庫分表呢？

繼續(xù)跟進(jìn)新技術(shù)的發(fā)展，我相信會找到答案。

希望能得到您的 關(guān)注、評論、轉(zhuǎn)發(fā)，謝謝！

阿丸把 Canal源碼解析與實(shí)戰(zhàn)筆記、HBase原理與實(shí)戰(zhàn)筆記、MySQL實(shí)戰(zhàn)筆記、JAVA實(shí)戰(zhàn)技巧筆記等整理為合集，全是原創(chuàng)手打干貨，現(xiàn)在免費(fèi)送給大家。

關(guān)注我，私信回復(fù)【資料】即可獲得。