分庫分表的文章網上很是多，可是大多內容比較零散，以講解知識點爲主，沒有完整地說明一個大表的切分、新架構設計、上線的完整過程。mysql
所以，我結合去年作的一個大型分庫分表項目，來複盤一下完整的分庫分表從架構設計 到 發佈上線的實戰總結。算法
1.前言
爲何須要作分庫分表。這個相信你們多少都有所瞭解。sql
海量數據的存儲和訪問成爲了MySQL數據庫的瓶頸問題，日益增加的業務數據，無疑對MySQL數據庫形成了至關大的負載，同時對於系統的穩定性和擴展性提出很高的要求。數據庫
並且單臺服務器的資源（CPU、磁盤、內存等）老是有限的，最終數據庫所能承載的數據量、數據處理能力都將遭遇瓶頸。api
目前來講通常有兩種方案。緩存
1）一種是更換存儲，不使用MySQL，好比可使用HBase、polarDB、TiDB等分佈式存儲。服務器
2）若是出於各類緣由考慮，仍是想繼續使用MySQL，通常會採用第二種方式，那就是分庫分表。微信
文章開頭就說了，網上分庫分表文章不少，對知識點講解比較多，所以，本文將再也不過多贅述分庫分表方案的範式處理。架構
而是專一於梳理分庫分表從架構設計 到 發佈上線的完整過程，同時總結其中的注意事項和最佳實踐。包括五個部分：app
業務重構
存儲架構設計
改造和上線
穩定性保障
項目管理
尤爲是各個階段的最佳實踐，都是血與淚凝聚的經驗教訓。
2.第一階段：業務重構（可選）
對於微服務劃分比較合理的分庫分錶行爲，通常只須要關注存儲架構的變化，或者只須要在個別應用上進行業務改造便可，通常不須要着重考慮「業務重構」 這一階段，所以，這一階段屬於「可選」。
本次項目的第一大難點，在於業務重構。
而本次拆分項目涉及到的兩張大表A和B，單表將近八千萬的數據，是從單體應用時代遺留下來的，從一開始就沒有很好的領域驅動/MSA架構設計，邏輯發散很是嚴重，到如今已經涉及50+個在線服務和20+個離線業務的的直接讀寫。
所以，如何保證業務改造的完全性、全面性是重中之重，不能出現有遺漏的狀況。
另外，表A 和 表B 各自有2、三十個字段，兩表的主鍵存在一一對應關係，所以，本次分庫分表項目中，還須要將兩個表進行重構融合，將多餘/無用的字段剔除。
2.1 查詢統計
在線業務經過分佈式鏈路追蹤系統進行查詢，按照表名做爲查詢條件，而後按照服務維度進行聚合，找到全部相關服務，寫一個文檔記錄相關團隊和服務。
這裏特別注意下，不少表不是隻有在線應用在使用，不少離線算法和數據分析的業務也在使用，這裏須要一併的梳理好，作好線下跨團隊的溝通和調研工做，以避免切換後影響正常的數據分析。
2.2 查詢拆分與遷移
建立一個jar包，根據2.1的統計結果，與服務owner合做將服務中的相關查詢都遷移到這個jar包中（本項目的jar包叫projected）。
此處爲1.0.0-SNAPSHOT版本。
而後將本來服務內的xxxMapper.xxxMethod( ) 所有改爲projectdb.xxxMethod( )進行調用。
這樣作有兩個好處：
方便作後續的查詢拆分分析。
方便後續直接將jar包中的查詢替換爲改造後 中臺服務 的rpc調用，業務方只需升級jar包版本，便可快速從sql調用改成rpc查詢。
這一步花了幾個月的實際，務必梳理各個服務作全面的遷移，不能遺漏，不然可能會致使拆分分析不全面，遺漏了相關字段。
查詢的遷移主要因爲本次拆分項目涉及到的服務太多，須要收攏到一個jar包，更方便後期的改造。若是實際分庫分表項目中僅僅涉及一兩個服務的，這一步是能夠不作的。
2.3 聯合查詢的拆分分析
根據2.2收攏的jar包中的查詢，結合實際狀況將查詢進行分類和判斷，把一些歷史遺留的問題，和已經廢棄的字段作一些整理。
如下舉一些思考點。
1）哪些查詢是沒法拆分的？例如分頁（儘量地改造，實在改不了只能以冗餘列的形式）
2）哪些查詢是能夠業務上join拆分的？
3）哪些表/字段是能夠融合的？
4）哪些字段須要冗餘？
5）哪些字段能夠直接廢棄了？
6）根據業務具體場景和sql總體統計，識別關鍵的分表鍵。其他查詢走搜索平臺。
思考後獲得一個查詢改造整體思路和方案。
同時在本項目中須要將兩張表融合爲一張表，廢棄冗餘字段和無效字段。
2.4 新表設計
這一步基於2.3對於查詢的拆分分析，得出舊錶融合、冗餘、廢棄字段的結果，設計新表的字段。
產出新表設計結構後，必須發給各個相關業務方進行review，並保證全部業務方都經過該表的設計。有必要的話能夠進行一次線下review。
若是新表的過程當中，對部分字段進行了廢棄，必須通知全部業務方進行確認。
對於新表的設計，除了字段的梳理，也須要根據具體查詢，從新設計、優化索引。
2.5 第一次升級
新表設計完成後，先作一次jar包內sql查詢的改造，將舊的字段所有更新爲新表的字段。
此處爲2.0.0-SNAPSHOT版本。
而後讓全部服務升級jar包版本，以此來保證這些廢棄字段確實是不使用了，新的表結構字段可以徹底覆蓋過去的業務場景。
特別注意的是，因爲涉及服務衆多，能夠將服務按照 非核心 與 核心 區分，而後分批次上線，避免出現問題致使嚴重故障或者大範圍回滾。
2.6 最佳實踐
2.6.1 儘可能不改變原表的字段名稱
在作新表融合的時候，一開始只是簡單歸併表A 和 表B的表，所以不少字段名相同的字段作了重命名。
後來字段精簡過程當中，刪除了不少重複字段，可是沒有將重命名的字段改回來。
致使後期上線的過程當中，不可避免地須要業務方進行重構字段名。
所以，新表設計的時候，除非必不得已，不要修改原表的字段名稱！
2.6.2 新表的索引須要仔細斟酌
新表的索引不能簡單照搬舊錶，而是須要根據查詢拆分分析後，從新設計。
尤爲是一些字段的融合後，可能能夠歸併一些索引，或者設計一些更高性能的索引。
2.6 本章小結
至此，分庫分表的第一階段告一段落。這一階段所需時間，徹底取決於具體業務，若是是一個歷史包袱沉重的業務，那可能須要花費幾個月甚至半年的時間才能完成。
這一階段的完成質量很是重要，不然可能致使項目後期須要重建表結構、從新全量數據。
這裏再次說明，對於微服務劃分比較合理的服務，分庫分錶行爲通常只須要關注存儲架構的變化，或者只須要在個別應用上進行業務改造便可，通常不須要着重考慮「業務重構」 這一階段。
3.第二階段：存儲架構設計（核心）
對於任何分庫分表的項目，存儲架構的設計都是最核心的部分！
3.1 總體架構
根據第一階段整理的查詢梳理結果，咱們總結了這樣的查詢規律。
80%以上的查詢都是經過或者帶有字段pk一、字段pk二、字段pk3這三個維度進行查詢的，其中pk1和pk2因爲歷史緣由存在一一對應的關係
20%的查詢千奇百怪，包括模糊查詢、其餘字段查詢等等
所以，咱們設計了以下的總體架構，引入了數據庫中間件、數據同步工具、搜索引擎（阿里雲opensearch/ES）等。
下文的論述都是圍繞這個架構來展開的。
3.1.1 mysql分表存儲
Mysql分表的維度是根據查詢拆分分析的結果肯定的。
咱們發現pk1\pk2\pk3能夠覆蓋80%以上的主要查詢。讓這些查詢根據分表鍵直接走mysql數據庫便可。
原則上通常最多維護一個分表的全量數據，由於過多的全量數據會形成存儲的浪費、數據同步的額外開銷、更多的不穩定性、不易擴展等問題。
可是因爲本項目pk1和pk3的查詢語句都對實時性有比較高的要求，所以，維護了pk1和pk3做爲分表鍵的兩份全量數據。
而pk2和pk1因爲歷史緣由，存在一一對應關係，能夠僅保留一份映射表便可，只存儲pk1和pk2兩個字段。
3.1.2 搜索平臺索引存儲
搜索平臺索引，能夠覆蓋剩餘20%的零散查詢。
這些查詢每每不是根據分表鍵進行的，或者是帶有模糊查詢的要求。
對於搜索平臺來講，通常不存儲全量數據（尤爲是一些大varchar字段），只存儲主鍵和查詢須要的索引字段，搜索獲得結果後，根據主鍵去mysql存儲中拿到須要的記錄。
固然，從後期實踐結果來看，這裏仍是須要作一些權衡的：
1）有些非索引字段，若是不是很大，也能夠冗餘進來，相似覆蓋索引，避免多一次sql查詢；
2）若是表結構比較簡單，字段不大，甚至能夠考慮全量存儲，提升查詢性能，下降mysql數據庫的壓力。
這裏特別提示，搜索引擎和數據庫之間同步是必然存在延遲的。因此對於根據分表id查詢的語句，儘可能保證直接查詢數據庫，這樣不會帶來一致性問題的隱患。
3.1.3 數據同步
通常新表和舊錶直接能夠採用 數據同步 或者 雙寫的方式進行處理，兩種方式有各自的優缺點。
通常根據具體狀況選擇一種方式就行。
本次項目的具體同步關係見總體存儲架構，包括了四個部分：
1）舊錶到新表全量主表的同步
一開始爲了減小代碼入侵、方便擴展，採用了數據同步的方式。並且因爲業務過多，擔憂有未統計到的服務沒有及時改造，因此數據同步能避免這些狀況致使數據丟失。
可是在上線過程當中發現，當延遲存在時，不少新寫入的記錄沒法讀到，對具體業務場景形成了比較嚴重的影響。（具體緣由參考4.5.1的說明）
所以，爲了知足應用對於實時性的要求，咱們在數據同步的基礎上，從新在3.0.0-SNAPSHOT版本中改形成了雙寫的形式。
2）新表全量主表到全量副表的同步
3）新表全量主表到映射表到同步
4）新表全量主表到搜索引擎數據源的同步
2）、3）、4）都是重新表全量主表到其餘數據源的數據同步，由於沒有強實時性的要求，所以，爲了方便擴展，所有采用了數據同步的方式，沒有進行更多的多寫操做。
3.2 容量評估
在申請mysql存儲和搜索平臺索引資源前，須要進行容量評估，包括存儲容量和性能指標。
具體線上流量評估能夠經過監控系統查看qps，存儲容量能夠簡單認爲是線上各個表存儲容量的和。
可是在全量同步過程當中，咱們發現須要的實際容量的需求會大於預估，具體能夠看3.4.6的說明。
具體性能壓測過程就再也不贅述。
3.3 數據校驗
從上文能夠看到，在本次項目中，存在大量的業務改造，屬於異構遷移。
從過去的一些分庫分表項目來講，大可能是同構/對等拆分，所以不會存在不少複雜邏輯，因此對於數據遷移的校驗每每比較忽視。
在徹底對等遷移的狀況下，通常確實比較少出現問題。
可是，相似這樣有比較多改造的異構遷移，校驗絕對是重中之重！！
所以，必須對數據同步的結果作校驗，保證業務邏輯改造正確、數據同步一致性正確。這一點很是很是重要。
在本次項目中，存在大量業務邏輯優化以及字段變更，因此咱們單獨作了一個校驗服務，對數據的全量、增量進行校驗。
過程當中提早發現了許多數據同步、業務邏輯的不一致問題，給咱們本次項目平穩上線提供了最重要的前提保障！！
3.4 最佳實踐
3.4.1 分庫分表引發的流量放大問題
在作容量評估的時候，須要關注一個重要問題。就是分錶帶來的查詢流量放大。
這個流量放大有兩方面的緣由：
索引表的二次查詢。好比根據pk2查詢的，須要先經過pk2查詢pk1，而後根據pk1查詢返回結果。
in的分批查詢。若是一個select...in...的查詢，數據庫中間件會根據分表鍵，將查詢拆分落到對應的物理分表上，至關於本來的一次查詢，放大爲屢次查詢。（固然，數據庫會將落在同一個分表的id做爲一次批量查詢，而這是不穩定的合併）
所以，咱們須要注意：
業務層面儘可能限制in查詢數量，避免流量過於放大；
容量評估時，須要考慮這部分放大因素，作適當冗餘，另外，後續會提到業務改造上線分批進行，保證能夠及時擴容；
分6四、128仍是256張表有個合理預估，拆得越多，理論上會放大越多，所以不要無謂地分過多的表，根據業務規模作適當估計；
對於映射表的查詢，因爲存在明顯的冷熱數據，因此咱們又在中間加了一層緩存，減小數據庫的壓力
3.4.2 分表鍵的變動方案
本項目中，存在一種業務狀況會變動字段pk3，可是pk3做爲分表鍵，在數據庫中間件中是不能修改的，所以，只能在中臺中修改對pk3的更新邏輯，採用先刪除、後添加的方式。
這裏須要注意，刪除和添加操做的事務原子性。固然，簡單處理也能夠經過日誌的方式，進行告警和校準。
3.4.3 數據同步一致性問題
咱們都知道，數據同步中一個關鍵點就是（消息）數據的順序性，若是不能保證接受的數據和產生的數據的順序嚴格一致，就有可能由於（消息）數據亂序帶來數據覆蓋，最終帶來不一致問題。
咱們自研的數據同步工具底層使用的消息隊列是kakfa，，kafka對於消息的存儲，只能作到局部有序性（具體來講是每個partition的有序）。咱們能夠把同一主鍵的消息路由至同一分區，這樣一致性通常能夠保證。可是，若是存在一對多的關係，就沒法保證每一行變動有序，見以下例子。
那麼須要經過反查數據源獲取最新數據保證一致性。
可是，反查也不是「銀彈「，須要考慮兩個問題。
1）若是消息變動來源於讀寫實例，而反查 數據庫是查只讀實例，那就會存在讀寫實例延遲致使的數據不一致問題。所以，須要保證 消息變動來源 和 反查數據庫 的實例是同一個。
2）反查對數據庫會帶來額外性能開銷，須要仔細評估全量時候的影響。
3.4.4 數據實時性問題
延遲主要須要注意幾方面的問題，並根據業務實際狀況作評估和衡量。
1）數據同步平臺的秒級延遲
2）若是消息訂閱和反查數據庫都是落在只讀實例上，那麼除了上述數據同步平臺的秒級延遲，還會有數據庫主從同步的延遲
3）寬表到搜索平臺的秒級延遲
只有可以知足業務場景的方案，纔是合適的方案。
3.4.5 分表後存儲容量優化
因爲數據同步過程當中，對於單表而言，不是嚴格按照遞增插入的，所以會產生不少」存儲空洞「，使得同步完後的存儲總量遠大於預估的容量。
所以，在新庫申請的時候，存儲容量多申請50%。
具體緣由能夠參考個人這篇文章 爲何MySQL分庫分表後總存儲大小變大了？
3.5 本章小結
至此，分庫分表的第二階段告一段落。
這一階段踩了很是多的坑。
一方面是設計高可用、易擴展的存儲架構。在項目進展過程當中，也作了屢次的修改與討論，包括mysql數據冗餘數量、搜索平臺的索引設計、流量放大、分表鍵修改等問題。
另外一方面是「數據同步」自己是一個很是複雜的操做，正如本章最佳實踐中說起的實時性、一致性、一對多等問題，須要引發高度重視。
所以，更加依賴於數據校驗對最終業務邏輯正確、數據同步正確的檢驗！
在完成這一階段後，能夠正式進入業務切換的階段。須要注意的是，數據校驗仍然會在下一階段發揮關鍵性做用。
4.第三階段：改造和上線（慎重）
前兩個階段完成後，開始業務切換流程，主要步驟以下：
1）中臺服務採用單讀 雙寫 的模式
2）舊錶往新表開着數據同步
3） 全部服務升級依賴的projectDB版本，上線RPC，若是出現問題，降版本便可回滾（上線成功後，單讀新庫，雙寫新舊庫）
4）檢查監控確保沒有 中臺服務 之外的其餘服務訪問舊庫舊錶
5）中止數據同步
6）刪除舊錶
4.1 查詢改造
如何驗證咱們前兩個階段設計是否合理？可否徹底覆蓋查詢的修改 是一個前提條件。
當新表設計完畢後，就能夠以新表爲標準，修改老的查詢。
以本項目爲例，須要將舊的sql在 新的中臺服務中 進行改造。
1）讀查詢的改造
可能查詢會涉及如下幾個方面：
a）根據查詢條件，須要將pk1和pk2的inner join改成對應分表鍵的新表表名
b）部分sql的廢棄字段處理
c）非分表鍵查詢改成走搜索平臺的查詢，注意保證語義一致
d）注意寫單測避免低級錯誤，主要是DAO層面。
只有新表結構和存儲架構能徹底適應查詢改造，才能認爲前面的設計暫時沒有問題。
固然，這裏還有個前提條件，就是相關查詢已經所有收攏，沒有遺漏。
2) 寫查詢的改造
除了相關字段的更改之外，更重要的是，須要改造爲舊錶、新表的雙寫模式。
這裏可能涉及到具體業務寫入邏輯，本項目尤其複雜，須要改造過程當中與業務方充分溝通，保證寫入邏輯正確。
能夠在雙寫上各加一個配置開關，方便切換。若是雙寫中發現新庫寫入有問題，能夠快速關閉。
同時，雙寫過程當中不關閉 舊庫到新庫 的數據同步。
爲何呢？主要仍是因爲咱們項目的特殊性。因爲咱們涉及到幾十個服務，爲了下降風險，必須分批上線。所以，存在比較麻煩的中間態，一部分服務是老邏輯，一部分服務是新邏輯，必須保證中間態的數據正確性，具體見4.5.1的分析。
4.2 服務化改造
爲何須要新建一個 服務來 承載改造後的查詢呢？
一方面是爲了改造可以方便的升級與回滾切換，另外一方面是爲了將查詢收攏，做爲一箇中臺化的服務來提供相應的查詢能力。
將改造後的新的查詢放在服務中，而後jar包中的本來查詢，所有替換成這個服務的client調用。
同時，升級jar包版本到3.0.0-SNAPSHOT。
4.3 服務分批上線
爲了下降風險，須要安排從非核心服務到核心服務的分批上線。
注意，分批上線過程當中，因爲寫服務每每是核心服務，因此安排在後面。可能出現非核心的讀服務上線了，這時候會有讀新表、寫舊錶的中間狀態。
1） 全部相關服務使用 重構分支 升級projectdb版本到3.0.0-SNAPSHOT並部署內網環境；
2） 業務服務依賴於 中臺服務，須要訂閱服務
3） 開重構分支（不要與正常迭代分支合併），部署內網，內網預計測試兩週以上
使用一個新的 重構分支 是爲了在內網測試兩週的時候，不影響業務正常迭代。每週更新的業務分支能夠merge到重構分支上部署內網，而後外網使用業務分支merge到master上部署。
固然，若是從線上線下代碼分支一致的角度，也能夠重構分支和業務分支一塊兒測試上線，對開發和測試的壓力會較大。
4）分批上線過程當中，若是碰到依賴衝突的問題，須要及時解決並及時更新到該文檔中
5）服務上線前，必需要求業務開發或者測試，明確評估具體api和風險點，作好迴歸。
這裏再次提醒，上線完成後，請不要漏掉離線的數據分析業務！請不要漏掉離線的數據分析業務！請不要漏掉離線的數據分析業務！
4.4 舊錶下線流程
1）檢查監控確保沒有中臺服務之外的其餘服務訪問舊庫舊錶
2）檢查數據庫上的sql審計，確保沒有其餘服務仍然讀取舊錶數據
3）中止數據同步
4）刪除舊錶
4.5 最佳實踐
4.5.1 寫完當即讀可能讀不到
在分批上線過程當中，遇到了寫完當即讀可能讀不到的狀況。因爲業務衆多，咱們採用了分批上線的方式下降風險，存在一部分應用已經升級，一部分應用還沒有升級的狀況。未升級的服務仍然往舊錶寫數據，而升級後的應用會重新表讀數據，當延遲存在時，不少新寫入的記錄沒法讀到，對具體業務場景形成了比較嚴重的影響。
延遲的緣由主要有兩個：
1）寫服務尚未升級，尚未開始雙寫，仍是寫舊錶，這時候會有讀新表、寫舊錶的中間狀態，新舊錶存在同步延遲。
2）爲了不主庫壓力，新表數據是從舊錶獲取變動、而後反查舊錶只讀實例的數據進行同步的，主從庫自己存在必定延遲。
解決方案通常有兩種：
1）數據同步改成雙寫邏輯。
2）在讀接口作補償，若是新表查不到，到舊錶再查一次。
4.5.2 數據庫中間件惟一ID替換自增主鍵（劃重點，敲黑板）
因爲分表後，繼續使用單表的自增主鍵，會致使全局主鍵衝突。所以，須要使用分佈式惟一ID來代替自增主鍵。各類算法網上比較多，本項目採用的是數據庫自增sequence生成方式。
數據庫自增sequence的分佈式ID生成器，是一個依賴Mysql的存在， 它的基本原理是在Mysql中存入一個數值， 每有一臺機器去獲取ID的時候，都會在當前ID上累加必定的數量好比說2000， 而後把當前的值加上2000返回給服務器。這樣每一臺機器均可以繼續重複此操做得到惟一id區間。
可是僅僅有全局惟一ID就大功告成了嗎？顯然不是，由於這裏還會存在新舊錶的id衝突問題。
由於服務比較多，爲了下降風險須要分批上線。所以，存在一部分服務仍是單寫舊錶的邏輯，一部分服務是雙寫的邏輯。
這樣的狀態中，舊錶的id策略使用的是auto_increment。若是隻有單向數據來往的話（舊錶到新表），只須要給舊錶的id預留一個區間段，sequence從一個較大的起始值開始就能避免衝突。
但該項目中，還有新表數據和舊錶數據的雙寫，若是採用上述方案，較大的id寫入到舊錶，舊錶的auto_increment將會被重置到該值，這樣單寫舊錶的服務產生的遞增id的記錄必然會出現衝突。
因此這裏交換了雙方的區間段，舊庫從較大的auto_increment起始值開始，新表選擇的id（也就是sequence的範圍）從大於舊錶的最大記錄的id開始遞增，小於舊錶auto_increment即將設置的起始值，很好的避免了id衝突問題。
1）切換前：
sequence的起始id設置爲當前舊錶的自增id大小，而後舊錶的自增id須要改大，預留一段區間，給舊錶的自增id繼續使用，防止未升級業務寫入舊錶的數據同步到新庫後產生id衝突；
2）切換後
無需任何改造，斷開數據同步便可
3）優勢
只用一份代碼；
切換可使用開關進行，不用升級改造；
若是萬一中途舊錶的autoincrement被異常數據變大了，也不會形成什麼問題。
4）缺點
若是舊錶寫失敗了，新表寫成功了，須要日誌輔助處理
4.6 本章小結
完成舊錶下線後，整個分庫分表的改造就完成了。
在這個過程當中，須要始終保持對線上業務的敬畏，仔細思考每一個可能發生的問題，想好快速回滾方案（在三個階段提到了projectdb的jar包版本迭代，從1.0.0-SNAPSHOT到3.0.0-SNAPSHOT，包含了每一個階段不一樣的變動，在不一樣階段的分批上線的過程當中，經過jar包版本的方式進行回滾，發揮了巨大做用），避免形成重大故障。
5.穩定性保障
這一章主要再次強調穩定性的保障手段。做爲本次項目的重要目標之一，穩定性其實貫穿在整個項目週期內，基本上在上文各個環節都已經都有提到，每個環節都要引發足夠的重視，仔細設計和評估方案，作到心中有數，而不是靠天吃飯：
1）新表設計必須跟業務方充分溝通、保證review。
2）對於「數據同步」，必須有數據校驗保障數據正確性，可能致使數據不正確的緣由上文已經提到來不少，包括實時性、一致性的問題。保證數據正確是上線的大前提。
3）每一階段的變更，都必須作好快速回滾都預案。
4）上線過程，都以分批上線的形式，從非核心業務開始作試點，避免故障擴大。
5）監控告警要配置全面，出現問題及時收到告警，快速響應。不要忽略，很重要，有幾回出現過數據的問題，都是經過告警及時發現和解決的。6）單測，業務功能測試等要充分
6.項目管理之跨團隊協做
關於「跨團隊協做」，本文專門拎出來做爲一章。
由於在這樣一個跨團隊的大型項目改造過程當中，科學的團隊協做是保障總體項目按時、高質量完成的不可缺乏的因素。
下面，分享幾點心得與體會。
6.1 一切文檔先行
團隊協做最忌「空口無憑」。
不管是團隊分工、進度安排或是任何須要多人協做的事情，都須要有一個文檔記錄，用於追蹤進度，把控流程。
6.2 業務溝通與確認
全部的表結構改造，必須跟相關業務方溝通，對於可能存在的歷史邏輯，進行全面梳理；
全部討論肯定後的字段改造，必須由每一個服務的Owner進行確認。
6.3 責任到位
對於多團隊多人次的合做項目，每一個團隊都應該明確一個對接人，由項目總負責人與團隊惟一對接人溝通，明確團隊完整進度和完成質量。
7.展望
其實，從全文的篇幅就可以看出，本次的分庫分表項目因爲複雜的業務邏輯改造，費大量的時間和精力，而且很是容易在改造過程當中，引發不穩定的線上問題。
本文覆盤了整個分庫分表從拆分、設計、上線的總體過程，但願能對你們有所幫助。
看到這裏，咱們會想問一句。因此，有沒有更好的方式呢？
也許，將來仍是須要去結合業界新的數據庫中間件技術，可以快速實現分庫分表。
也許，將來還能夠引入新的數據存儲技術與方案（polardb、tidb、hbase），根本再也不須要分庫分表呢？
繼續跟進新技術的發展，我相信會找到答案。
原創：阿丸筆記（微信公衆號：aone_note），歡迎 分享，轉載請保留出處。
掃描下方二維碼能夠關注我哦～
本文分享自微信公衆號 - 阿丸筆記（aone_note）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。