zookeeper、websocket 資料同步的機制比較簡單，而 http 同步會相對複雜一些。soul 借鑑了 apollo、nacos 的設計思想，取其精華，自己實現了 http 長輪詢資料同步功能。注意：這裡並非傳統的 ajax 長輪詢！
http 長輪詢機制如上所示，soul-web 閘道器請求 admin 的配置服務，讀取超時時間為 90s，意味著閘道器層請求配置服務最多會等待 90s，這樣便於 admin 配置服務及時響應變更資料，從而實現準實時推送。
http 請求到達 sou-admin 之後，並非立馬響應資料，而是利用 servlet3.0 的非同步機制，非同步響應資料。首先，將長輪詢請求任務 longpollingclient 扔到 blocingqueue 中，並且開啟排程任務，60s 後執行，這樣做的目的是 60s 後將該長輪詢請求移除佇列，即便是這段時間內沒有發生配置資料變更。因為即便是沒有配置變更，也得讓閘道器知道，總不能讓其幹等吧，而且閘道器請求配置服務時，也有 90s 的超時時間。
如果這段時間內，管理員變更了配置資料，此時，會挨個移除佇列中的長輪詢請求，並響應資料，告知是哪個 group 的資料發生了變更（我們將外掛程式、規則、流量配置、使用者配置資料分成不同的組）。閘道器收到響應資訊之後，只知道是哪個 group 發生了配置變更，還需要再次請求該 group 的配置資料。有人會問，為什麼不是直接將變更的資料寫出？我們在開發的時候，也深入討論過該問題，因為 http 長輪詢機制只能保證準實時，如果在閘道器層處理不及時，或者管理員頻繁更新配置，很有可能便錯過了某個配置變更的推送，安全起見，我們只告知某個 group 資訊發生了變更。
同步流程分析
soul-admin 更改同步資料方式
閘道器服務開啟同步資料方式配置
啟動 soul-admin 、soul-bootstrap 、http-example
修改selector資訊看同步功能 符合預期
跟蹤同步流程
繼續跟蹤
從呼叫站的最頂層開始
其他斷點處都是通用處理邏輯，所以直接看這個httpsyncdataservice 裡面的處理流程
入口開啟去各個服務的任務（cas 處理了一波如果啟動了任務就無需在啟動了）
看下具體任務 （catch 的處理值得借鑑）
預設重試三次 出現異常超過重試次數時候休息時間較長5min 如果沒有超過重試次數睡眠時間短一些5s
繼續跟蹤下拉取資料 （這裡看到了官網說的再去來一次二次確認的處理）
跟進去看下處理方式
跟蹤了http長輪訓同步資料方式
分析了httpsyncdataservice 具體實現方式
通過目前這幾種同步方式，可以看出抽象出監聽資料變化介面，以及訂閱資料變化介面，抽象通用處理邏輯，尤其是同步記憶體資料那裡只需要替換不同實現類的原始資料同步方式，策略模式的具體應用。
soul閘道器資料同步方式之zookeeper
基於 zookeeper 的同步原理很簡單，主要是依賴 zookeeper 的 watch 機制，soul web 會監聽配置的節點，soul admin 在啟動的時候，會將資料全量寫入 zookeeper，後續資料發生變更時，會增量更新 zookeeper 的節點，與此同時，soul web 會監...
Soul閘道器同步資料邏輯初探
按照前面兩個同步資料的分析，可以看到http同步跟其他的同步的載入基本一樣。不同的地方主要是載入資料的操作 載入資料的過程主要是 private void start else executor override suppresswarnings unchecked for datachangedl...
Soul閘道器（九） Nacos同步資料
soul admin的nacos配置類nacosconfiguration初始化bean時通過nacosfactory建立配置服務。nacosdatachangedlistener 會監聽配置的變化，並將變化的配置存入本地記憶體，然後通過 nacos 的配置服務將變化的資料同步到 nacos 中 將...