作為業務系統的開發設計人員，資料及資料同步是非常重要的工作之一。
在日常的軟體開發過程中，經常會碰到推送和拉取等業務。那麼一開始如何選用推送或拉取這兩個方案呢？這是由實際業務決定、雙方系統的技術實現、雙方系統的架構和效能，看日後是否此業務會經常修改等多方面決定的。下面本文就從實際的兩個業務情況來討論。
一、a 系統有一些訂單資料，b 系統需要 a 系統的訂單資料，並做一些處理。比如 a 系統的訂單支付完成之後會轉到 b 系統中做銷售結算、銷售出庫等處理。
這種情況我相信大部分人都會決定在 a 系統的訂單付完款之後，把訂單資料推送到 b 系統中。因為這樣選擇是合理的。why？如果要讓 b 系統去輪循地查詢 a 系統的訂單資料是否被付款，不僅在實時性和準確性上有缺陷，而且在a、b 系統效能上也會有影響，還要處理重複訂單問題。所以說由 a 系統推送訂單資料到 b 系統是合理的，但這時如果在設計時只是簡單地在 a 系統付完款這裡做乙個推送動作到 b 系統，這其實是不妥的，如果要碰到推送失敗，那麼如何再推送一次呢？如果把這個推送動作設計成序列的，那會影響到原有流程。所以在這裡設計時，要在訂單付完款的動作後做推送的動作設計成非同步，也可以做成訊息機制，由專門的程式去接收訊息，並推送到 b 系統，b 系統在接收到訂單後要反饋接收成功標誌，並且要對重複訂單做處理。這才是乙個比較完整的處理邏輯。
二、a 系統有一些訂單資料，b 系統需要 a 系統的訂單資料展示給客戶，比如 b 系統要做乙個報表展示或實時性不強的操作（比如根據訂單生成銷售結算的憑證，一天可做一次）。
這種情況就可以設計成 b 系統主動去拉 a 系統的訂單資料，然後根據 b 系統的業務維度，分析訂單資料，展示訂單資料。這樣做可減輕 a 系統的壓力。但這樣做同時也要注意網路頻寬、b 系統的資料處理效能的高低與重複資料的處理。對於網路頻寬，可以採取分頁形式來拉取資料，對於資料處理的效能問題，可以通過管道和佇列來一組一組處理訂單資料，對於重複資料，可以通過時間戳的形式來解決，時間戳要持久化在 b 系統中。最後也不要忘了在 a 系統中設計檢視、中間表甚至報表資料庫來作為資料來源，最好不要直接操作訂單表（讀寫分離）。
綜述，不管是選用哪種形式，都要根據業務的特性來設計，合理地利用介面來實現業務，必要時選用管道、佇列、檢視、非同步、訊息佇列等方法。
資料同步方案
三 軟體選擇 同步分為 實時同步和離線同步 實時同步，一般是通過監控源資料變更操作，通過在目標端實時重放操作，從而達到實時同步的目的 離線同步，相當於某個時候對源資料做乙個快照。mysql自帶功能 一般針對的是整個資料庫 參考 主主同步 同步型別 實時同步 簡介 kafka是訊息中介軟體的一種 開發...
es同步mysql方案 ES資料同步方案
當業務量上公升後，由於mysql對全文檢索或模糊查詢支援的能力不強，在系統中查詢的地方，往往會出現慢sql等，拖累系統其他模組，造成效能低下。隨著es使用普及率的公升高，es是mysql的乙個有效補充。我們可以將資料傳送到搜尋引擎 如es 上，由搜尋引擎來提供專業的服務。接下來，就結合工作中實際用到...
資料同步方案思考
yahoo的pnuts的資料同步 基於行的mastership 通過 去以非同步方式同步那些 資料。首先，應用更新請求到達 根據 對映到某乙個 去向 傳送資料更新訊息，做到安全儲存資料 可能是互備訊息 然後響應 這時候寫入資料，然後向 返回響應，然後向應用傳送響應。同步時機有 控制，估計最終一致時間...