給產品經理的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……******