設計新系統容易，但是我們處理的都是老系統和歷史詩句。怎麼能更平滑的遷移舊資料到新的資料庫和系統，特別是在異構的資料庫結構情況下，達到資料準確，遷移速度快，減少停機，對業務影響小
遷移是最容易出故障的乙個點。
那麼如何做資料遷移呢？
最直觀的一把梭方案，即全量資料的匯入/出：
如果直接複製，可以 dump 後全量匯入，如果是異構資料，需要用程式處理。
優點：簡單
缺點：停機時間過長，資料量不太大時適合這種方案
大部分開發採用的方案，依賴資料本身的時間戳，即版本號：
優點：極大縮短停機時間
看來已經滿足絕大部分需求了，還有更流弊的方案嗎？
當你的公司資料庫和中介軟體比較完善時，推薦使用。
通過主庫或從庫的binlog解析和重新構造資料，利用主從複製實現擴充套件遷移，這需要中介軟體的支援。可實現多執行緒，斷點續傳，全量歷史和增量資料同步。
可以達到：
當然了，既然這種需求很常見，社群肯定也有支援的框架：
php分布式微服務開發 分布式微服務架構
隨著業務的不斷發展,使用者體量的快速擴張.從單體 垂直架構轉移到分布式 微服務架構是自然而然的選擇.分布式理論是分布式系統的基礎,在任何情況下分布式系統都要滿足網路分割槽容錯性,因此分布式系統都是在可用性和一致性方面做平衡.cap理論指的是在乙個分布式系統中,一致性 可用性 分割槽容錯性 在任何情況...
分布式 微服務面試
分布式 微服務面試 為什麼要拆分成多個微服務？微服務架構與傳統架構的優缺點？我們為什麼要使用分布式？分布式事物問題出現場景？如何解決分布式事物的問題？tcc是什麼？實現原理是怎麼樣的？2pc，3pc的概念是什麼？實現原理是怎樣的？訊息的最終一致性是什麼意思？如何實現訊息的最終一致性？訊息的最大努力通...
什麼是分布式 微服務
單體 傳統web專案 比較適合小專案，優點是 它的缺點也非常明顯，特別對於網際網路公司來說 通俗點說就是對於網際網路專案，屬於一直運營中有客戶一直在使用。單體應用的缺陷就暴露出來了，比如可能會因為乙個小問題，需要緊急上線，而導致整個 需要停止，這樣的情況對客戶 業務都是影響很大的，重新部署 備份對於...