中心思想：分為同步頻率不等的兩個層次，一個近乎實時（分鐘甚至秒級別）定時同步，一個長時間（小時級甚至天級）定時同步。通過實時同步與資料庫的互動，執行長時間定時同步中的同步任務。 為什麼想到這個策略？最近在看 api 閘道器架構相關知識，想到閘道器中可能有一部分配置資訊需要定時同步，同時在系統執行時可能需要即時更新什麼配置。由於我們的 node.js 程序是無中心的多程序，因此想到了下面的混合策略來提供一方面可以低系統消耗即時更新配置，另一方面又可以長期同步配置的功能。 首先，長時間定時同步容易理解，類似下面的： // 每五個小時同步一次資訊 setInterval ( () => { longIntervalSyncFunc () ; }, HOUR * 5 ) ; 這種同步策略是常用的同步策略，既能及時同步資料，又不會對系統造成太大的負載。 有時候我們可能需要很快的同步資料，那麼，可能會寫成下面的形式： // 每五秒同步一次資訊 setInterval ( () => { shortIntervalSyncFunc () ; }, SECOND * 5 ) ; 這樣寫可以很快的同步資料，但是如果我們的資料變化得沒有那麼快，那麼很多次的同步操作都是無效操作，對系統性能造成了不少損耗。可以使用增量資料更新來減輕這個問題。 如果需要既能及時同步又能不顯著增加系統負擔，可以採用一種混合策略。 // 每五秒同步一次資訊 setInterval ( async () => { // 首先從 db 中查詢需要執行的同步函式 let rel = await db . get ( ' syncFuncNeedCall ' ) ; if (rel . someSyncFunc && rel . synced . indexOf (curProcess) < 0 ) { // 如果其中有這個函式，並且還沒有開始執行同步，就執行 await someSyncFunc () ; // 執行同步任務 await db . update ( ' syncFuncNeedCall ' ) ; // 更新資料庫中本程序執行同步任務的資訊，以及是否所有程序都已經執行過此同步任務 } }, SECOND * 5 ) ; 需要及時同步時，只需要更新一下資料庫中的資料，數秒內所有的程序就會開始執行同步任務。 每個程序執行完此同步任務之後，就在資料庫中標記本程序已經執行。所有程序都執行完畢之後，就可以標記本任務已執行，所有程序都不再執行此任務。 ----------------------------> end