系統隨着業務的發展，系統技術選型和層級劃分都會進行或大或小的調整，在系統調整過程中，沉澱下來的數據需要得到良好的梳理和傳承，對於非流水的屬性類數據，需要隨着系統的重構重新遷移、組合，但是在線的系統不允許大規模的停服來配合遷移，這個時候需要一套熱遷移或者準熱遷移的方案，下面我們來討論下。
查了下類似的經驗和方案，主要分一下幾類：
1、完全停服，全量部署至新服務、遷移至新數據源（單寫） 推薦指數 ☆☆☆
優點：邏輯簡單、操作成本較低
缺點：停服影響用戶體驗，且不具備回滾方案，如上線後遇到問題風險較大
2、部分功能降級，停止寫操作，遷移至新數據源（單寫） 推薦指數 ☆☆
優點：對用戶影響減小
缺點：需具備配合服務降級相關的流量控制能力，不具備回滾方案
3、停服部署、在原服務的基礎上增加雙寫功能、數據源也採用雙寫 推薦指數 ☆☆☆☆
優點：可通過開關控制雙寫、具備回滾方案
缺點：操作成本較高、對接過程中的迭代需要同步支持、需要停服
4、不停服，增加緩衝層（MQ），數據遷移過程中增量數據寫入緩存，在數據遷移完成、緩衝層數據消費完成後，打開開關開始雙寫數據庫 推薦指數 ☆☆☆☆☆
優點：對用戶無感，有回滾方案
缺點：操作成本高、方案操作節點、引入組件較多、研發和測試流程需要嚴格把控
針對五星方案操作流程圖：
幾個需要關注的點：
1、業務系統數據是否有中間態，雙寫上線時的在途數據兼容
2、數據遷移前業務系統數據是否需要前置對賬，切割存量、輕裝前行
3、雙寫工具是否能通用？