記一次處理「跨終端資料同步」

需求：

終端a，終端b同時共享乙個list或數個list。終端a更新list時，終端b能在較短時間自動同步更新。

技術基礎：

前後端使用websocket協議進行雙向通訊。（ajax輪詢的方案伺服器壓力過大，同步的延遲時間也較長）

專案現狀與方案：

前端為保證各個頁面資料共享，減少部分頁面響應延遲在全域性存在資料模型(companymodel, typemodel, customermodel 等)。有快取資料，必然會出現與伺服器資料保持不一致的問題。在老專案裡靠重新整理頁面的同步方式如今是斷然不能在移動端或重資料操作的專案上進行。

前後端業務服務已經推進了數個迭代。推倒現有http協議而全部改有websocket工作量將十分的大，意味著完全重組現有資料請求邏輯。可行的方案只能是兩個相結合。仍然由http請求承擔資料拉取的工作，前端資料接收的流程不變。何時拉取新的資料，拉取哪乙個介面的資料。這些問題交由websocket來通知。實現上服務端將在http的響應流程中增加攔截中介軟體，並判斷是否需要推送更新訊號。

資料同步，便會涉及是增量同步還是全量同步的問題。在目前的專案現狀中，希望保持原有資料獲取流程不變。方便的自是針對不同的介面來進行全量資料同步。當然，這也是乙個優化點。要想高效的節省網路請求，終端與伺服器需校對資料的差異，在通知時即詳細告知具體差異和差異的內容。

實現與細節：

搭建基礎的websocket通訊：

前端的構建十分簡單，不再贅述。

後端的搭建有許多十分成熟的庫如：ws, socket.io,websocket 等。諸位根據自己的需要來選擇。我在篩選之後選擇了ws這個庫來實現nodejs部分的websocket服務。

使用websocket我們都熟知是在http的請求發起之後建立了websocket通訊。那麼中間發生了什麼？

關注http。http協議允許進行協議變更，存在upgrade機制。

這個http請求明確的告訴了自己的型別 upgrade。 upgrade的目標協議websocket。

伺服器在收到這條請求後將決定是否變更當前協議至websocket。

nodejs中的**實現可以參考ws模組的例子來實現。

websocket內容通訊約定：

op即資料操作型別；

model即是哪乙個資料模型發生了更新。

前端**，在解析出推送資料後，便執行相應介面的fetch操作。重新整理資料模型中的對應列表。以達到同步伺服器資料的任務。

後端需要決定在何時推送什麼樣的資料，以及推送給誰。

1.推送給誰

http的通訊識別身份一般由cookie或者header攜帶的字段實現，標示出來自於哪一位使用者。websocket通訊也一樣。在建立時它是http帶來，身份資訊自然在http上。socket建立後一直在伺服器的記憶體中保留。標示身份類似與賦值乙個屬性給乙個物件。標示了身份，便可以通過業務系統關聯相關的socket。boardcast 給每乙個關聯的socket。

(risk: socket如果過多，物理機的socket是有上限，服務本身的記憶體問題也不可忽視)

2.何時推送，推送什麼樣的資料

我的http服務框架由koa搭建。給koa增加乙個中介軟體攔截往來的http，依據method和url判斷出是哪乙個模型發生了操作，然後廣播。

export async function updateclientmodel(ctx: koa.context, next: function): promise = ctx;
const  = header;
if (!logininfo) 
const  = logininfo;
if (method === "get") 
await next();
// 僅請求成功時操作
if (!ctx.body || ctx.body.code != 0) 
// 檢查是否為納入推送範圍的資料
let  = getopandmodel(ctx.url, method);
if (!op || !model) 
// 將來需要合併多次推送請求。
boardcast();
}

總結：基於此，當多終端資料需要同步時便可在秒級響應同步資訊。

本文主在介紹實現思路，並未就詳細過程貼上實現**。程式設計是個細緻活，過程實現需要考慮很多細節。投向生產的**，簡單的原理卻不是簡單的事情。

往諸君共勉！

記一次處理「跨終端資料同步」

記一次同步千萬資料需求

記一次nginx解決跨域問題

記一次statspack錯誤處理

記一次處理「跨終端資料同步」

記一次同步千萬資料需求

記一次nginx解決跨域問題

記一次statspack錯誤處理

相關推薦