前言
最近知識星球中有位小夥伴問了我一個問題：如何快速同步第三方平台資料？
他們有個業務需求是：需要同步全國34個省市，多個系統的8種業務資料，到他們公司的系統當中。
他們需求同步全量的資料和增量的資料。
全量的資料主要是針對多個系統的曆史資料，大概有幾千萬資料，隻需要初始化一次即可。
而增量的資料，是系統後續變更的資料。
這個需求其實不簡單，至少有以下難點：
- 不能直接通路第三方資料庫。
- 不能将曆史資料導出到excel中，有洩露資料的風險。
- 如何快速同步曆史資料？
- 增量資料如何處理？
- 接口需要做限流嗎？
- 增量資料如何校驗資料的一緻性？
帶着這些問題，開始今天的文章之旅。
1. 如何快速同步曆史資料？
想要快速同步曆史資料，第一個想到的可能是直接同步資料庫中的資料。
但多個第三方系統為了資料安全考慮，不可能直接把他們的資料庫通路位址和相關賬号密碼告訴你。
即使他們告訴你了，但有很多個系統，你一個個去連資料庫查資料，也非常麻煩。
有些小夥伴可能會說：這好辦，讓第三方系統把他們的曆史資料導出到excel中，我們寫個程式解析去這些excel，就能将資料快速導入到我們的資料庫中。
這是個好辦法，但忽略了一點：這些資料是敏感資料，不能對外暴露。
是以導出excel的方案行不通。
那麼，該如何快速同步曆史資料呢？
答：使用SFTP。
不知道你有沒有跟銀行對接過，SFTP在銀行業務中經常會用到。
那麼，如何用SFTP同步資料呢？
2. 如何使用SFTP？
說起SFTP，就不得不說一說FTP。
我們都知道，FTP是用來傳送檔案的協定。使用FTP實作遠端檔案傳輸的同時，還可以保證資料傳輸的可靠性和高效性。
而SFTP是一種可以安全傳輸檔案的協定，它是一種基于SSH（Secure Shell）的檔案傳輸協定，它允許使用者将檔案以加密的形式傳輸到遠端伺服器上，以保護檔案的安全性。
FTP和SFTP有哪些差別呢？
- 連結方式不同：FTP使用TCP的21号端口建立連接配接。而SFTP是在用戶端和伺服器之間通過 SSH 協定 (即TCP22号端口) 建立的安全連接配接來傳輸檔案。
- 安全性不同：SFTP使用加密傳輸認證資訊和傳輸的資料，相對于FTP更安全一些。
- 傳輸效率不同：SFTP傳輸檔案時使用了加密解密技術，是以傳輸效率比普通的FTP要低一些。
- 使用協定不同：FTP使用了TCP/IP協定，而SFTP使用了SSH協定。
- 安全通道：SFTP協定提供了一個安全通道，用于在網絡上的主機之間傳輸檔案。而FTP協定沒有安全通道。
是以可見，我們使用SFTP來傳輸檔案還是比較安全的。
那麼，如何使用SFTP來實作同步曆史資料的需求呢？
答：這就需要我們做好SFTP的賬号、目錄和檔案格式的規劃了。
2.1 賬号權限控制
首先需要運維同學搭建一個SFTP伺服器，提供一個可以對外通路的域名和端口号。
然後需要在根目錄下，建立一個存放檔案的目錄，比如：/data。
然後給每個省市的第三方系統都建立一個子目錄，比如：/data/sichuan、/data/shenzhen、/data/beijing等。
接下來，我們需要給每個子目錄建立一個賬号，以及配置設定權限。
比如有個賬号是：sichuan，密碼是：sisuan123。這個賬号隻擁有/data/sichuan目錄讀資料和寫資料的權限。
另外一個賬号是：shenzhen，密碼是：shenzhen123。這個賬号隻擁有/data/目錄讀資料和寫資料的權限。
以此類推。
當然大家如果不放心，可以用線上工具，将密碼設定成一個8位的随機字元串，包含字母、數字和特殊字元，這樣的密碼安全性相對來說要高一些。
這樣相關的第三方系統都有往SFTP自己目錄下讀和寫資料的權限。
在這裡溫馨提醒一下：上面這些賬号讀資料的權限，主要是為了後面他們好排查問題用的，不是必須配置設定的，我們需要根據實際情況而定。
此外，還需要給我們自己配置設定一個賬号，開通對/data整個目錄的隻讀權限。
2.2 統一資料格式
接下來，最關鍵的一步是要制定一個統一的檔案格式和資料格式。
檔案名稱為：sichuan_20230724.txt。
也就是用 省市拼音_日期.txt 的格式。
這樣大家就能非常清楚的看出，是哪個省市，哪個日期産生的資料。
然後我們需要規定txt檔案的格式。
比如：id占20個字元，name占30個字元，金額占10個字元等等。
如果有些列的資料不滿對應的字元長度，前面可以補0。
這樣我們的程式，隻需要在解析txt檔案時，先讀取一行資料，是一個比較長的字元串，然後按照固定的長度，去解析字元串中每一列的資料即可。
2.3 使用job同步資料
假如第三方系統都按照我們要求，已将曆史資料寫入到指定目錄下的指定檔案中。
這時我們需要提供一個job，去讀取/data目錄下，所有子目錄的txt檔案，一個個解析裡面包含的曆史資料，然後将這些資料，做一些業務邏輯處理，然後寫入我們的資料庫當中。
如圖所示：
當然如果想快一點處理完，我們可以在job中使用多線程解析和讀取不同的txt檔案，然後寫資料。
3. 增量資料如何處理？
對于曆史資料，我們通過上面的方案，可以快速的同步資料。
但對于增量的資料如何處理呢？
增量的資料，對實時性要求比較高。
我們沒辦法跟之前一下，走SFTP同步檔案，然後使用job定時解析檔案的方案。
為了滿足資料實時性的需求，我們不得不走接口實時資料同步的方案。
那麼，是第三方系統提供接口，還是我們這邊提供接口呢？
很顯然，如果讓第三方提供接口，第三方有那麼多系統，我們需要對接很多很多接口，非常麻煩。
是以，這個接口必須由我們這邊提供。
我們這邊提供一個統一的資料上報接口，支援傳入批量的資料。
為了防止第三方系統，一次性傳入過多的參數，導緻該接口逾時，我們需要對單次上傳的資料條數做限制，例如：一次請求，最大允許上傳500條資料。
其實，光限制請求參數還不夠。
我們的這個資料上報接口，可能會被多個系統調用，并發量可能也不小。
為了防止在高并發下，請求量突增把我們的接口搞挂了，我們需要對接口限流。
我們可以使用redis記錄第三方系統請求的url和請求賬号，然後在程式中查詢redis中的次數，是否超過限額。允許每一個第三方系統，在1秒之内調用10次。第三方系統總的請求次數，1秒不超過500次。
如果超過了限額，則資料上報接口提示：請求太頻繁，請稍後再試。
為了增加資料上報接口的性能，在接收到資料之後，不直接寫庫。
我們可以将接口中接收到的資料作為mq消息，發送到mq伺服器。
然後有專門的mq消費者，實時監聽mq伺服器的消息，異步讀取消息寫入資料庫。
該方案比較适合，寫庫操作，包含了一些複雜的業務邏輯。
如果消費速度有點慢，我們可以及時調整mq消費者，使用多線程處理，或者增加mq中隊列的數量，增加mq消費者來增加消息的處理速度。
如果mq消費者在處理mq消息的過程中，由于網絡問題，寫庫失敗了，可以增加自動重試機制。
一旦mq消費者在mq消費過程中出現失敗的情況，則自動重試3次，如果還是失敗，則将消息寫入死信隊列，目前RocketMQ自帶了失敗重試功能。
然後有個job監控死信隊列，如果一旦發現異常資料，則發報警郵件給相關開發，後面人工處理。
4. 如何校驗資料一緻性？
通過上面的方案，我們把曆史資料和增量的資料都已經處理了。
但還有一個問題：如何校驗資料一緻性。
對于曆史資料，其實我們好處理，第三方系統已經生成好txt檔案上傳到SFTP上了，我們可以直接對比那些檔案即可。
但對于增量的資料，是第三方系統調用我們的資料上報接口，去上報的資料，這部分資料如何校驗資料一緻性呢？
答：我們可以要求第三方系統，在某日淩晨，生成一份昨日的增量資料到txt檔案，然後上傳到SFTP上。
我們有個job，在每天的淩晨1點會讀取第三方系統生成昨日增量資料，跟我們資料庫中昨日的增量資料做對比，校驗資料的差異性。
如果第三方後面産生的增量資料，隻有新增，沒有删除和修改，使用上面的方案是沒有問題的。
但如果增量的資料，包含了删除和修改的資料，可能會有問題。
因為我們做比較的資料源是昨日的增量資料，而我們的job在比較資料的過程中，萬一第三方系統上報了我們正在對比的資料，更新成了一個新值，跟昨日的值不一樣，這樣對比資料就會産生差異。
那麼，該如何解決這個問題呢？
答：我們可以隻校驗昨日的資料（就修改時間是昨天），今日産生的增量資料，會在明日淩晨1點的job中會去校驗的。
在比較時，周遊昨日增量txt檔案中的每行資料，跟資料庫中的資料做對比，如果id相同，但是修改時間是今天，則忽略這條資料。
如果id相同，修改時間是昨天，則判斷資料是否一緻，如果不一緻，則用txt檔案中的資料修複我們資料庫中的異常資料。
如果txt檔案中的id，在我們資料庫中不存在，則新增一條資料。
這兩種情況産生的資料變動，修改時間要設定成昨天，不然明日的job又會再重新處理一次這條資料。
來源：https://juejin.cn/post/7260053157698322488