随着網際網路業務的發展，無論是企業開發者，還是個人開發者，産品能力的不斷疊代，都會帶來大量的新增資料，資料的新增則意味着作為服務商的雲開發需要為開發者們做好資料的存儲和備份，以及在合适的時候對叢集進行更新、優化。在優化的過程中，就涉及到了遷移的問題。
一般來說，業界針對更新和遷移，會提供熱遷移和冷遷移兩種方案：
- 冷遷移：冷遷移需要對資料庫先進行停機，等遷移完成後，再重新開機資料庫。
- 熱遷移：熱遷移無需對資料庫進行停機，整個遷移過程中，資料庫可以持續對外提供服務。使用者對于熱遷移無感覺。用一個比喻來說，就是有一個開着水龍頭往裡注水的水池，熱遷移做的事情是将這個水池子裡面的水完整地倒入另外一個水池。
雲開發作為基礎服務提供商，是無法進行冷遷移的，是以，對于雲開發來說，思考如何在現有的架構基礎之上做好熱遷移勢在必行。
想要對雲開發的資料庫進行熱遷移，首先，需要了解雲開發資料庫的底層架構。
簡單來說，雲開發的資料庫由一組 Keeper 和 Agent 組成的接入層直接對使用者提供服務，Keeper 來完成鑒權操作，Agent 負責維護 Keeper 到底層資料庫的連結池，使用者的請求會打散并分發到各個 Agent 中，避免單點資料故障。
就雲開發本身的資料實作而言，熱遷移就意味着在使用者請求不停的情況下，将使用者的存儲叢集從 db1 遷移至 db2，并将 agent 的連接配接池從 db1 指向 db2。
在了解了雲開發底層的資料庫架構以後，就可以來讨論遷移的具體實作。
熱遷移的基礎是資料庫底層的遷移能力，而資料庫底層的遷移分為三個狀态：
- 資料同步：對快照和資料庫的 oplog 進行拷貝和追蹤；
- 資料割接：在 oplog 幾乎追上時，進行資料割接；
- 目标叢集可用：完成割接後，原叢集變為可用狀态。
可以看到，在這個過程中，割接會影響原叢集的讀寫狀态，是以對于熱遷移來說，割接的處理至關重要。我們需要在割接過程中 block 住使用者的請求，在割接完成之後将請求轉發到新的叢集，同時我們需要盡量保證割接的時間不能太長。
類似的，也因為割接的重要性，引出了熱遷移的四個難點：
- 強一緻性地感覺叢集變更、熱遷移狀态 ：熱遷移完成後，agent 需要改變連接配接池指向；
- 高性能割接
- 割接狀态持久化，逾時控制 ：割接過程的容災處理；
- 割接流程中block住使用者請求的能力：通過 block 使用者請求，實作無損熱遷移。
在對于熱遷移的難點有了深入的了解後，我們設計了如下的熱遷移實作流程：
圖中的 DBMaster 為雲開發資料庫底層資料庫控制中心；Shark 為接入層控制服務、Agent 為接入層；ETCD 為分布式鍵值存儲系統，用于配置共享和服務發現。
第一步：發起請求：由 shark 向 db master 發起開始熱遷移的請求；
第二步：資料同步：db maste 響應 response，同時開始資料同步，此時原叢集可寫可讀；
第三步：資料割接：資料同步完成之後 db master 判斷可以進行割接了，于是發起開始割接請求，shark 向 etcd 中寫入割接資訊；
第四、五步：廣播請求：shark 廣播準備割接請求到全部的 agent；
第六步：回複請求：shark 回複準備割接 response；
第七、八步：Block 請求：agent 收到消息之後，設定 etcd 中的割接狀态，相當于回複一個 ack。此時 agent 開始準備 block 住使用者的請求；
第九步：調整割接狀态：通知db master進行割接，整個割接狀态不超過5秒，通過etcd逾時實作；
第十步：确認狀态：db master 回複割接成功或者失敗的 response；
第十一、十二步：通知割接成功：shark 通知各個 agent 本次割接是否成功。
通過上述操作，即可成功的完成雲開發資料庫的熱遷移。值得注意的是，在割接過程中，被遷移資料庫的連接配接池是被 block 住的，直到割接流程結束，是以，整個割接的過程需要盡可能的短，以免影響使用者請求。
我們基于上述的方案，做了一些測試，在測試環境 3KQPS 寫請求的情況下，使用者請求無失敗。
生産環境下目前遷移使用者請求如圖所示：
以上便是基于小程式雲開發自身的資料庫架構設計的資料庫底層熱遷移實作方案概述。
如果你對上文有任何疑問，歡迎在下方評論區留言。
作者：李子昂，騰訊雲雲開發團隊進階背景開發工程師。