首發(fā)于筆者的微信公眾號(hào)：技術(shù)心流FollowFlows

原文地址：Stripe Engineering Blog

各工程團(tuán)隊(duì)常面臨一項(xiàng)共同挑戰(zhàn)：重新設(shè)計(jì)數(shù)據(jù)模型以支持清晰準(zhǔn)確的抽象和更復(fù)雜的功能。這意味著，在生產(chǎn)環(huán)境中，需要遷移數(shù)以百萬(wàn)計(jì)的活躍數(shù)據(jù)對(duì)象，并且重構(gòu)上千行代碼。

用戶期望 Stripe API 保障可用性和一致性。所以在進(jìn)行遷移時(shí)，需要格外謹(jǐn)慎，必須保證數(shù)據(jù)的數(shù)值正確無(wú)誤，并且 Stripe 的服務(wù)始終保持可用。

本文將展示 Stripe 如何安全地對(duì)數(shù)以億計(jì)的 Subscriptions （譯者注：Subscriptions指服務(wù)的訂購(gòu)）對(duì)象進(jìn)行大規(guī)模遷移。

為什么遷移是困難的

數(shù)據(jù)規(guī)模

數(shù)以億計(jì)的 Subscriptions 對(duì)象。在生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)上進(jìn)行涉及到所有這些對(duì)象的大規(guī)模遷移會(huì)有巨大的工作量。

想象一下，遷移一個(gè) Subscription 對(duì)象需要花費(fèi)一秒鐘，若以順序方式遷移一億個(gè)對(duì)象將花費(fèi)超過(guò)三年的時(shí)間。

服務(wù)在線時(shí)間

商業(yè)機(jī)構(gòu)不斷的通過(guò) Stripe 的服務(wù)進(jìn)行交易。所有的基礎(chǔ)設(shè)施升級(jí)都是在線進(jìn)行，而不依賴于有計(jì)劃的維護(hù)時(shí)段。因?yàn)椴荒茉谶w移過(guò)程中中斷Subscriptions 服務(wù)，在這個(gè)遷移過(guò)程中必須要保證所有服務(wù)100%處于可用狀態(tài)。

數(shù)據(jù)正確性

代碼庫(kù)中的很多代碼都在使用 Subscriptions 數(shù)據(jù)庫(kù)表。如果試圖一次性修改整個(gè) Subscriptions 服務(wù)中數(shù)以千計(jì)的代碼行，那幾乎肯定會(huì)忽視一些邊界情況 。工程團(tuán)隊(duì)必須確保每項(xiàng)服務(wù)都能夠持續(xù)獲取正確無(wú)誤的數(shù)據(jù)。

在線遷移的模式

將數(shù)百萬(wàn)個(gè)對(duì)象從舊數(shù)據(jù)庫(kù)表遷移到新表是很有難度的，但許多公司需要去做這樣的事情。

以下是在進(jìn)行大型在線遷移中常用的4步”雙寫(xiě)模式“，具體步驟是：

向舊表和新表雙寫(xiě)數(shù)據(jù)以保證它們之間的數(shù)據(jù)是同步的。

修改代碼庫(kù)中所有的數(shù)據(jù)讀取路徑以從新表讀取數(shù)據(jù)。

修改代碼庫(kù)中所有的數(shù)據(jù)寫(xiě)入路徑以將數(shù)據(jù)只寫(xiě)入新表。

刪除依賴過(guò)時(shí)數(shù)據(jù)模型的舊數(shù)據(jù)。

遷移示例：Subscriptions

什么是Subscriptions？為什么需要進(jìn)行遷移？

Stripe 的 Subscriptions用于幫助 DigitalOcean 和 Squarespace 這類(lèi)用戶構(gòu)建并管理他們客戶的訂購(gòu)計(jì)費(fèi)。在過(guò)去幾年中，我們穩(wěn)步增加了一些功能來(lái)支持更復(fù)雜的計(jì)費(fèi)模式，例如復(fù)合訂閱、試用、優(yōu)惠券和發(fā)票。

在早期，每個(gè) Customer 對(duì)象最多只有一個(gè) subscription 。 customers 信息存儲(chǔ)為單獨(dú)的記錄。因?yàn)?customers到 subscriptions 之間的映射關(guān)系非常簡(jiǎn)單，所以subscriptions 信息與 customers 信息存儲(chǔ)在一起。

最終，我們的用戶想要具有多個(gè) subscriptions 的 customers 。我們決定將單一的subscription字段轉(zhuǎn)換為subscriptions字段，以便存儲(chǔ)具有多個(gè) subscription 的數(shù)組。

當(dāng)添加新功能時(shí)，這個(gè)數(shù)據(jù)模型便出現(xiàn)問(wèn)題了。任何對(duì) subscriptions 的修改都會(huì)引發(fā)整條 Customer 記錄的更新，以及 subscriptions 相關(guān)的查詢都要通過(guò)掃描 customer 對(duì)象實(shí)現(xiàn)。所以我們決定將 subscriptions 獨(dú)立存儲(chǔ)。

重新設(shè)計(jì)的數(shù)據(jù)模型將 subscriptions 轉(zhuǎn)移到獨(dú)立的數(shù)據(jù)表中

再次提醒，四步遷移方案如下：

向舊表和新表雙寫(xiě)數(shù)據(jù)以保證它們之間的數(shù)據(jù)是同步的。

修改代碼庫(kù)中所有的數(shù)據(jù)讀取路徑以從新表讀取數(shù)據(jù)。

修改代碼庫(kù)中所有的數(shù)據(jù)寫(xiě)入路徑以將數(shù)據(jù)只寫(xiě)入新表。

刪除依賴過(guò)時(shí)數(shù)據(jù)模型的舊數(shù)據(jù)。

下面介紹這四個(gè)步驟的具體實(shí)踐。

第一步：雙寫(xiě)

創(chuàng)建一張新的數(shù)據(jù)庫(kù)表作為遷移的開(kāi)始。第一步是開(kāi)始復(fù)制新數(shù)據(jù)，同時(shí)寫(xiě)入新舊兩處存儲(chǔ)中。之后，再將缺失的數(shù)據(jù)回填至新存儲(chǔ)，已使兩處存儲(chǔ)具有相同的數(shù)據(jù)。

所有新寫(xiě)入的數(shù)據(jù)都應(yīng)更新新舊兩處存儲(chǔ)

在 Stripe 的案例中，我們將所有新創(chuàng)建的 subscriptions 同時(shí)寫(xiě)入 Customers 表和 Subscriptions 表。在開(kāi)始雙寫(xiě)兩張表之前，需要評(píng)估額外的寫(xiě)入操作對(duì)生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)性能的潛在影響。可以通過(guò)緩慢提高重復(fù)對(duì)象的百分比來(lái)緩解性能問(wèn)題，同時(shí)持續(xù)關(guān)注系統(tǒng)運(yùn)行指標(biāo)。

進(jìn)行到此時(shí)，新創(chuàng)建的對(duì)象已同時(shí)存在于兩張表中，而舊對(duì)象只能在舊表中找到。接下來(lái)將以懶惰方式（ lazy fashion ）開(kāi)始復(fù)制已存在的舊對(duì)象：每當(dāng)對(duì)象更新時(shí)，將它們自動(dòng)復(fù)制到新表中。這種方式可逐步轉(zhuǎn)移已存在的數(shù)據(jù)。

最后，將剩余的 subscriptions 數(shù)據(jù)回填至新表。

回填已存在 subscriptions 數(shù)據(jù)至新表

在正在對(duì)外提供服務(wù)的數(shù)據(jù)庫(kù)上找到所有需要遷移的數(shù)據(jù)是回填操作中代價(jià)最大的部分。通過(guò)查詢數(shù)據(jù)庫(kù)查找所有對(duì)象的方式將需要在生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)上執(zhí)行相當(dāng)多的查詢操作，這將耗費(fèi)很多時(shí)間。幸運(yùn)的是，可以將數(shù)據(jù)從線上導(dǎo)入對(duì)生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)完全無(wú)影響的離線流程中。我們創(chuàng)建適用于我們 Hadoop 集群的數(shù)據(jù)庫(kù)快照，這讓我們可以使用 MapReduce (https://en.wikipedia.org/wiki/MapReduce) 以離線，分布式的方式快速處理數(shù)據(jù)。

我們使用 Scalding (https://github.com/twitter/scalding) 來(lái)管理 MapReduce Job。 Scalding 是用 Scala 編寫(xiě)的非常實(shí)用的庫(kù)，可以很容易地編寫(xiě)MapReduce Job（10行代碼即可實(shí)現(xiàn)一個(gè)簡(jiǎn)單的Job）。 在這種情況下，使用 Scalding 幫助工程團(tuán)隊(duì)找出所有subscriptions 數(shù)據(jù)。具體步驟如下：

編寫(xiě)一份 Scalding Job，提供所有需要復(fù)制的 subscription ID 的列表。

通過(guò)一組進(jìn)程并行執(zhí)行來(lái)大規(guī)模的復(fù)制 subscriptions 數(shù)據(jù)。

遷移完成后，需再次運(yùn)行 Scalding Job，以確保所有 subscriptions 數(shù)據(jù)都已存在于 Subscriptions 表中。

第二步：改變所有讀操作路徑

到目前為止，新舊數(shù)據(jù)表已是同步狀態(tài)。下一步要做的是在新表上進(jìn)行所有的讀操作。

目前，所有的讀操作在 Customers 表上進(jìn)行，需要將這些操作轉(zhuǎn)移到 Subscriptions 表上。

需要確保從新表讀數(shù)據(jù)是安全的，subscription 在新舊表中的數(shù)據(jù)應(yīng)該是一致的。可以使用 GitHub 出品的 Scientist (https://github.com/github/scientist) 來(lái)輔助驗(yàn)證讀操作。Scientist 是一個(gè) Ruby 庫(kù)， 它可以讓我們?cè)谏a(chǎn)環(huán)境運(yùn)行實(shí)驗(yàn)，比對(duì)不同代碼的運(yùn)行結(jié)果并對(duì)不一致的結(jié)果發(fā)出警告 。通過(guò) Scientist ，可實(shí)時(shí)生成針對(duì)不一致結(jié)果的警告和指標(biāo)。當(dāng)實(shí)驗(yàn)代碼中發(fā)生錯(cuò)誤，其余的應(yīng)用程序是不會(huì)受到任何影響的。

實(shí)驗(yàn)如下進(jìn)行：

使用 Scientist 從 Subscriptions 表和 Customers 表同時(shí)讀取數(shù)據(jù)。

如果讀取到的數(shù)據(jù)不一致，則向工程團(tuán)隊(duì)發(fā)出警告。

GitHub 出品的 Scientist 可運(yùn)行讀取兩張表并對(duì)數(shù)據(jù)做對(duì)比的實(shí)驗(yàn)。

在確認(rèn)所有數(shù)據(jù)是一致的后，就可以開(kāi)始從新表讀取數(shù)據(jù)了。

實(shí)驗(yàn)成功，現(xiàn)在所有的讀操作都在 Subscriptions 表上進(jìn)行。

第三步：改變所有寫(xiě)操作路徑

接下來(lái)，需要更新寫(xiě)操作路徑，將數(shù)據(jù)寫(xiě)入新的 Subscriptions 表。 實(shí)施的目標(biāo)是逐步推進(jìn)這些改變，所以需要采取謹(jǐn)慎的策略。

直到現(xiàn)在，數(shù)據(jù)一直寫(xiě)入舊表，然后被復(fù)制到新表：

現(xiàn)在要顛倒這個(gè)順序：先將數(shù)據(jù)寫(xiě)入新表，然后將其寫(xiě)入舊表中。 通過(guò)保持這兩張表的一致性，我們可以進(jìn)行增量更新并仔細(xì)觀察每個(gè)更改。

重構(gòu) subscriptions 的所有寫(xiě)操作代碼可以說(shuō)是遷移中最具挑戰(zhàn)性的部分。 Stripe 服務(wù)中處理 subscriptions 操作的邏輯（例如更新，分期付款、續(xù)費(fèi)）涉及多個(gè)服務(wù)的數(shù)千行代碼。

成功重構(gòu)的關(guān)鍵是增量處理：將盡可能多的代碼路徑分隔成可能的最小單元，以便可以仔細(xì)應(yīng)用每個(gè)更改。 新舊兩張表的數(shù)據(jù)在重構(gòu)的任何一個(gè)階段都需要保持一致。

對(duì)于每個(gè)代碼路徑，我們需要使用整體方法來(lái)確保我們的更改是安全的。 我們不能僅僅只使用新數(shù)據(jù)替代舊數(shù)據(jù)：每一個(gè)邏輯塊都需要仔細(xì)斟酌。 如果錯(cuò)過(guò)了任何情況，可能就會(huì)造成數(shù)據(jù)不一致。 值得慶幸的是，可以運(yùn)行更多的 Scientist 實(shí)驗(yàn)來(lái)提醒工程團(tuán)隊(duì)可能存在的任何不一致。

新的，簡(jiǎn)化的寫(xiě)數(shù)據(jù)路徑如下所示：

可通過(guò)在調(diào)用 subscriptions 數(shù)組時(shí)觸發(fā)報(bào)錯(cuò)的方法，確保沒(méi)有代碼繼續(xù)使用過(guò)時(shí)的subscriptions 數(shù)組：

第四步：刪除舊數(shù)據(jù)

最后的步驟是移除舊的寫(xiě)操作代碼并最終刪除它們。

一旦確定沒(méi)有任何代碼依賴過(guò)時(shí)數(shù)據(jù)模型的 subscriptions 字段，就不再需要將數(shù)據(jù)寫(xiě)入舊表：

隨著這一變化，代碼不再使用舊數(shù)據(jù)源，新數(shù)據(jù)源成為唯一數(shù)據(jù)源。

現(xiàn)在，可以刪除所有 Customer 對(duì)象上的 subscriptions 數(shù)組，并且逐漸以懶惰的方式處理“刪除”操作。 每次 subscription 被加載后，都會(huì)自動(dòng)清空這個(gè) subscriptions 數(shù)組，然后運(yùn)行 Scalding 作業(yè)并遷移，以查找任何剩余的要?jiǎng)h除的對(duì)象。 最終的數(shù)據(jù)模型如下：

結(jié)論

在保證 Stripe API 數(shù)據(jù)一致性的同時(shí)進(jìn)行遷移是非常復(fù)雜的工作。安全進(jìn)行這項(xiàng)遷移的幾個(gè)要點(diǎn)如下：

我們制定了一個(gè)四階段遷移策略，可以讓我們?cè)谏a(chǎn)環(huán)境中不停服進(jìn)行數(shù)據(jù)切換。

使用Hadoop離線處理數(shù)據(jù)，使用MapReduce以并行方式處理大量數(shù)據(jù)，而不是依賴在生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)上執(zhí)行的代價(jià)高昂的查詢。

所做的所有更改都是漸進(jìn)式的。 我們從未試圖一次更改幾百行代碼。

所有的變化都是高度透明和可觀察的。 Scientist 的實(shí)驗(yàn)只要有一條數(shù)據(jù)在生產(chǎn)環(huán)境中是不一致的，就立即提醒工程團(tuán)隊(duì)。 在整個(gè)遷移過(guò)程中，我們都對(duì)安全的遷移懷有信心。

我們發(fā)現(xiàn)這種方法在我們執(zhí)行過(guò)的許多在線數(shù)據(jù)遷移中都很有效。我們希望這些實(shí)踐做法對(duì)于其他團(tuán)隊(duì)進(jìn)行大規(guī)模遷移也是有幫助的。

總結(jié)

以上是生活随笔為你收集整理的如何进行大规模在线数据迁移（来自Stripe公司的经验）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。