Soul閘道器中的資料同步之Http長輪詢（二）

layout: post

title: soul閘道器中的資料同步之http長輪詢（二）

tags: soul

zookeeper、websocket資料同步的機制比較簡單，而http同步會相對複雜一些。soul借鑑了apollo、nacos的設計思想，取其精華，自己實現了http長輪詢資料同步功能。注意，這裡並非傳統的ajax長輪詢！

http 長輪詢機制如上所示，請求邏輯是soul閘道器主動請求soul-admin的配置服務。響應邏輯有兩種：soul-admin端本身的配置修改和60s的等待時間到了。

http請求到達sou-admin之後，並非立馬響應資料，而是利用servlet3.0的非同步機制，非同步響應資料。首先，將長輪詢請求任務longpollingclient扔到阻塞佇列blocingqueue中，並且開啟排程任務，每60s執行一次，將佇列中的請求拿出，傳送對應的響應。如果沒有發生配置資訊的更改，也需要對請求響應，好讓閘道器知道，不需要一直等待。當然，閘道器請求配置服務時，也有90s的超時時間。

class

longpollingclient
implements
runnable
@override
public
void
run(
), timeouttime, timeunit.milliseconds)
;//放到阻塞佇列中
clients.
add(
this);
}}

如果這段時間內，soul-admin發生了資料資訊的更改，此時，會挨個移除佇列中的長輪詢請求，並響應資料，告知是哪個group的資料發生了變更（我們將外掛程式、規則、流量配置、使用者配置資料分成不同的組）。閘道器收到響應資訊之後，只知道是哪個group發生了配置變更，還需要再次請求該group的配置資料。

// soul-admin發生了配置變更，挨個將佇列中的請求移除，並予以響應

class
datachangetask
implements
runnable
@override
public
void
run()}
catch
(throwable e)
}}

當soul-web閘道器層接收到http響應資訊之後，拉取變更資訊（如果有變更的話），然後再次請求soul-admin的配置服務，如此反覆迴圈。

長輪詢體現在請求任務會一直執行。

}}輪詢：客戶端每隔幾秒鐘向服務端傳送http請求，服務端在收到請求後，不論是否有資料更新，都直接進行響應。在服務端響應完成，就會關閉這個tcp連線。這種方式實現非常簡單，相容性也比較好，只要支援http協議就可以用這種方式實現。缺點就是非常消耗資源，會占用較多的記憶體和頻寬。

長輪詢：客戶端傳送請求後伺服器端不會立即返回資料，伺服器端會阻塞，請求連線掛起，直到服務端有資料更新或者是連線超時才返回，客戶端才再次發出請求新建連線、如此反覆從而獲取最新資料。相比輪詢，長輪詢減少了很多不必要的http請求次數，相比之下節約了資源。

soul閘道器資料同步方式之zookeeper

基於 zookeeper 的同步原理很簡單，主要是依賴 zookeeper 的 watch 機制，soul web 會監聽配置的節點，soul admin 在啟動的時候，會將資料全量寫入 zookeeper，後續資料發生變更時，會增量更新 zookeeper 的節點，與此同時，soul web 會監...

Soul閘道器中的Http服務探活

服務探活機制是為了發現系統中上下游服務的的狀態。當有新的服務註冊時要通知其他系統，當有服務下線時也要告知其他系統。soul閘道器中有對http服務處理的探活，所有的服務物件儲存在soul admin的upstream map中，這裡面的服務物件有兩個 乙個來自於原有的資料庫，乙個來自於其他服務的註冊...

Soul閘道器同步資料邏輯初探

按照前面兩個同步資料的分析，可以看到http同步跟其他的同步的載入基本一樣。不同的地方主要是載入資料的操作 載入資料的過程主要是 private void start else executor override suppresswarnings unchecked for datachangedl...