PayPay 成立於 2018 年 10 月，由軟銀集團、日本雅虎和印度移動支付公司 Paytm 共同投資成立，是日本排名第一的移動支付公司。日本現在仍然較多使用現金，但經過大規模的營銷活動，以及政府推動無現金社會的政策支持下，我們的業務正迅速擴張。目前日本大約有 1 億人口，其中有 2900 萬用戶和 200 萬商家在使用 PayPay，近期交易量已達到 10 億。此外，PayPay 和支付寶關聯，支付寶可以掃描 PayPay 的二維碼並支付。如果你們到日本旅遊，可以試試掃 PayPay 的二維碼。

去年我們的業務增速極快，由於諸多時間限制，我們不得不在三個月內完成遷移，將最關鍵核心數據庫遷移到 TiDB，該數據庫管理着付款交易。下面我將分享我們爲什麼選擇 TiDB 以及遷移實踐經驗。

項目背景

PayPay 可以用於線上和線下支付，我們支持多種支付方式，用戶使用手機 APP 掃描商戶的二維碼，商家使用 POS 機來掃描手機上的條形碼，電商網站上也可以用 PayPay 在線支付。用戶既可以用註冊的信用卡來付款，也可以用預存的錢包餘額來支付。

PayPay 使用亞馬遜 AWS 作爲基礎架構，並在此基礎之上，搭建了微服務架構。

我們有大約 80 個組件，幾乎所有組件都使用 Java、Spring Boot、Amazon Aurora 作爲數據庫架構。所有的支付交易都傳輸到 Payment 組件進行管理。發生支付交易時，交易數據寫入到 Payment 數據庫中，該筆交易的狀態也隨之更新。因此，Payment 數據庫的寫入操作很頻繁。再加上業務量不斷增長，Payment 數據庫就成爲了瓶頸，所以我們決定要遷移到擴展性更好的數據庫。

爲什麼選擇 TiDB？

選擇 TiDB 作爲新的數據庫，有以下幾個原因：

首先，TiDB 兼容 MySQL，幾乎不需要修改業務代碼。 由於 TiDB 是分佈式架構，我們必須注意自增列的行爲，但這種修改也很少。

第二，TiDB 支持水平擴展，可以輕鬆應對未來的數據增長。 此外，TiDB 集羣由多個實例組成，能做到高可用。PayPay 的雲原生架構也與 TiDB 非常契合。

第三，開發人員不需要在應用層進行分庫分表，我們可以保持應用層的簡單。 當數據庫成爲瓶頸時，我們通常會以用戶 ID 爲 sharding key 來分庫分表，把數據分開存儲在多個數據庫裏。但這種方式下，應用需要處理分庫分表邏輯，應用變得更爲複雜。如果我們使用 TiDB，就無需擔心這種問題。

第四個原因則是，有很多公司已經把 TiDB 用在生產環境 中 。 特別是在金融領域，TiDB 有豐富的經驗，讓我們對這項新技術更有信心。這也是對決策層最有說服力的一點。

另外，我們也將 Amazon Aurora 和 TiDB 進行了對比。

Aurora 的優點在於，它默認使用一個只讀的 slave 節點，一個寫入的 master 節點。主從間的同步延遲非常小，即使 slave 上發生慢查詢，也不會影響 master 上的寫入性能。恰當地使用這兩個節點，可以有效確保穩定性，而且 Aurora 是 AWS 託管服務，管理成本較低。但是，當 Aurora 遇到許多寫入請求時，binlog 同步會成爲瓶頸。在提交過程中，Aurora 等待同步目標返回 ACK，因此當同步數量增加時，提交延遲也會增加。爲了容災，我們必須進行同步，所以這個問題日益嚴重。當我們進行 TiDB 的 POC 時，我們沒有遇到這個問題，TiDB 可以輕鬆處理比 Aurora 多 3 倍的交易量。公平地說，我想強調一下 Aurora 是一個很好的數據庫。但替換掉 Aurora，不僅是因爲我們的 binlog 同步需求。

以上就是爲什麼我們決定遷移到 TiDB。

New Payment DB with TiDB

上圖展示了我們使用 TiDB 後的新架構。一個 TiDB 集羣由 PD、TiDB 和 TiKV 組件組成，每個組件都有多個實例。另外，Pump 和 Drainer 用來設置同步 binlog 到 slave 集羣和災備站。多個實例位於不同的 AWS 可用區（即獨立的數據中心）中。因此，現在我們同時實現了很高的容災能力。

遷移實踐

我們花了一個月的時間來驗證和討論是否要遷移到 TiDB 上。在接下來的兩個月中，我們又做了詳細的驗證。

1. 數據完整性測試

第一個測試是數據完整性。我們已經確認，TiDB 與我們的應用程序集成後，可以按預期工作。爲了保證這一點，我們引入了兩種驗證，即域內驗證和跨域驗證。

域內驗證

當然，我們是在測試環境中進行的測試，但是我們想通過實際生產數據來確認行爲，因此，我們將實際生產流量克隆到另一個 Aurora 和 TiDB，查看數據是否完全相同。我們在這裏引入了一個稱爲 p6spy 的框架。

P6spy 抓取了通過 JDBC 連接發送的數據，將其發佈到 Kafka 消息隊列。用戶應用程序在 Aurora 和 TiDB 上執行了通過 Kafka 消息發送的數據庫操作。然後，我們使用 TiDB 提供的 sync-diff-inspector 比較了兩組數據。結果我們確認兩個數據庫的數據完全相同。這種方法的優勢在於，可以在不對生產數據庫造成任何額外負擔的情況下完成測試。

跨域驗證

由於我們的系統是微服務，因此我們還在 Payment 和其他相鄰組件之間添加了一致性檢查。我們使用了Amazon EMR，一種類似 Hadoop 的架構，如下圖所示：

我們每隔幾分鐘從每個數據庫中提取一次數據，將其提供給 EMR，並不斷檢查這些組件的一致性。該檢查在遷移前後都會一直進行，因爲我們希望這個系統在遷移後也可以檢測到未知問題。

2. 性能和可用性測試

我們已經有能力處理 Aurora 無法處理的高 TPS，因此我們優化了應用程序以提高性能，比如增加連接池大小，刪除不必要的索引。 TiDB 可以輕鬆處理比 Aurora 多 3 倍的 TPS，而支付交易延遲不到1秒。

對於故障案例測試，我們模擬了 30 多種場景，例如實例故障、集羣故障和可用區故障。我們定了恢復點目標（RPO）、恢復時間目標（RTO）等指標。多虧了 TiDB Binlog 工具進行同步，我們可以將 RPO 降低到趨近於零，但是由於數據量的原因，RTO 仍然很高。爲了避免將來發生大規模故障，我們需要縮短恢復時間。

3. 遷移流程

在實際遷移中，爲了降低風險，我們考慮使用增量的方法來逐步增加流量。如果是隻讀數據庫，我們可以輕鬆控制流量。但是對於寫入的數據庫，實現非常複雜。因此，我們選擇了一次性的方法。

這種方法很簡單，但一旦出現問題就會有風險，因爲會影響到所有用戶。因此，它必須能夠立即回滾。我們在首次數據遷移中進行 binlog 同步，但在遷移過程中，我們將同步設置爲相反的方向。現在我們把 Aurora 作爲備份，這樣即使出現問題，也可以立即回滾。

同樣，在遷移之前，我們進行了多次演習，包括銷售成員和 CS 成員。 實際遷移在 2 小時內就完成了，包括驗證時間在內，沒有出現任何問題，服務停機時間降至最低 。 遷移到現在已經三個月，到目前爲止，我們獲得了預期的性能。在過去的三個月中，沒有發生任何問題，TiDB 很贊，非常可靠。 此外，我還想感謝 PingCAP 的支持，他們提供了許多幫助，讓我們建立起對 TiDB 的信任。藉此機會，我想再次表達感謝。

未來規劃

實際上，我們目前選擇的是 TiDB 2.x 版本，因爲我們的數據庫涉及關鍵業務，2.x 版本有豐富的經驗。在上半年，我們將按現有狀態運行，保持信心。在這之後，我們將盡快升級到 3.x 或更高版本，因爲我們可以使用許多高版本的優秀特性，例如更有效地使用 TiKV Region Merge、更好的備份功能。如果有需要，我們還想遷移除 Payment 以外的其他數據庫。最後，我們希望通過分享我們的知識和經驗，爲 TiDB 社區做出貢獻。

希望 TiDB 在未來越來越好。

本文整理自 Munenori Hirakawa 在TiDB DevCon 2020 上的演講，大會相關視頻可以關注官方 Bilibli 賬號（ID：TiDB_Robot）的更新。