數據同步或者遷移操作也算是線上數據變更的一種類型。由于涉及的數據量非常大，一旦發生故障，會直接影響線上業務，并且較難止損。從變更風險管控的角度考慮，數據同步或遷移操作也需要走合理的發布窗口，并且在操作前也需要做足夠的影響分析。本文就來聊一下數據同步和遷移的變更期間注意事項。

數據同步按照持續狀態的不同可以分為一次性同步跟持續性同步。從質量保障的角度，要降低持續性同步的風險，需要額外考慮數據跟組件性能的監控，其它方面的考慮兩者沒有太大的差別。數據同步的操作手法也有很多種，既可以通過搭建中間件，實現一個導入binlog到MQ然后再導到其它存儲的通路，也可以通過自建業務服務，通過批量刷數的方式主動導入大量數據。對于后者，在以前的文章當中已經提到了一些通用的風險點，但如果考慮到數據同步的需要，還會有一些額外的考量。

第一塊是壓力，數據同步的壓力相比于一般修數是更加大的，源存儲有讀的壓力，而目標存儲有寫的壓力，并且由于一般讀操作可能會分散到多個存儲節點，寫壓力對于單點存儲的影響會更大，因此需要重點考慮目標節點當前的QPS情況，選擇一個相對合適的數字。

第二塊的考量點是同步數據的篩選和轉化。通常如果涉及到異構數據存儲，同步鏈路上需要執行數據轉化的服務節點，這些節點也會承受一定的壓力。如果服務節點的QPS過高，可能會影響服務節點連帶的一些服務，或者也有可能導致服務節點注冊的網關觸發限流，這樣就有業務不可用的風險。同時，數據轉化本身的代碼邏輯也需要保證健壯性，如果觸發了corner-case導致服務報錯，也有可能影響甚至阻塞數據同步。

第三塊的考量點是數據校驗。尤其針對批量調用服務接口導入數據的情況，需要通過一定的機制去驗證數據的正確性，保證同步的數據生效并對符合業務需求表現。校驗方面，需要補上小時級、日級的數據對賬；發布過程本身，也需要保證有階段性的灰度過程，并盡可能隨機遴選數據，確保全量發布前數據驗證無誤。

最后再回到壓力。這塊討論的是數據同步已經在線上穩定運行時，其它變更需要考慮到線上已有的數據同步鏈路。好比說DB數據的增量持續性同步，如果線上有大批量的修改數據，那么就會有可能導致潛在的數據同步鏈路因為突然的壓力發生阻塞，影響某些業務可用性。要解決這個問題，需要梳理變更操作涉及的DB，以及DB涉及的數據同步鏈路，通過小流量灰度的方式初步檢測壓力狀況如何，再逐步地修改并發參數，找到最合適的變更方式。