給產品經理的9千字總結：系統間資料傳輸關注這些就夠了：介面、otter、log4j、SFTP、MQ……

世界最遙遠的距離，是我站在你對面，你卻在另一臺服務器里，

世界最溫暖的舉例，是我在internet的另一端，而你挑著一筐剛刨出來的資料來看我， ——做產品的柏拉圖

一個系統裝再多資料，不與其他系統互動，那也是孤島系統，孤獨沒女朋友，

一個系統若很外向，不斷撩撥周圍的系統，也樂意被撩撥，成為了眾系統中的“交際花”，那么這貨甚至就是中臺的性質，

而更多的系統是介于上述兩種極端之間的，像人一樣，自己搞生產，也要參與社交——就是系統之間的資料對接，

對接的本質是為了實作資料資訊的傳輸，

在后端產品的世界里，各子系統之間，或與外部系統之間的對接非常常見，

作為產品經理，不僅要知道資料從哪來，還要理清楚獲取資料之后的握手方式、運算邏輯、例外規則、容錯機制、資料日志等等，

本文嘗試聊聊如下話題：

資料傳輸的場景和意義
資料傳輸的方式
資料傳輸的處理機制
資料傳輸的注意事項

說明，因為編輯器的問題 一度缺少圖片，若需看原文可以點擊這里：******系統間資料傳輸，產品經理視角的9千字總結：介面、otter、log4j、SFTP、MQ……******

一、 資料傳輸的場景和意義

1、資料傳輸的應用場景

1）前端和后端本身無時不刻的資料互動，

2）公司的各個系統之間的資訊共享，
比如，式系統部署之后，就需要各個系統模塊之間進行資料的配合，比如訂單系統的庫存扣減資料要同步給備貨系統進行采購，

3）與第三方平臺的對接
比如入駐第三方銷售平臺亞馬遜之后，店家可能自己需要管理自己的訂單，這時候就要從亞馬遜平臺獲取訂單資料，也就是抓取，

4）呼叫現成的公共插件
避免重復造輪子，市場上很多開放性的功能插件可以呼叫或接入，比如接入百度地圖的API，接入微信小程式的二次開發，

2、資料傳輸的意義

1）不重復生產資料庫，避免資源和功能的浪費，

2）統一資料的維護或生產源頭，避免資料不同步，
比如同一個公司的兩個系統都要用人員資訊架構資料，如果各自都能維護，勢必出現不一致，也浪費資源，

3）別人家的資料，自己沒辦法生產，

4）復用現成的輪子，API或SDK共享（可能自己也發明不出來），

二、資料傳輸的方式

資料傳輸的方式，作為產品經理我將其分為：介面傳輸、中間件傳輸、message方式傳輸等，散開了說，比如：MQ（佇列）、HTTP介面、otter、檔案共享傳輸等，每一種又有細分的方式和適合的場景，

1、介面

這是一種傳統的問答式的傳輸方式，是典型才c/s 互動模式，

相當于一臺客戶機，一臺服務器（注：這里的客戶機或服務器根據資料的提供方和接收方相對而言的，并不一定是實際的），

目前我們常用的http呼叫、java遠程呼叫、webserivces 都屬于這種方式，只不過，不同的就是傳輸協議以及報文格式的區別，

1）介面的作用

通過介面，可以呼叫成熟的第三方功能插件為我所用（一般就是API介面），也可以根據實際需求由開發寫具體的介面代碼解決具體場合的資訊傳輸問題（一般所說的http介面），

對后端產品經理來說，http介面的使用場景最多，比如：公司先上線了OA系統，后上線了訂單系統，訂單系統需要同步OA系統的人員組織結構資訊，那么一個可行做法就是OA系統創建一個介面，訂單系統請求，獲取最新的人員結構資訊，

這個籠統的方案描述中，包含了這么些資訊：創建介面、請求介面、獲取最新資訊等，那么分別是什么以及有什么原則呢？下面分別討論，

2）哪一方負責創建介面？

在討論需求的時候，開發會問哪方創建介面呢？有時候產品經理只知道需要建介面，不知道哪個系統來建，

可以這樣理解，如果把資料源比成一缸水，那么介面就像是鑿的一個口，口只能是在缸上面的，

所以介面必須是在被請求的資料源這邊，由被請求的一方定義介面，

注意，這里的資料源是相對的資料源，就是被請求的一方就是資料源方，

實際上可能目標資料在請求方，比如例子中也可以是OA系統請求訂單系統，但是如果這樣的話，介面就是訂單系統創建了，因此確切說是被請求的一方創建介面，

通俗的講就像是求婚：男方去求婚帶一百萬，女方接到后就把姑娘嫁過去，這是一來一回，

女方也可以去求婚，只是是直接帶著姑娘去敲開男方的門，而后男方才把一百萬送到女方，這也是一來一回，

3）什么是定義介面

定義介面，其實就是定義缸上的出水口，口的大小、濾網、放水的頻率等，就是個規則，

這個規則約定了哪些資料是需要流過去，以及流過去的條件（像門禁密碼一樣），

定義介面就是設定口令、資料范圍、推送前的篩選、轉化運算規則等，這是介面的核心內容，

4）資料在哪一方做轉義？

某些時候，資料從源頭到應用端不是原封不動的，而是轉化了，比如80分、90分都是及格，可能使用者只需要兩個值：及格or不及格，

那么這就涉及到是在接收之前就轉化為是否及格，還是接收之后自己轉化的問題，

考慮的依據主要是：該資料獲取之后是否還有其他用處，只要有可能被二次使用，最好是取原資料，

提前轉化的好處是，流轉的資料會變得簡單直接，但是需要注意的是轉化后資料量不一定會少，比如：資料源是訂單維度的，而目標是轉化為訂單+商品維度的資料，這就可能一條變多條了，

5）是主動獲取還是對方推送

有時候開發還會問是對方推，還是我們主動去取，這就是介面的post/ get方式問題，

get是從服務器方請求資料，post是向服務器方傳送資料，前面也提到了，介面互動資料可以是主動推送，也可以是請求獲取，

主動推送一般是資料生產方一旦更新，則觸發推送，將所需欄位對應值傳遞過去，

請求獲取就是資料需求方傳遞請求引數（請求引數一般是若干條件，比如：賬號+密碼），資料生產方則按照協議回應，給出滿足條件的資料到請求方（也就是回傳引數），

所以可以看出來，如果對時效要求高的，則建議生產方主動推，比如產生一個新用戶，那么就可以理解把用戶的資訊主動推送給運營方使用，

如果是時效不高或者資料量大，則可以按一定頻率主動請求，有利于系統負荷壓力穩定，

在具體使用的時候，如果你對接的系統比較多，那么建議做一個公共介面，以后誰想用他們自己來對接就好了，不然就要來一個對接一次，麻煩還有風險，

另外，選擇post/ get，最終由雙方開發權衡決定，但是一般而言：

get傳送的資料量較小，不能大于2KB，

post傳送的資料量較大，一般被默認為不受限制，get安全性非常低，post安全性較高，

6）介面定義是開發的事情，但產品經理需要給出輪廓

在輸出方案的時候，介面定義的規則是什么？傳參和回傳引數是什么？重復傳參時是跳過還是再次獲取（一般都再獲取）？必傳引數是什么？是否回傳接收結果給資料生產方？這些都是要有大致明確并傳達給開發測驗的，

比如：每小時/次取對方表中第一頁最新的50條資料，超過的資料下個小時繼續取，可以這樣設計：

因為一些關鍵引數牽扯到業務的唯一性維度，這些都在產品經理調研的時候獲知的，而這些可能開發根本不知道，因此產品經理要給出輪廓和大概方向，

7）資料流轉的時效

介面創建之后，如果是接收的對方資料庫中的資訊，那么上線之后，要考慮先進行資料的初始化（保持基礎資料一致），然后確保后續雙方是同步的，

同步的機制和要求是在定義方案的時候就確定的，那么怎么確保同步呢?方法是兩種：觸發式和定時任務，

觸發式就是一旦一個引數值滿足條件，則觸發同步，

圖片

定時任務式一般用在不知道資料源什么時候更新，需求方就要設定一個定時任務的腳本，隔一段時間查詢一次，請求的頻率需要與更新的頻率相協調，

8）總結介面的特點

優點：時效性強，可以觸發式實時問答，容易控制權限，通過傳輸層協議https，加密傳輸的資料，使得安全性提高，通用性比較強，無論客戶端是.net架構，java，python 都是可以的，

缺點：服務器和客戶端必須同時作業，當服務器端不可用的時候，整個資料互動是不可進行，當傳輸資料量比較大的時候，嚴重占用網路帶寬，可能導致連接超時，使得在資料量互動的時候，服務變的很不可靠，

9）相關概念擴展

API：即“應用程式編程介面”，是一些預先定義的函式，無需訪問原始碼或理解內部作業機制的細節，即可呼叫的物件，比如和Windows系統溝通，需要呼叫Windows提供得API，和新浪微博進行溝通，需要呼叫新浪微博提供得Api，其實它就是一個軟體系統對其他軟體系統提供得服務，

open api：是指對外開發的介面，比如百度地圖API、facebook的API等，

SDK（“軟體開發工具包”）：可以理解為api的集合，也就是封裝后的API為，功能更完善，

http介面：是基于介面的傳輸方式（HTTP協議）來命名的，當然也有基于其他協議傳輸的介面，

比如：

和Windows系統溝通，需要呼叫Windows的API（CreateWindowEx, bitblt,等等），是C語言函式形式的介面，

和.Net框架進行溝通，需要呼叫.Net提供得Api，是以C#，VB函式/類形式的介面，和新浪微博進行溝通，需要呼叫新浪微博提供得Api，是以Http請求形式的介面，

API介面的叫法相對http介面叫法更籠統和概念化一些，因此在寫方案的時候，http介面和API介面都可以，在具體的場景開發都可以理解的，

2、資料庫對庫同步

介面完成的是資訊的傳輸，相對來說比較保守，易于保護敏感資訊，而資料庫同步實際就是表對表的共享，相對介面就大方多了，因此多發生在企業內部兩小無猜的系統之間，

資料庫同步有這么幾種辦法：

1）使用中間表

例如：B系統要用A系統的資料，可以新建一個資料庫DB，A系統將資料寫入DB，B系統再到資料庫中讀取資料，

也就是將資料放進一個中間表中，A、B兩個系統都對這個表有訪問權限，這樣的好處就是選擇性地將一大批資料共享出去，

2）直接調取對方資料表

這個方式就是在B系統在開發時，在代碼中加載A系統的資料表，直接從資料表中取資料，

這就是實時拉取對方的資料，B系統自己本地不做表保存，比較省，事但是耦合性較大，資料量大的時候不建議，

3）同步對方的資料表

直接將對方的資料表copy一份過來，并保持實時同步，otter技術就是常用的一個方法，

otte可以將mysql的資料同步至另外mysql或者oracle，也支持雙向同步（即A庫同步給B庫，B庫也同步給A庫）、檔案同步等，主要應用應用是多資料中心、BI系統抽取資料、災備，

該方式需要DB協助配置，也就是做了一個mysql的同步平臺（帶WEB管理界面），在界面上，你可以定義相應的映射規則，otter行程就會根據你定義的規則讀取binlog，并更新到目標庫中去，

該方式主要用于內部系統之間（一般一個公司的才這樣）庫對庫的傳輸，可以實作資料的相互同步更新，建議應用在資料量大的時候，或者基礎資料對周邊兄弟系統提供基礎支持的時候，優點是占用資源少，互動更加簡單可靠，

當連接B的系統越來越多的時候，由于資料庫的連接池是有限的，導致每個系統分配到的連接不會很多，當系統越來越多的時候，可能導致無可用的資料庫連接，

這時候otter比較適合，而兩個不同公司的系統，不太會開放自己的資料庫給對方連接，因為這樣會有安全性影響，

3、檔案包共享方式

一些第三方公司為了保密，不愿意提供介面，那么會把檔案存在類似網盤或網頁上，供需求方下載，

雙方系統約定檔案服務器地址、密碼、檔案命名規則、檔案內容格式等，通過上傳檔案到檔案服務器，進行資料互動，對大資料量的也很適合，

這就是一種異步的上傳下載機制，雙方的操作割裂開，并且一旦上傳可以被多個需求方使用，

比如：第三方支付公司與需求方約定好SFTP服務器（一種檔案服務器，可以理解為網盤）的賬號密碼，然后支付公司將賬單資料上傳到SFTP服務器上，那么需求方就可以登陸SFTP客戶端，進行下載、決議，然后保存使用，這也實作了資料在服務器之間的傳輸，

實際上這些資料本身也是加密的，所以只有協議的公司才能拿到解碼鑰匙，長期合作的公司就會持續更新，授權的公司就可以持續下載和決議，這里就有一個下載頻率的問題，一般使用定時任務按一定頻率去下載，并且要考慮丟包的機制，

案例：
到SFTP服務器抓取并決議WP支付平臺的賬單明細，方案如下：

到SFTP服務器找到檔案路徑，篩選出需要的型別檔案，打開檔案，按規則決議所需的欄位，對應寫入本地資料表，

腳本執行邏輯：每次抓取路徑下‘修改時間’為前一天的檔案，（這里有個隱患：如果出了故障，可能某天的資料就漏了），

問題：怎么防止丟抓呢？

分析：因為是外部資料，所以這里無法對源資料做“是否被抓取過”的標注，因此建議防丟方案是增加斷抓補抓機制，

斷抓補抓機制：比如4號抓了修改時間為3號的資料，5號斷抓，則6號繼續抓取4、5號的資料，斷抓補抓的機制就是說一旦某一天的資料中斷了，發現不連續，那么系統就自動在下次重新抓一次，看看是否能補上，直到三次都未取到，則不再補救，

該方案可以降低我方抓取故障導致的抓空情況，有時候開發懶省事不愿意考慮這么多，這時候產品經理要提醒他，

4、訊息佇列MQ（Message Queue）

1）MQ概念

訊息佇列技術是分布式應用間交換資訊的一種技術，目前市場上有很多開源的jms訊息中間件，比如ActiveMQ, OpenJMS，

簡單說就是一方不斷把資訊推到佇列中，像排隊進隧道一樣，另一方依次消費這些資訊，訊息佇列可駐留在記憶體或磁盤上，佇列存盤訊息直到它們被應用程式讀走，

該方式更適用于公司內部，資料量大，規律性強，批量往來的資料，主要解決應用解耦，異步訊息，流量削鋒等問題，

2）以異步處理舉例說明

用戶注冊后，需要發注冊郵件和注冊短信，傳統的做法有兩種：a.串行的方式；b.并行方式

a、串行方式：
將注冊資訊寫入資料庫成功后，發送注冊郵件，再發送注冊短信，以上三個任務全部完成后，回傳給客戶端，

b、并行方式：
將注冊資訊寫入資料庫成功后，發送注冊郵件的同時，發送注冊短信，以上三個任務完成后，回傳給客戶端，與串行的差別是，并行的方式可以提高處理的時間，

假設三個業務節點每個使用50毫秒鐘，不考慮網路等其他開銷，則串行方式的時間是150毫秒，并行的時間可能是100毫秒，

因為CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次，則串行方式1秒內CPU可處理的請求量是7次（1000/150），并行方式處理的請求量是10次（1000/100）

小結：如以上案例描述，傳統的方式系統的性能（并發量，吞吐量，回應時間）會有瓶頸，如何解決這個問題呢？

引入訊息佇列，異步處理，改造后的架構如下：

按照以上約定，用戶的回應時間相當于是注冊資訊寫入資料庫的時間，也就是50毫秒，注冊郵件，發送短信寫入訊息佇列后，直接回傳，因此寫入訊息佇列的速度很快，基本可以忽略，因此用戶的回應時間可能是50毫秒，因此架構改變后，系統的吞吐量提高到每秒20 QPS，比串行提高了3倍，比并行提高了兩倍，

在設計方案的時候要注意例外情況的處理機制，比如：首次消費失敗？

如果第一次資料消費的時候，無法識別沒有匹配上，但是又想下次再消費一次看是否匹配的上怎么辦？可以設定機制：無法識別的則重新插到佇列后面繼續推送，

如果一直回圈仍消費不掉資訊積壓怎么辦？

設定處理機制：超過一定積壓資料量或者回圈時間過長則進行報警，

3）MQ、檔案包共享、介面的對比

MQ推送過去之后，是否推送成功無需對方再用MQ回傳，因為推到中間站就意味著我方能做的事情已經做完，

而介面是一來一往才知道是否成功的，也就是要回傳一個資訊，這點與mq是不一樣的，但是如果非要對方再回傳是否接受成功的話，那么就要做反向MQ，這相當于另一個獨立的MQ，

檔案包共享也不需要反饋機制，因此傳到了檔案服務器之后，資料方的事情就做完了，

佇列的一個資訊只能被消費一次，不同系統不能共同消費一個佇列，因此如果對接多個系統則要多次創建MQ，而介面可以創建一個，讓其他很多系統調取，

在訂單系統對接各個銷售網站和平臺的時候就可以采用這樣的機制，避免多次對接，檔案包共享也是可以上傳一次，供多個需求方下載，這點和介面有相似之處，是MQ所不具備的，

5、其他手段

資料傳輸包含了資料資訊的獲取和寫入，其實除了線上的自動機制，還有很多土辦法，在后端產品系統中也是常使用的，

1）匯入匯出

場景：沒有辦法做系統之間的對接，但是線下能獲得資料，資料量不太大，且有規則資料，則可以通過匯入的方式，

檔案一般用csv格式，該格式檔案較小，兼容性好，然后需要定義好excel表格對應欄位的關系，比如A列對應欄位‘name’，B列對應欄位’age’，

上傳時需要對檔案檢驗，比如格式不對、必填項為空等，建議一旦一處錯誤，就全部不予匯入，并回傳錯誤提示，修改后繼續匯入，

若資料太大（與服務器的性能也有關系，比如超過一萬條），可以采用異步上傳機制，就是上傳之后不立即執行寫入，而是后臺自動分批寫入，

2）爬取

作為資料需求方，獲取資料可以通過協商介面的方式、SFTP決議的方式、或者直接爬取的方式，比如需要獲取第三方網站商標庫中最新商標名稱、注冊地、logo、授權期限等資訊，如果該網站不給于開放的介面授權，可能就需要我們開發寫爬蟲代碼爬取（當然有的商業資料也是帶有反爬機制的，這就看誰道高一尺魔高一丈了），

三、資料傳輸的處理機制

1、資料同步的觸發機制

前面提到了資料獲取的方式，那么資料獲取頻次或者觸發機制是怎么樣的呢？這要根據應用場景來設定方案，但是一般都是要求持續獲取的，

一種方式是操作事件觸發，比如頁面的按鈕點擊則觸發傳遞最新狀態，這種的時效性比較高，但是也會由于并發而增加系統負荷，

如果對時效要求不高就可以采用異步機制，比如使用腳本監控，設定腳本的運行頻率，當讀取到更新時間為頻寬內的資料，則將其捕獲并傳輸，定時腳本也叫定時任務等，定時腳本在后端是很常用的，

比如說每次獲取A系統6小時內更新的資料，那么每2小時取一次的話是沒問題的，但是若每7小時獲取一次就會漏掉1小時的資料，因此一定是每次獲取的資料時間區間，要高于資料獲取的時間間隔，

當然用時間是一種維度，更安全的是用標示性欄位，比如每次獲取is_got為0的資料，前臺是is_got做表索引（索引前面講到過），這樣遍歷（遍歷約等于全表查詢）資料庫的時候就不會太慢，

2、是否異步執行資料處理

如果獲取后還要在本地進行規則運算，則最好先落地到中間表，再由中間表寫入最終表，也就是異步寫入，

比如：按照訂單+包裹號維度，從物流系統獲取運費到財務系統，然后財務系統再將其分攤到包裹的商品上面，算出每個商品分攤的運費金額，

這時候就很容易出錯，因為分攤規則是個演算法，演算法就帶有規則的可變動性，一旦分攤規則的引數不準確，或者演算法結構變化，都會導致最終分攤的運費金額錯誤，那么這時候追查錯誤原因并修復資料就很麻煩，

所以在進行分攤之前，先落地到財務系統的臨時表（中間表）中，然后獲取資料完成，再進行寫入分攤運費的操作，

除了上述方便查錯誤原因外（有種資料清洗的意思），這種異步操作同時也確保了較少的偶聯，不至于一個環節出錯，則聯動出錯，同時它作為一個基礎資料，也可以被其他功能呼叫，若資料量萬級以上的，必須這樣做，

3、判重機制

資料通道搭建好之后，資料流往往是持續獲的，而資料源在別人那里，可能會被增刪改，因此常常有相似或相關的資料進來，

在寫入本地表的時候，不管是覆寫、更新還是插入，都是以確定若干欄位做為判重的標示為前題的，

比如職工資訊表：（姓名+手機號+性別+家鄉+身份證號），（姓名+手機號+性別+家鄉）這幾個欄位對一個職工不一定唯一，但是身份證號就是唯一的，因此如果我們更新這里的資料，就以身份證號為唯一標示，

比如獲取到同一個身份證號的手機號與我們的資料庫的不同，則更新，遇到我們的資料庫不存在的身份證號碼則插入，

某些時候無法確定那幾個是唯一欄位，則可以添加一個備用欄位，人為定義其取值規則，然后作為去重欄位，比如這個欄位叫unique_code，取資料源表的主鍵+日期，（或者直接就取源表的id，也就是外鍵），

有了判重欄位（也就是資料唯一的欄位），就可以進行更新、插入或者跳過規則設定了，

注意:若一段時間之后，改變了表的去重規則，則需要考慮到歷史資料對新資料的影響，因為二者的判重維度不一樣，可能會進來和以前的歷史資料沖突的交叉資料，

4、獲取到資料之后，如果使用?

一種是直接在頁面展示，不保存在本地資料庫中，相當于每重繪一次頁面則通過介面調取一次對方的資料展示，但這種從性能和場景上都是比較少的，一般都是先保存到本地資料庫上，自己本地各種呼叫，

對于先保存到本地的情況，有兩個問題要考慮：是否異步保存，和如何確保同源同步，

5、處理日志

資料日志：目的是記錄資料的來龍去脈，追溯以分析問題，

日志要記錄三個主要事項：資料源系統是否提供資料、目標系統是否接收到資料、目標系統是否寫入了資料，

產品經理告訴開發加資料捕獲日志的時候，需要告知是否存到表里，因為系統一般都有一個類似快取一樣的日記，只是會定期清理的，只有保存下來才能一直記錄和追溯，

開發后臺本身是有資料log日志的，因為log4j開源代碼定義了5個主要級別的log：FATAL、ERROR、WARN、INFO、DEBUG，一般情況下，開發都會自覺配置INFO或DEBUG級別的日志，以方便查資料，

但是代碼中的kog保存時間不會太長，比如一個月就會清除了，因此如果需要保留的時間長，則可以將其保存到本地資料庫，

根據實習需要，存了資料庫就可以做成頁面，展示給用戶看，比如可以從以下維度展示：

四、資料傳輸的注意事項

1、目標資料表最好和中間表的維度一致

假設從A系統獲取的資料存入B系統，先落地到中間表b，然后經過一些列運算后將資料從b寫入到b’表，

注意b和b’表的去重欄位要對應起來，并傳遞下去，因為維度相同，做到一對一，方便實作例外資料溯源，

2、不同入口寫入同一型別資料時，如何與自身入口的資料去重，且與其他入口的資料互相去重？

案例：
有新舊兩個不同的寫入程式，寫資料到利潤表，寫入的都是‘退件入庫’利潤型別，是殊途同歸，不巧的是兩個寫入入口各自有本身的去重規則，彼此去重的規則不能通用：假設入口1對應的去重欄位是A+B，入口2寫入的去重欄位是B+C，

這就意味著同一個資料如果分多次寫入，有可能從兩個入口都會寫入，如何實作避免重復寫入是核心問題，

我們首先考慮的是，如果一條源資訊從一個入口已經寫入了利潤表，那么就不能從另一個入口再寫，

其次，如果從入口1寫入一次，那么后面源資料更新再次觸發寫入的時候（判重，確定是插入還是更新），就還要從入口1寫，也就是一旦從一個入口寫入，后面該資料的變更觸發的再次寫入也只能從這個入口繼續變更，

只有這樣才能保證這個資料不重復，好比先找到是哪家的孩子，再確定是第幾個孩子，且只能是基于這家內部去確認，

方案一：比如入口1遇到一個待寫入的資料，則先按自己的去重欄位A+B校驗，如果發現不存在該資料，則再按照入口2的去重欄位B+C（這個事先是知道的）判斷是否存在，若也不存在，則回到入口1寫入，若存在，則入口1不在寫入，且結束行程（因為入口2會觸發寫入該資料的），

方案二：比如入口1遇到一個待寫入的資料，則先按入口2的去重欄位B+C校驗，

查看對方入口下是否有重復資料，有，則本入口不寫（繼續按對方的路徑寫）；無，則自己的路徑寫，顯然方案二的判斷路徑更短，相對好一點，

3、同步基礎資料的時候是否提前過濾

這個在上面內容中也提到過，比如：A系統維護了員工的基礎資訊，其中有個狀態為【是否有效】，只有有效狀態的才能在整個系統中看得到才是生效的，B系統要取用員工資訊的資料，但不做資料維護，那么是否只取啟用狀態的資料到B，還是不區分狀態都取呢？

答案是：在資料量差異不大的情況下，取全量，

原因之一就是，若啟用狀態的用戶忽然被A系統禁用，那么可能該用戶在B系統的生產資料報錯，這時候到中間表看狀態就可以看出來問題，而不需跨系統或跨部門溝通查證，
后記：
原文來自公號 jjyypm
因為編輯器的問題 一度缺少圖片，若需看原文可以點擊這里：******系統間資料傳輸，產品經理視角的9千字總結：介面、otter、log4j、SFTP、MQ……******