中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：一個孤立的系統(tǒng)即使錄入了再多的數(shù)據(jù)，其本身的作用也是有限的，只有和其他系統(tǒng)產(chǎn)生關(guān)聯(lián)，互相之間進行數(shù)據(jù)對接和傳輸，才能發(fā)揮其真正的功能和作用。本篇文章中，作者為我們分析總結(jié)了獲取數(shù)據(jù)之后的握手方式、運算邏輯、異常規(guī)則、容錯機制、數(shù)據(jù)日志等等，希望對你有幫助。

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

世界最溫暖的舉例，是我在internet的另一端，而你挑著一筐剛刨出來的數(shù)據(jù)來看我。

——做產(chǎn)品的柏拉圖

一個系統(tǒng)裝再多數(shù)據(jù)，不與其他系統(tǒng)交互，那也是孤島系統(tǒng)，孤獨沒女朋友。

一個系統(tǒng)若很外向，不斷撩撥周圍的系統(tǒng)，也樂意被撩撥，成為了眾系統(tǒng)中的“交際花”，那么這貨基本就是中臺的性質(zhì)。

而更多的系統(tǒng)是介于上述兩種極端之間的。像人一樣，自己搞生產(chǎn)，也要參與社交——就是系統(tǒng)之間的數(shù)據(jù)對接。

對接的本質(zhì)是為了實現(xiàn)數(shù)據(jù)信息的傳輸。

在后端產(chǎn)品的世界里，各子系統(tǒng)之間，或與外部系統(tǒng)之間的對接非常常見。

作為產(chǎn)品經(jīng)理，不僅要知道數(shù)據(jù)從哪來，還要理清楚獲取數(shù)據(jù)之后的握手方式、運算邏輯、異常規(guī)則、容錯機制、數(shù)據(jù)日志等等。

本文嘗試聊聊如下話題：

• 數(shù)據(jù)傳輸?shù)膱鼍昂鸵饬x
• 數(shù)據(jù)傳輸?shù)姆绞?/li>
• 數(shù)據(jù)傳輸?shù)奶幚頇C制
• 數(shù)據(jù)傳輸?shù)淖⒁馐马?/li>

一、數(shù)據(jù)傳輸?shù)膱鼍昂鸵饬x

1. 數(shù)據(jù)傳輸?shù)膽脠鼍?/h3>

1）前端和后端本身無時不刻的數(shù)據(jù)互動

2）公司的各個系統(tǒng)之間的信息共享

比如，式系統(tǒng)部署之后，就需要各個系統(tǒng)模塊之間進行數(shù)據(jù)的配合，比如訂單系統(tǒng)的庫存扣減數(shù)據(jù)要同步給備貨系統(tǒng)進行采購。

3）與第三方平臺的對接

比如入駐第三方銷售平臺亞馬遜之后，店家可能自己需要管理自己的訂單，這時候就要從亞馬遜平臺獲取訂單數(shù)據(jù)，也就是抓取。

4）調(diào)用現(xiàn)成的公共插件

避免重復造輪子，市場上很多開放性的功能插件可以調(diào)用或接入，比如接入百度地圖的API，接入微信小程序的二次開發(fā)。

2. 數(shù)據(jù)傳輸?shù)囊饬x

1）不重復生產(chǎn)數(shù)據(jù)庫，避免資源和功能的浪費。

2）統(tǒng)一數(shù)據(jù)的維護或生產(chǎn)源頭，避免數(shù)據(jù)不同步。

比如同一個公司的兩個系統(tǒng)都要用人員信息架構(gòu)數(shù)據(jù)，如果各自都能維護，勢必出現(xiàn)不一致，也浪費資源。

3）別人家的數(shù)據(jù)，自己沒辦法生產(chǎn)。

4）復用現(xiàn)成的輪子，API或SDK共享（可能自己也發(fā)明不出來）。

二、數(shù)據(jù)傳輸?shù)姆绞?/h2>

數(shù)據(jù)傳輸?shù)姆绞?，作為產(chǎn)品經(jīng)理我將其分為：接口傳輸、中間件傳輸、message方式傳輸?shù)取Ｉ㈤_了說，比如：MQ（隊列）、HTTP接口、otter、文件共享傳輸?shù)取Ｃ恳环N又有細分的方式和適合的場景。

1. 接口

這是一種傳統(tǒng)的問答式的傳輸方式，是典型才c/s 交互模式。

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

目前我們常用的http調(diào)用、java遠程調(diào)用、webserivces 都屬于這種方式，只不過，不同的就是傳輸協(xié)議以及報文格式的區(qū)別。

1）接口的作用

通過接口，可以調(diào)用成熟的第三方功能插件為我所用（一般就是API接口），也可以根據(jù)實際需求由開發(fā)寫具體的接口代碼解決具體場合的信息傳輸問題（一般所說的http接口）。

對后端產(chǎn)品經(jīng)理來說，http接口的使用場景最多。比如：公司先上線了OA系統(tǒng)，后上線了訂單系統(tǒng)，訂單系統(tǒng)需要同步OA系統(tǒng)的人員組織結(jié)構(gòu)信息。那么一個可行做法就是OA系統(tǒng)創(chuàng)建一個接口，訂單系統(tǒng)請求，獲取最新的人員結(jié)構(gòu)信息。

這個籠統(tǒng)的方案描述中，包含了這么些信息：創(chuàng)建接口、請求接口、獲取最新信息等，那么分別是什么以及有什么原則呢？下面分別討論。

2）哪一方負責創(chuàng)建接口？

在討論需求的時候，開發(fā)會問哪方創(chuàng)建接口呢？有時候產(chǎn)品經(jīng)理只知道需要建接口，不知道哪個系統(tǒng)來建。

可以這樣理解，如果把數(shù)據(jù)源比成一缸水，那么接口就像是鑿的一個口，口只能是在缸上面的。

所以接口必須是在被請求的數(shù)據(jù)源這邊，由被請求的一方定義接口。

注意，這里的數(shù)據(jù)源是相對的數(shù)據(jù)源，就是被請求的一方就是數(shù)據(jù)源方。

實際上可能目標數(shù)據(jù)在請求方。比如例子中也可以是OA系統(tǒng)請求訂單系統(tǒng)，但是如果這樣的話，接口就是訂單系統(tǒng)創(chuàng)建了。因此確切說是被請求的一方創(chuàng)建接口。

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

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

3）什么是定義接口

定義接口，其實就是定義缸上的出水口。口的大小、濾網(wǎng)、放水的頻率等，就是個規(guī)則。

這個規(guī)則約定了哪些數(shù)據(jù)是需要流過去，以及流過去的條件（像門禁密碼一樣）。

定義接口就是設定口令、數(shù)據(jù)范圍、推送前的篩選、轉(zhuǎn)化運算規(guī)則等，這是接口的核心內(nèi)容。

4）數(shù)據(jù)在哪一方做轉(zhuǎn)義？

某些時候，數(shù)據(jù)從源頭到應用端不是原封不動的，而是轉(zhuǎn)化了。比如80分、90分都是及格，可能使用者只需要兩個值：及格or不及格。

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

考慮的依據(jù)主要是：該數(shù)據(jù)獲取之后是否還有其他用處，只要有可能被二次使用，最好是取原數(shù)據(jù)。

提前轉(zhuǎn)化的好處是，流轉(zhuǎn)的數(shù)據(jù)會變得簡單直接。但是需要注意的是轉(zhuǎn)化后數(shù)據(jù)量不一定會少，比如：數(shù)據(jù)源是訂單維度的，而目標是轉(zhuǎn)化為訂單+商品維度的數(shù)據(jù)，這就可能一條變多條了。

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

有時候開發(fā)還會問是對方推，還是我們主動去取，這就是接口的post/ get方式問題。

get是從服務器方請求數(shù)據(jù)，post是向服務器方傳送數(shù)據(jù)。前面也提到了，接口交互數(shù)據(jù)可以是主動推送，也可以是請求獲取。

主動推送一般是數(shù)據(jù)生產(chǎn)方一旦更新，則觸發(fā)推送，將所需字段對應值傳遞過去。

請求獲取就是數(shù)據(jù)需求方傳遞請求參數(shù)（請求參數(shù)一般是若干條件，比如：賬號+密碼）。數(shù)據(jù)生產(chǎn)方則按照協(xié)議響應，給出滿足條件的數(shù)據(jù)到請求方（也就是返回參數(shù)）。

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

如果是時效不高或者數(shù)據(jù)量大，則可以按一定頻率主動請求，有利于系統(tǒng)負荷壓力穩(wěn)定。

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

另外，選擇post/ get，最終由雙方開發(fā)權(quán)衡決定，但是一般而言：

• get傳送的數(shù)據(jù)量較小，不能大于2KB。
• post傳送的數(shù)據(jù)量較大，一般被默認為不受限制。get安全性非常低，post安全性較高。

6）接口定義是開發(fā)的事情，但產(chǎn)品經(jīng)理需要給出輪廓

在輸出方案的時候，接口定義的規(guī)則是什么？傳參和返回參數(shù)是什么？重復傳參時是跳過還是再次獲取（一般都再獲?。勘貍鲄?shù)是什么？是否回傳接收結(jié)果給數(shù)據(jù)生產(chǎn)方？這些都是要有大致明確并傳達給開發(fā)測試的。

比如：每小時/次取對方表中第一頁最新的50條數(shù)據(jù)。超過的數(shù)據(jù)下個小時繼續(xù)取?？梢赃@樣設計：

因為一些關(guān)鍵參數(shù)牽扯到業(yè)務的唯一性維度，這些都在產(chǎn)品經(jīng)理調(diào)研的時候獲知的，而這些可能開發(fā)根本不知道。因此產(chǎn)品經(jīng)理要給出輪廓和大概方向。

7）數(shù)據(jù)流轉(zhuǎn)的時效

接口創(chuàng)建之后，如果是接收的對方數(shù)據(jù)庫中的信息，那么上線之后，要考慮先進行數(shù)據(jù)的初始化（保持基礎數(shù)據(jù)一致）。然后確保后續(xù)雙方是同步的。

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

觸發(fā)式就是一旦一個參數(shù)值滿足條件，則觸發(fā)同步。

定時任務式一般用在不知道數(shù)據(jù)源什么時候更新，需求方就要設置一個定時任務的腳本，隔一段時間查詢一次。請求的頻率需要與更新的頻率相協(xié)調(diào)。

8）總結(jié)接口的特點

優(yōu)點：時效性強，可以觸發(fā)式實時問答。容易控制權(quán)限，通過傳輸層協(xié)議https，加密傳輸?shù)臄?shù)據(jù)，使得安全性提高。通用性比較強，無論客戶端是.net架構(gòu)，java，python 都是可以的。

缺點：服務器和客戶端必須同時工作，當服務器端不可用的時候，整個數(shù)據(jù)交互是不可進行。當傳輸數(shù)據(jù)量比較大的時候，嚴重占用網(wǎng)絡帶寬，可能導致連接超時。使得在數(shù)據(jù)量交互的時候，服務變的很不可靠。

9）相關(guān)概念擴展

API：即“應用程序編程接口”，是一些預先定義的函數(shù)，無需訪問源碼或理解內(nèi)部工作機制的細節(jié)，即可調(diào)用的對象。比如和Windows系統(tǒng)溝通，需要調(diào)用Windows提供得API。和新浪微博進行溝通，需要調(diào)用新浪微博提供得Api。其實它就是一個軟件系統(tǒng)對其他軟件系統(tǒng)提供得服務。

open api：是指對外開發(fā)的接口，比如百度地圖API、facebook的API等。

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

http接口：是基于接口的傳輸方式（HTTP協(xié)議）來命名的，當然也有基于其他協(xié)議傳輸?shù)慕涌凇?/p>

比如：

和Windows系統(tǒng)溝通，需要調(diào)用Windows的API（CreateWindowEx, bitblt,等等），是C語言函數(shù)形式的接口。

和.Net框架進行溝通，需要調(diào)用.Net提供得Api，是以C#，VB函數(shù)/類形式的接口。和新浪微博進行溝通，需要調(diào)用新浪微博提供得Api，是以Http請求形式的接口。

API接口的叫法相對http接口叫法更籠統(tǒng)和概念化一些。因此在寫方案的時候，http接口和API接口都可以，在具體的場景開發(fā)都可以理解的。

2. 數(shù)據(jù)庫對庫同步

接口完成的是信息的傳輸，相對來說比較保守，易于保護敏感信息。而數(shù)據(jù)庫同步實際就是表對表的共享，相對接口就大方多了，因此多發(fā)生在企業(yè)內(nèi)部兩小無猜的系統(tǒng)之間。

數(shù)據(jù)庫同步有這么幾種辦法：

1）使用中間表

例如：B系統(tǒng)要用A系統(tǒng)的數(shù)據(jù)，可以新建一個數(shù)據(jù)庫DB，A系統(tǒng)將數(shù)據(jù)寫入DB，B系統(tǒng)再到數(shù)據(jù)庫中讀取數(shù)據(jù)。

也就是將數(shù)據(jù)放進一個中間表中，A、B兩個系統(tǒng)都對這個表有訪問權(quán)限。這樣的好處就是選擇性地將一大批數(shù)據(jù)共享出去。

2）直接調(diào)取對方數(shù)據(jù)表

這個方式就是在B系統(tǒng)在開發(fā)時，在代碼中加載A系統(tǒng)的數(shù)據(jù)表，直接從數(shù)據(jù)表中取數(shù)據(jù)。

這就是實時拉取對方的數(shù)據(jù)，B系統(tǒng)自己本地不做表保存。比較省，事但是耦合性較大，數(shù)據(jù)量大的時候不建議。

3）同步對方的數(shù)據(jù)表

直接將對方的數(shù)據(jù)表copy一份過來，并保持實時同步，otter技術(shù)就是常用的一個方法。

otte可以將mysql的數(shù)據(jù)同步至另外mysql或者oracle，也支持雙向同步（即A庫同步給B庫，B庫也同步給A庫）、文件同步等，主要應用應用是多數(shù)據(jù)中心、BI系統(tǒng)抽取數(shù)據(jù)、災備。

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

該方式主要用于內(nèi)部系統(tǒng)之間（一般一個公司的才這樣）庫對庫的傳輸，可以實現(xiàn)數(shù)據(jù)的相互同步更新。建議應用在數(shù)據(jù)量大的時候，或者基礎數(shù)據(jù)對周邊兄弟系統(tǒng)提供基礎支持的時候。優(yōu)點是占用資源少，交互更加簡單可靠。

當連接B的系統(tǒng)越來越多的時候，由于數(shù)據(jù)庫的連接池是有限的，導致每個系統(tǒng)分配到的連接不會很多，當系統(tǒng)越來越多的時候，可能導致無可用的數(shù)據(jù)庫連接。

這時候otter比較適合。而兩個不同公司的系統(tǒng)，不太會開放自己的數(shù)據(jù)庫給對方連接，因為這樣會有安全性影響。

3. 文件包共享方式

一些第三方公司為了保密，不愿意提供接口，那么會把文件存在類似網(wǎng)盤或網(wǎng)頁上，供需求方下載。

雙方系統(tǒng)約定文件服務器地址、密碼、文件命名規(guī)則、文件內(nèi)容格式等，通過上傳文件到文件服務器，進行數(shù)據(jù)交互，對大數(shù)據(jù)量的也很適合。

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

比如：第三方支付公司與需求方約定好SFTP服務器（一種文件服務器，可以理解為網(wǎng)盤）的賬號密碼，然后支付公司將賬單數(shù)據(jù)上傳到SFTP服務器上，那么需求方就可以登陸SFTP客戶端，進行下載、解析，然后保存使用。這也實現(xiàn)了數(shù)據(jù)在服務器之間的傳輸。

實際上這些數(shù)據(jù)本身也是加密的，所以只有協(xié)議的公司才能拿到解碼鑰匙。長期合作的公司就會持續(xù)更新，授權(quán)的公司就可以持續(xù)下載和解析。這里就有一個下載頻率的問題，一般使用定時任務按一定頻率去下載。并且要考慮丟包的機制。

案例：

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

到SFTP服務器找到文件路徑，篩選出需要的類型文件，打開文件，按規(guī)則解析所需的字段，對應寫入本地數(shù)據(jù)表。

腳本執(zhí)行邏輯：每次抓取路徑下‘修改時間’為前一天的文件。（這里有個隱患：如果出了故障，可能某天的數(shù)據(jù)就漏了）。

問題：怎么防止丟抓呢？

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

斷抓補抓機制：比如4號抓了修改時間為3號的數(shù)據(jù)。5號斷抓，則6號繼續(xù)抓取4、5號的數(shù)據(jù)。斷抓補抓的機制就是說一旦某一天的數(shù)據(jù)中斷了，發(fā)現(xiàn)不連續(xù)，那么系統(tǒng)就自動在下次重新抓一次，看看是否能補上。直到三次都未取到。則不再補救。

該方案可以降低我方抓取故障導致的抓空情況。有時候開發(fā)懶省事不愿意考慮這么多，這時候產(chǎn)品經(jīng)理要提醒他。

4. 消息隊列MQ（Message Queue）

1）MQ概念

消息隊列技術(shù)是分布式應用間交換信息的一種技術(shù)。目前市場上有很多開源的jms消息中間件，比如ActiveMQ, OpenJMS。

簡單說就是一方不斷把信息推到隊列中，像排隊進隧道一樣，另一方依次消費這些信息。消息隊列可駐留在內(nèi)存或磁盤上，隊列存儲消息直到它們被應用程序讀走。

該方式更適用于公司內(nèi)部，數(shù)據(jù)量大，規(guī)律性強，批量往來的數(shù)據(jù)。主要解決應用解耦，異步消息，流量削鋒等問題。

2）以異步處理舉例說明

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

a. 串行方式

b. 并行方式

假設三個業(yè)務節(jié)點每個使用50毫秒鐘，不考慮網(wǎng)絡等其他開銷，則串行方式的時間是150毫秒，并行的時間可能是100毫秒。

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

小結(jié)：如以上案例描述，傳統(tǒng)的方式系統(tǒng)的性能（并發(fā)量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？

引入消息隊列，異步處理。改造后的架構(gòu)如下：

按照以上約定，用戶的響應時間相當于是注冊信息寫入數(shù)據(jù)庫的時間，也就是50毫秒。注冊郵件，發(fā)送短信寫入消息隊列后，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構(gòu)改變后，系統(tǒng)的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了兩倍。

在設計方案的時候要注意異常情況的處理機制。比如：首次消費失??？

如果第一次數(shù)據(jù)消費的時候，無法識別沒有匹配上，但是又想下次再消費一次看是否匹配的上怎么辦？可以設定機制：無法識別的則重新插到隊列后面繼續(xù)推送。

如果一直循環(huán)仍消費不掉信息積壓怎么辦？

設定處理機制：超過一定積壓數(shù)據(jù)量或者循環(huán)時間過長則進行報警。

3）MQ、文件包共享、接口的對比

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

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

文件包共享也不需要反饋機制，因此傳到了文件服務器之后，數(shù)據(jù)方的事情就做完了。

隊列的一個信息只能被消費一次，不同系統(tǒng)不能共同消費一個隊列。因此如果對接多個系統(tǒng)則要多次創(chuàng)建MQ。而接口可以創(chuàng)建一個，讓其他很多系統(tǒng)調(diào)取。

在訂單系統(tǒng)對接各個銷售網(wǎng)站和平臺的時候就可以采用這樣的機制，避免多次對接。文件包共享也是可以上傳一次，供多個需求方下載。這點和接口有相似之處，是MQ所不具備的。

5. 其他手段

數(shù)據(jù)傳輸包含了數(shù)據(jù)信息的獲取和寫入，其實除了線上的自動機制，還有很多土辦法，在后端產(chǎn)品系統(tǒng)中也是常使用的。

1）導入導出

場景：沒有辦法做系統(tǒng)之間的對接，但是線下能獲得數(shù)據(jù)。數(shù)據(jù)量不太大，且有規(guī)則數(shù)據(jù)。則可以通過導入的方式。

文檔一般用csv格式，該格式文件較小，兼容性好，然后需要定義好excel表格對應字段的關(guān)系，比如A列對應字段‘name’，B列對應字段’age’。

上傳時需要對文件檢驗，比如格式不對、必填項為空等，建議一旦一處錯誤，就全部不予導入。并返回錯誤提示，修改后繼續(xù)導入。

若數(shù)據(jù)太大（與服務器的性能也有關(guān)系，比如超過一萬條），可以采用異步上傳機制，就是上傳之后不立即執(zhí)行寫入，而是后臺自動分批寫入。

2）爬取

作為數(shù)據(jù)需求方，獲取數(shù)據(jù)可以通過協(xié)商接口的方式、SFTP解析的方式、或者直接爬取的方式。比如需要獲取第三方網(wǎng)站商標庫中最新商標名稱、注冊地、logo、授權(quán)期限等信息，如果該網(wǎng)站不給于開放的接口授權(quán)，可能就需要我們開發(fā)寫爬蟲代碼爬取（當然有的商業(yè)數(shù)據(jù)也是帶有反爬機制的，這就看誰道高一尺魔高一丈了）。

三、數(shù)據(jù)傳輸?shù)奶幚頇C制

1. 數(shù)據(jù)同步的觸發(fā)機制

前面提到了數(shù)據(jù)獲取的方式，那么數(shù)據(jù)獲取頻次或者觸發(fā)機制是怎么樣的呢？這要根據(jù)應用場景來設定方案，但是一般都是要求持續(xù)獲取的。

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

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

比如說每次獲取A系統(tǒng)6小時內(nèi)更新的數(shù)據(jù)，那么每2小時取一次的話是沒問題的。但是若每7小時獲取一次就會漏掉1小時的數(shù)據(jù)。因此一定是每次獲取的數(shù)據(jù)時間區(qū)間，要高于數(shù)據(jù)獲取的時間間隔。

當然用時間是一種維度，更安全的是用標示性字段。比如每次獲取is_got為0的數(shù)據(jù)。前臺是is_got做表索引（索引前面講到過），這樣遍歷（遍歷約等于全表查詢）數(shù)據(jù)庫的時候就不會太慢。

2. 是否異步執(zhí)行數(shù)據(jù)處理

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

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

這時候就很容易出錯，因為分攤規(guī)則是個算法，算法就帶有規(guī)則的可變動性。一旦分攤規(guī)則的參數(shù)不準確，或者算法結(jié)構(gòu)變化，都會導致最終分攤的運費金額錯誤。那么這時候追查錯誤原因并修復數(shù)據(jù)就很麻煩。

所以在進行分攤之前，先落地到財務系統(tǒng)的臨時表（中間表）中，然后獲取數(shù)據(jù)完成。再進行寫入分攤運費的操作。

除了上述方便查錯誤原因外（有種數(shù)據(jù)清洗的意思），這種異步操作同時也確保了較少的偶聯(lián)，不至于一個環(huán)節(jié)出錯，則聯(lián)動出錯。同時它作為一個基礎數(shù)據(jù)，也可以被其他功能調(diào)用。若數(shù)據(jù)量萬級以上的，必須這樣做。

3. 判重機制

數(shù)據(jù)通道搭建好之后，數(shù)據(jù)流往往是持續(xù)獲的。而數(shù)據(jù)源在別人那里，可能會被增刪改，因此常常有相似或相關(guān)的數(shù)據(jù)進來。

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

比如職工信息表：（姓名+手機號+性別+家鄉(xiāng)+身份證號）。（姓名+手機號+性別+家鄉(xiāng)）這幾個字段對一個職工不一定唯一，但是身份證號就是唯一的。因此如果我們更新這里的數(shù)據(jù)，就以身份證號為唯一標示。

比如獲取到同一個身份證號的手機號與我們的數(shù)據(jù)庫的不同，則更新。遇到我們的數(shù)據(jù)庫不存在的身份證號碼則插入。

某些時候無法確定那幾個是唯一字段，則可以添加一個備用字段，人為定義其取值規(guī)則，然后作為去重字段，比如這個字段叫unique_code，取數(shù)據(jù)源表的主鍵+日期，（或者直接就取源表的id，也就是外鍵）。

有了判重字段（也就是數(shù)據(jù)唯一的字段），就可以進行更新、插入或者跳過規(guī)則設定了。

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

4. 獲取到數(shù)據(jù)之后，如果使用?

一種是直接在頁面展示，不保存在本地數(shù)據(jù)庫中。相當于每刷新一次頁面則通過接口調(diào)取一次對方的數(shù)據(jù)展示。但這種從性能和場景上都是比較少的，一般都是先保存到本地數(shù)據(jù)庫上，自己本地各種調(diào)用。

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

5.處理日志

數(shù)據(jù)日志：目的是記錄數(shù)據(jù)的來龍去脈，追溯以分析問題。

日志要記錄三個主要事項：數(shù)據(jù)源系統(tǒng)是否提供數(shù)據(jù)、目標系統(tǒng)是否接收到數(shù)據(jù)、目標系統(tǒng)是否寫入了數(shù)據(jù)。

產(chǎn)品經(jīng)理告訴開發(fā)加數(shù)據(jù)捕獲日志的時候，需要告知是否存到表里，因為系統(tǒng)一般都有一個類似緩存一樣的日記，只是會定期清理的。只有保存下來才能一直記錄和追溯。

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

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

根據(jù)實習需要，存了數(shù)據(jù)庫就可以做成頁面，展示給用戶看，比如可以從以下維度展示：

四、數(shù)據(jù)傳輸?shù)淖⒁馐马?/h2>

1. 目標數(shù)據(jù)表最好和中間表的維度一致

假設從A系統(tǒng)獲取的數(shù)據(jù)存入B系統(tǒng)，先落地到中間表b，然后經(jīng)過一些列運算后將數(shù)據(jù)從b寫入到b’表。

注意b和b’表的去重字段要對應起來，并傳遞下去。因為維度相同，做到一對一，方便實現(xiàn)異常數(shù)據(jù)溯源。

2. 不同入口寫入同一類型數(shù)據(jù)時，如何與自身入口的數(shù)據(jù)去重，且與其他入口的數(shù)據(jù)互相去重？

案例：有新舊兩個不同的寫入程序，寫數(shù)據(jù)到利潤表，寫入的都是‘退件入庫’利潤類型，是殊途同歸。不巧的是兩個寫入入口各自有本身的去重規(guī)則，彼此去重的規(guī)則不能通用：假設入口1對應的去重字段是A+B，入口2寫入的去重字段是B+C。

這就意味著同一個數(shù)據(jù)如果分多次寫入，有可能從兩個入口都會寫入。如何實現(xiàn)避免重復寫入是核心問題。

我們首先考慮的是，如果一條源信息從一個入口已經(jīng)寫入了利潤表，那么就不能從另一個入口再寫。

其次，如果從入口1寫入一次，那么后面源數(shù)據(jù)更新再次觸發(fā)寫入的時候（判重，確定是插入還是更新），就還要從入口1寫。也就是一旦從一個入口寫入，后面該數(shù)據(jù)的變更觸發(fā)的再次寫入也只能從這個入口繼續(xù)變更。

只有這樣才能保證這個數(shù)據(jù)不重復。好比先找到是哪家的孩子，再確定是第幾個孩子，且只能是基于這家內(nèi)部去確認。

方案一：比如入口1遇到一個待寫入的數(shù)據(jù)，則先按自己的去重字段A+B校驗。如果發(fā)現(xiàn)不存在該數(shù)據(jù)，則再按照入口2的去重字段B+C（這個事先是知道的）判斷是否存在，若也不存在，則回到入口1寫入。若存在，則入口1不在寫入，且結(jié)束進程（因為入口2會觸發(fā)寫入該數(shù)據(jù)的）。

方案二：比如入口1遇到一個待寫入的數(shù)據(jù)，則先按入口2的去重字段B+C校驗。

查看對方入口下是否有重復數(shù)據(jù)，有，則本入口不寫（繼續(xù)按對方的路徑寫）；無，則自己的路徑寫。顯然方案二的判斷路徑更短，相對好一點。

3. 同步基礎數(shù)據(jù)的時候是否提前過濾

這個在上面內(nèi)容中也提到過。比如：A系統(tǒng)維護了員工的基礎信息，其中有個狀態(tài)為【是否有效】，只有有效狀態(tài)的才能在整個系統(tǒng)中看得到才是生效的。B系統(tǒng)要取用員工信息的數(shù)據(jù)，但不做數(shù)據(jù)維護。那么是否只取啟用狀態(tài)的數(shù)據(jù)到B，還是不區(qū)分狀態(tài)都取呢？

答案是：在數(shù)據(jù)量差異不大的情況下，取全量。

原因之一就是，若啟用狀態(tài)的用戶忽然被A系統(tǒng)禁用，那么可能該用戶在B系統(tǒng)的生產(chǎn)數(shù)據(jù)報錯，這時候到中間表看狀態(tài)就可以看出來問題，而不需跨系統(tǒng)或跨部門溝通查證。

#專欄作家#

唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產(chǎn)品經(jīng)理專欄作家，2019年年度作者。《后端產(chǎn)品經(jīng)理寶典》作者，藥學碩士轉(zhuǎn)行互聯(lián)網(wǎng)產(chǎn)品多年；熟悉跨境電商業(yè)務，醫(yī)藥領域；擅長大型后臺體系，社交APP。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來自pixabay，基于CC0協(xié)議。