萬億級資料的方法，簡單易懂！

背景

在星爺的《大話西遊》中有一句非常出名的臺詞：“曾經有一份真摯的感情擺在我的面前我沒有珍惜，等我失去的時候才追悔莫及，人間最痛苦的事莫過於此，如果上天能給我一次再來一次的機會，我會對哪個女孩說三個字：我愛你，如果非要在這份愛上加一個期限，我希望是一萬年！”在我們開發人員的眼中，這個感情就和我們資料庫中的資料一樣，我們多希望他一萬年都不改變，但是往往事與願違，隨著公司的不斷髮展，業務的不斷變更，我們對資料的要求也在不斷的變化，大概有下面的幾種情況：

分庫分表：業務發展越來越快，導致單機資料庫承受的壓力越來越大，資料量也越來越多，這個時候通常會使用分庫的方法去解決這個問題，將資料庫的流量均分到不同的機器上。從單機資料庫到分庫這個過程，我們就需要完整的遷移我們的資料，我們才能成功的分庫的方式上使用我們的資料。
更換儲存介質：上面介紹的分庫，一般來說我們遷移完之後，儲存介質依然是同樣的，比如說之前使用的是單機Mysql，分庫之後就變成了多臺機器的Mysql，我們的資料庫表的欄位都沒有發生變化,遷移來說相對比較簡單。有時候我們分庫分表並不能解決所有的問題，如果我們需要很多複雜的查詢，這個時候使用Mysql可能就不是一個靠譜的方案，那麼我們就需要替換查詢的儲存介質，比如使用elasticsearch，這種的遷移就會稍微要複雜一些，涉及到不同儲存介質的資料轉換。
切換新系統：一般公司在高速發展中，一定會出現很多為了速度快然後重複建設的專案，當公司再一定時間段的時候，往往這部分專案會被合併，變成一個平臺或者中臺，比如我們一些會員系統，電商系統等等。這個時候往往就會面臨一個問題，將老的系統中的資料需要遷移到新的系統中，這個時候就更加複雜了，有可能不僅是儲存介質有變動，有可能專案語言也不同，從更上層的角度來看，部門有可能也不同，所以這種資料遷移的難度是比較高，風險也更加的大。
在實際業務開發中，我們會根據不同的情況來做出不同的遷移方案，接下來我們來討論一下到底應該怎麼遷移資料。

資料遷移

資料遷移其實不是一蹴而就的，每一次資料遷移都需要一段漫長的時間，有可能是一週，有可能是幾個月，通常來說我們遷移資料的過程基本都和下圖差不多：

首先我們需要將我們資料庫已經存在的資料進行批量的遷移，然後需要處理新增的這部分資料，需要實時的把這部分資料在寫完原本的資料庫之後然後寫到我們的新的儲存，在這一過程中我們需要不斷的進行資料校驗。當我們校驗基本問題不大的時候，然後進行切流操作，直到完全切流之後，我們就可以不用再進行資料校驗和增量資料遷移。

存量資料遷移

首先我們來說一下存量資料遷移應該怎麼做，存量資料遷移在開源社群中搜尋了一圈發現沒有太好用的工具，目前來說阿里雲的DTS提供了存量資料遷移，DTS支援同構和異構不同資料來源之間的遷移，基本支援業界常見的資料庫比如Mysql,Orcale,SQL Server等等。DTS比較適合我們之前說的前兩個場景，一個是分庫的場景，如果使用的是阿里雲的DRDS那麼就可以直接將資料通過DTS遷移到DRDS,另外一個是資料異構的場景，無論是Redis還是ES，DTS都支援直接進行遷移。

那麼DTS的存量遷移怎麼做的呢？其實比較簡單大概就是下面幾個步驟：

當存量遷移任務啟動的時候，我們獲取當前需要遷移的最大的id和最小id
設定一個分段，比如1萬，從最小id開始每次查詢1萬的資料給DTS伺服器，交給DTS處理。sql如下：

select * from table_name where id > curId and id < curId + 10000;

3.當id大於maxId之後，存量資料遷移任務結束

當然我們在實際的遷移過程中可能不會去使用阿里雲，或者說在我們的第三個場景下，我們的資料庫欄位之間需要做很多轉換，DTS不支援，那麼我們就可以模仿DTS的做法，通過分段批量讀取資料的方式來遷移資料，這裡需要注意的是我們批量遷移資料的時候需要控制分段的大小，以及頻率，防止影響我們線上的正常執行。

增量資料遷移

存量資料的遷移方案比較有限，但是增量的資料遷移方法就是百花齊放了，一般來說我們有下面的幾種方法：

DTS: 阿里雲的DTS算是一條龍服務了，在提供存量資料遷移的同時也提供了增量資料遷移，只不過需要按量收費。
服務雙寫：比較適合於系統沒有切換的遷移，也就是隻換了儲存但是系統還是同一個，比如說分庫分表，redis資料同步等，這個的做法比較簡單直接在程式碼裡面同步的去寫入需要遷移的資料，但是由於不是同一個資料庫就不能保證事務，有可能導致遷移資料的時候會出現資料丟失，這個過程通過後續的資料校驗會進行解決。
MQ非同步寫入：這個可以適用於所有的場景，當有資料修改的時候傳送一個MQ訊息，消費者收到這個訊息之後再進行資料更新。這個和上面的雙寫有點類似，但是他把資料庫的操作變成了MQ非同步了出問題的概率就會小很多
監聽binlog: 我們可以使用之前說過的canal或者其他的一些開源的如databus去進行binlog監聽，監聽binlog的方式 就和上面的訊息MQ方式一樣，只是傳送訊息的這一步被我們省略了。這個方式的一個開發量來說基本是最小的。
這麼多種方式我們應該使用哪種呢？我個人來說是比較推薦監聽binlog的做法的，監聽binlog減少開發成本，我們只需要實現consumer邏輯即可，資料能保證一致性，因為是監聽的binlog這裡不需要擔心之前雙寫的時候不是一個事務的問題。

資料校驗

前面所說的所有方案，雖然有很多是成熟的雲服務(dts)或者中介軟體(canal)，但是他們都有可能出現一些資料丟失，出現資料丟失的情況整體來說還是比較少，但是非常難排查，有可能是dts或者canal不小心抖了一下，又或者是接收資料的時候不小心導致的丟失。既然我們沒有辦法避免我們的資料在遷移的過程中丟失，那麼我們應該通過其他手段來進行校正。

通常來說我們遷移資料的時候都會有資料校驗這一個步驟，但是在不同團隊可能會選取不同的資料校驗方案：

之前在美團的時候，我們會做一個雙讀，也就是我們所有的讀取都會從新的裡面讀取一份，但是返回的還是老的，這個時候我們需要做這部分資料的校驗，如果有問題可以發出報警人工修復或者自動修復。通過這種方式，我們常用的資料就能很快的進行一個修復，當然也會不定時的去跑一個全量的資料check，只是這種check出來修復資料的時間就比較滯後。
現在在猿輔導之後，我們沒有采用之前的那種方式，因為雙讀check雖然能很快發現資料的不對，但是我們並沒有對這部分資料有那麼高的一個實時性校驗並且雙讀的一個程式碼開發量還是稍微比較大的，但是又不能依靠不定時全量check去保證，這樣就會導致我們的資料校驗時間會非常的延長。我們採取了一個折中的方法，我們借鑑了對賬裡面的T+1的一個思路，我們每天凌晨獲取老資料庫中昨天更新的資料，然後和我們新資料庫中的資料做一一比對，如果有資料不一樣或者資料缺失，我們都可以立馬進行一個修復。
當然在實際開發過程中我們也需要注意下面幾點：

資料校驗任務的一個正確性如何保證，校驗任務本來就是去校正其他資料的，但是如果他自身出現了問題，就失去了校驗的意義，這裡目前來說只能靠review程式碼這種方式去保證校驗任務的正確性。
校驗任務的時候需要注意日誌的列印，有時候出現問題可能是直接所有資料出現問題，那麼校驗任務就有可能會打出大量的錯誤日誌，然後進行報警，有可能會將系統打掛，或者說影響其他人的服務。這裡如果要簡單一點搞，可以將一些非人工處理的報警搞成warn，複雜一點搞得話，可以封裝一個工具，某個error列印再某個時間段超過一定量然後就不用再列印了。
校驗任務注意不要影響線上執行的服務，通常校驗任務會寫很多批查詢的語句，會出現批量掃表的情況，如果程式碼沒有寫好很容易導致資料庫掛掉。
切流

當我們資料校驗基本沒有報錯了之後，說明我們的遷移程式是比較穩定的了，那麼我們就可以直接使用我們新的資料了嗎？當然是不可以的，如果我們一把切換了，順利的話當然是很好的，如果出現問題了，那麼就會影響所有的使用者。

所以我們接下來就需要進行灰度，也就是切流。對於不同的業務切流的的維度會不一樣，對於使用者維度的切流，我們通常會以userId的取模的方式去進行切流，對於租戶或者商家維度的業務，就需要按照租戶id取模的方式去切流。這個切流需要制定好一個切流計劃，在什麼時間段，放出多少的流量，並且切流的時候一定要選擇流量比較少的時候進行切流，每一次切流都需要對日誌做詳細的觀察，出現問題儘早修復，流量的一個放出過程是一個由慢到快的過程，比如最開始是以1%的量去不斷疊加的，到後面的時候我們直接以10%，20%的量去快速放量。因為如果出現問題的話往往在小流量的時候就會發現，如果小流量沒有問題那麼後續就可以快速放量。

注意主鍵ID

在遷移資料的過程中特別要注意的是主鍵ID，在上面雙寫的方案中也提到過主鍵ID需要雙寫的時候手動的去指定，防止ID生成順序錯誤。

如果我們是因為分庫分表而進行遷移，就需要考慮我們以後的主鍵Id就不能是自增id,需要使用分散式id，這裡比較推薦的是美團開源的leaf，他支援兩種模式一種是雪花演算法趨勢遞增，但是所有的id都是Long型，適合於一些支援Long為id的應用。還有一種是號段模式，這種會根據你設定的一個基礎id，從這個上面不斷的增加。並且基本都走的是記憶體生成，效能也是非常的快。

當然我們還有種情況是我們需要遷移系統，之前系統的主鍵id在新系統中已經有了，那麼我們的id就需要做一些對映。如果我們在遷移系統的時候已經知道未來大概有哪些系統會遷移進來，我們就可以採用預留的方式，比如A系統現在的資料是1到1億，B系統的資料也是1到1億，我們現在需要將A,B兩個系統合併成新系統，那麼我們可以稍微預估一些Buffer,比如給A系統留1到1.5億，這樣A就不需要進行對映，B系統是1.5億到3億，那麼我們轉換成老系統Id的時候就需要減去1.5億，最後我們新系統的新的Id就從3億開始遞增。
但是如果系統中沒有做規劃的預留段怎麼辦呢？可以通過下面兩種方式：

需要新增一個表，將老系統的id和新系統的id做一個對映記錄，這個工作量還是比較大的，因為我們一般遷移都會涉及幾十上百張表，記錄的成本還是非常的高。
如果id是Long型的話，我們可以好好利用long是64位這個因素，我們可以制定一個規則，我們新系統的id都是從一個比較大的數開始，比如從大於Int的數開始，將小Int的那部分數都可以留給我們的老系統做Id遷移，比如我們上面的1.5億的資料量，其實只用了28位，我們的Int是32位，那麼還有4位可以使用，這個4位可以代表16個系統做遷移，當然如果規劃中有更多的系統做遷移，可以將新系統的id起始點設定得更大一點。如下圖所示：

總結

最後簡單來總結下這個套路，其實就是四個步驟，一個注意：存量，增量，校驗，切流，最後再注意一下id。不管是多大量級的資料，基本上按照這個套路來遷移就不會出現大的問題。希望能在大家的後續遷移資料工作中，這篇文章能幫助到你。
以下文章來源於咖啡拿鐵 ，作者咖啡拿鐵
連結：https://mp.weixin.qq.com/s/H3LcRM0cHkVxBM4pofq_LQ

總結了一些2020年的面試題，這份面試題的包含的模組分為19個模組，分別是： Java 基礎、容器、多執行緒、反射、物件拷貝、Java Web 、異常、網路、設計模式、Spring/Spring MVC、Spring Boot/Spring Cloud、Hibernate、MyBatis、RabbitMQ、Kafka、Zookeeper、MySQL、Redis、JVM 。

獲取資料以上資料：關注公眾號：有故事的程式設計師，獲取學習資料。
記得點個關注+評論哦~