摘要:服務器大規(guī)模下發(fā)數(shù)據(jù)幀時,可進行有效的擁塞控制超時重發(fā),可有效提升集群設備的可靠性,降低集群設備的研發(fā)難度。幀調(diào)度策略由于這些問題,故自行制定如下幀調(diào)度策略,實踐表明,該策略可最大程度上解決以上問題。
「博客搬家」 原地址: 簡書 原發(fā)表時間: 2017-07-19
最近正在做一個 Java 后端項目「大規(guī)模集群設備的管理平臺」。使用 Spring 作為基礎框架,使用 Netty 搭建 TCP 服務器與上萬臺設備組成的集群通信,使用基于 JavaFX 的圖形界面應用程序模擬上萬臺設備的行為,并可對服務器進行壓力測試。
本項目的基礎實現(xiàn)架構已開源,訪問以下地址獲取:「GitHub」
Java 服務器中,由于眾多硬件設備的數(shù)據(jù)幀處理能力較差,可靠性較差,所以在 Netty 模塊中使用的幀調(diào)度算法。服務器大規(guī)模下發(fā)數(shù)據(jù)幀時,可進行有效的擁塞控制、超時重發(fā),可有效提升集群設備的可靠性,降低集群設備的研發(fā)難度。
1. Netty 模塊和大規(guī)模集群設備通信遇到的問題硬件設備的幀處理能力較差,單臺設備最大處理能力為 20 幀/秒,服務器需進行流量控制,避免到達設備的處理極限。
硬件設備的可靠性較差,偶爾會出現(xiàn)丟幀的情況,故雖使用 TCP 協(xié)議,服務器仍需自行保證整個通信的可靠性。
2. 幀調(diào)度策略由于這些問題,故自行制定如下幀調(diào)度策略,實踐表明,該策略可最大程度上解決以上問題。
「注」本部分為源碼「Netty服務器」部分的解釋說明,需結合源碼進行閱讀。2.1 服務器發(fā)送 Message 指令策略
源碼從此處獲取:「GitHub」
服務器 ServerTcpMessageHandler 對象首先檢查鏈表雙端隊列「LinkedBlockingDeque」中待發(fā)送幀的數(shù)量,若數(shù)量大于限定數(shù)量,則將待執(zhí)行指令「Message」傳入時間輪進行等待,使之在預訂的時間后執(zhí)行。
2.2 Message 指令執(zhí)行策略待執(zhí)行的指令 Message 有兩種:
基本指令:普通幀生成指令,該指令分為以下 2 種:
復合指令:一條指令需要多個 CAN 幀才能完整表示
簡單指令:一條指令生成一個 CAN 幀
WebMsgSpecial:包含特殊執(zhí)行指令,該指令均內(nèi)含一條普通指令,該指令分為以下 3 種:
廣播發(fā)送:發(fā)送至一組或多組設備
緊急發(fā)送:將生成的 CAN 幀放置在隊列首位,以便優(yōu)先發(fā)送
不設置檢錯重發(fā):該 CAN 幀無回復,或重復發(fā)送該幀易導致設備異常
Netty 通道「WebMsgOutBoundHandler」接收到待執(zhí)行的指令 Message,根據(jù) Message 指令進行執(zhí)行,生成 CAN 幀并被 SendableMsg 對象包裹,具體執(zhí)行策略如下:
若為基本指令:生成相對應的一個或多個 CAN 幀,并添加進入不同的 SendableMsg 對象,執(zhí)行策略設為非緊急和開啟檢錯重發(fā)機制。
若為 WebMsgSpecial 指令
若為廣播指令:將內(nèi)含 Message 根據(jù)廣播指令生成多條其他 WebMsgSpecial 指令
若為其他指令:生成 CAN 幀和對應的 SendableMsg 對象的同時,將「緊急」和「檢錯重發(fā)」標識添加進 SendableMsg 對象
Netty 通道「WebMsgOutBoundHandler」接收到待執(zhí)行的「執(zhí)行通道」指令 SendableMsg,根據(jù)指令進行執(zhí)行:
1) SendableMsg 指令執(zhí)行策略若為「緊急」指令,將內(nèi)含的 CAN 幀放置在隊列首位,以便優(yōu)先發(fā)送
若為「不檢錯重發(fā)」指令,在內(nèi)含的 CAN 幀被發(fā)送后,不執(zhí)行「檢錯重發(fā)」操作
若為「普通」指令,執(zhí)行「非緊急」操作和「檢錯重發(fā)」操作
在隊列中選取首位 SendableMsg 對象,內(nèi)含 CAN 幀被發(fā)送的同時,CAN 幀的「組號」、「設備號」和「功能位」組成 Key,CAN 幀作為 Value,添加進 HashMap 中,并在時間輪上設置「檢錯重發(fā)」策略,該策略在約定延遲時間后執(zhí)行,之后在 TCP 通道發(fā)送該 CAN 幀。
在約定延遲時間內(nèi),Netty 的 InBound 處理通道收到特定 CAN 幀的回復,則將特定 CAN 幀的「Key, Value」對從 HashMap 中移除。
在約定時間后,執(zhí)行時間輪「檢錯重發(fā)」策略:
檢測 HashMap 中相應 CAN 幀的「Key, Value」對:
若為空,則服務器收到該 CAN 幀的回復,該策略終止
若不為空,則服務器未收到該 CAN 幀的回復,查看 SendableMsg 對象的執(zhí)行次數(shù)
若次數(shù)大于 3 次,Netty 模塊向 Server 模塊發(fā)送設備通信故障 Message,將該設備設為異常狀態(tài)。
若次數(shù)小于 3 次,根據(jù) SendableMsg 指令的內(nèi)含操作重新執(zhí)行。
3. 參考資料本項目的「GitHub」
Netty 源碼解讀之時間輪算法實現(xiàn)-HashedWheelTimer
文章版權歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/68247.html
摘要:消息與邏輯請求或響應消息對應的完整的一系列幀。聲明數(shù)據(jù)流依賴關系指出,應盡可能先向父數(shù)據(jù)流分配資源,然后再向其依賴項分配資源。數(shù)據(jù)流應先于和獲得完整資源分配和應先于和獲得相同的資源分配和應基于其權重獲得比例分配。 轉(zhuǎn)載自 | 小米運維(公眾號 ID:MI-SRE)showImg(https://segmentfault.com/img/bVbbesG?w=344&h=344); HTT...
摘要:后端好書閱讀與推薦系列文章后端好書閱讀與推薦后端好書閱讀與推薦續(xù)后端好書閱讀與推薦續(xù)二后端好書閱讀與推薦續(xù)三這里依然記錄一下每本書的亮點與自己讀書心得和體會,分享并求拍磚。然后又請求封鎖,當釋放了上的封鎖之后,系統(tǒng)又批準了的請求一直等待。 后端好書閱讀與推薦系列文章:后端好書閱讀與推薦后端好書閱讀與推薦(續(xù))后端好書閱讀與推薦(續(xù)二)后端好書閱讀與推薦(續(xù)三) 這里依然記錄一下每本書的...
摘要:后端好書閱讀與推薦系列文章后端好書閱讀與推薦后端好書閱讀與推薦續(xù)后端好書閱讀與推薦續(xù)二后端好書閱讀與推薦續(xù)三這里依然記錄一下每本書的亮點與自己讀書心得和體會,分享并求拍磚。然后又請求封鎖,當釋放了上的封鎖之后,系統(tǒng)又批準了的請求一直等待。 后端好書閱讀與推薦系列文章:后端好書閱讀與推薦后端好書閱讀與推薦(續(xù))后端好書閱讀與推薦(續(xù)二)后端好書閱讀與推薦(續(xù)三) 這里依然記錄一下每本書的...
摘要:后端好書閱讀與推薦系列文章后端好書閱讀與推薦后端好書閱讀與推薦續(xù)后端好書閱讀與推薦續(xù)二后端好書閱讀與推薦續(xù)三這里依然記錄一下每本書的亮點與自己讀書心得和體會,分享并求拍磚。然后又請求封鎖,當釋放了上的封鎖之后,系統(tǒng)又批準了的請求一直等待。 后端好書閱讀與推薦系列文章:后端好書閱讀與推薦后端好書閱讀與推薦(續(xù))后端好書閱讀與推薦(續(xù)二)后端好書閱讀與推薦(續(xù)三) 這里依然記錄一下每本書的...
摘要:如問到是否使用某框架,實際是是問該框架的使用場景,有什么特點,和同類可框架對比一系列的問題。這兩個方向的區(qū)分點在于工作方向的側重點不同。 [TOC] 這是一份來自嗶哩嗶哩的Java面試Java面試 32個核心必考點完全解析(完) 課程預習 1.1 課程內(nèi)容分為三個模塊 基礎模塊: 技術崗位與面試 計算機基礎 JVM原理 多線程 設計模式 數(shù)據(jù)結構與算法 應用模塊: 常用工具集 ...
閱讀 2642·2019-08-30 15:52
閱讀 3589·2019-08-29 17:02
閱讀 1835·2019-08-29 13:00
閱讀 910·2019-08-29 11:07
閱讀 3228·2019-08-27 10:53
閱讀 1762·2019-08-26 13:43
閱讀 1004·2019-08-26 10:22
閱讀 1307·2019-08-23 18:06