【摘要】：傳統(tǒng)的批處理系統(tǒng)和流處理系統(tǒng)主要針對(duì)大規(guī)模數(shù)據(jù)實(shí)時(shí)處理的需求,系統(tǒng)的開(kāi)發(fā)和部署復(fù)雜,數(shù)據(jù)處理應(yīng)用的重構(gòu)和使用困難。隨著應(yīng)用性能管理的發(fā)展,迫切需要一種輕量級(jí)的,具備良好重構(gòu)能力的流處理引擎,以應(yīng)對(duì)應(yīng)用性能管理所需的多源結(jié)構(gòu)化日志數(shù)據(jù)的流式處理需求。論文針對(duì)應(yīng)用性能管理的數(shù)據(jù)處理需求,分析了現(xiàn)有流處理系統(tǒng)在集群節(jié)點(diǎn)動(dòng)態(tài)管理、消息持久化、消息恢復(fù)、任務(wù)并發(fā)執(zhí)行等方面存在的問(wèn)題,提出了一種動(dòng)態(tài)自適應(yīng)的流式數(shù)據(jù)處理方法。該方法通過(guò)引入基于ZeroMQ的集群對(duì)等節(jié)點(diǎn)廣播策略和基于Redis的AOF持久化特性的時(shí)間窗口算法,解決了 Kafka這類傳統(tǒng)流式數(shù)據(jù)處理引擎,在應(yīng)對(duì)應(yīng)用性能管理數(shù)據(jù)分析系統(tǒng)時(shí)容易出現(xiàn)的集群節(jié)點(diǎn)同步不及時(shí)、消息恢復(fù)慢、集群配置過(guò)于復(fù)雜的問(wèn)題,提高了節(jié)點(diǎn)數(shù)據(jù)處理的可靠性和集群管理的高效性。論文首先分析了應(yīng)用性能管理系統(tǒng)的集群節(jié)點(diǎn)管理需求和節(jié)點(diǎn)故障恢復(fù)需求,設(shè)計(jì)了一個(gè)包含分布式處理引擎、流處理節(jié)點(diǎn)代理的動(dòng)態(tài)自適應(yīng)流式數(shù)據(jù)處理引擎。分布式處理引擎通過(guò)封裝ZeroMQ集群內(nèi)對(duì)等節(jié)點(diǎn)廣播來(lái)實(shí)現(xiàn)集群節(jié)點(diǎn)的動(dòng)態(tài)發(fā)現(xiàn)和管理,及節(jié)點(diǎn)間的數(shù)據(jù)消息傳遞。流處理節(jié)點(diǎn)代理則通過(guò)“生產(chǎn)者-消費(fèi)者”模式封裝數(shù)據(jù)的獲取和分發(fā),從而解耦流數(shù)據(jù)處理節(jié)點(diǎn),完成數(shù)據(jù)處理的動(dòng)態(tài)管理。流處理節(jié)點(diǎn)內(nèi)則通過(guò)時(shí)間窗口算法,處理節(jié)點(diǎn)在故障恢復(fù)過(guò)程中的數(shù)據(jù)自適應(yīng)加載,完成數(shù)據(jù)處理的自適應(yīng)管理。其后,論文對(duì)動(dòng)態(tài)自適應(yīng)流處理引擎的核心功能、開(kāi)發(fā)者接口、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)流程等進(jìn)行了設(shè)計(jì)與實(shí)現(xiàn),向開(kāi)發(fā)者提供了一個(gè)完整的輕量級(jí)數(shù)據(jù)傳輸與處理服務(wù)。論文最后通過(guò)一個(gè)典型應(yīng)用性能管理應(yīng)用對(duì)該引擎進(jìn)行了功能和性能測(cè)試,驗(yàn)證了系統(tǒng)的有效性,并對(duì)輕量級(jí)流式數(shù)據(jù)處理引擎進(jìn)行了總結(jié)和展望。
【學(xué)位授予單位】：北京郵電大學(xué)
【學(xué)位級(jí)別】：碩士
【學(xué)位授予年份】：2018
【分類號(hào)】：TP311.52
【圖文】：

這些分布式協(xié)調(diào)服務(wù)的優(yōu)點(diǎn)是能實(shí)現(xiàn)簡(jiǎn)單的分布式協(xié)調(diào)過(guò)程，能在服務(wù)器進(jìn)逡逑程之間相互協(xié)作；實(shí)現(xiàn)了消息編解碼功能，確保程序運(yùn)行一致；提供了數(shù)據(jù)操作逡逑的原子性。以Ｚｏｏｋｅｅｐｅｒ?yàn)槔郏福�，通用的分布式客戶端－服�?wù)器結(jié)構(gòu)如圖２－１所逡逑示：逡逑邐從節(jié)點(diǎn)邋邐逡逑邐邋＾邐ｆ?zhèn)浞輸?shù)據(jù)庫(kù)＾邐邋心跳廣播邐￥逡逑客戶端１邋—＾邐Ｖ邋ｙ邐丨１逡逑Ｉ逡逑客戶端２邋’邐廣邋＾主節(jié)點(diǎn)｜邐邐邋－邐｜１逡逑￣邐備份數(shù)據(jù)庫(kù)——心跳廣播邋＾——請(qǐng)求處理器邋—逡逑客戶端３邐？逡逑邐邋廣邐從節(jié)點(diǎn)邋邐逡逑客戶端４邐備份數(shù)據(jù)庫(kù)＾邐邋心跳廣播邐」逡逑圖２－１邋ＺｏｏＫｅ�。澹蚍植际娇蚣苠义希冢铮铮耍澹澹穑澹蚣�?jiǎn)?dòng)之后，等待來(lái)自客戶端的連接，客戶端連接到集群中某逡逑一個(gè)節(jié)點(diǎn)，可以是ｌｅａｄｅｒ節(jié)點(diǎn)，也可以是ｆｏｌｌｏｗｅｒ節(jié)點(diǎn)，一旦連接成功，節(jié)點(diǎn)將逡逑向該客戶端發(fā)送確認(rèn)消息，如果客戶端未收到確認(rèn)消息，將嘗試連接另一個(gè)節(jié)點(diǎn)。逡逑６逡逑

２．２．１生產(chǎn)者－消費(fèi)者模式逡逑Ｋａｆｋａ的分布式節(jié)點(diǎn)磁盤上存儲(chǔ)的每一個(gè)Ｔｏｐｉｃ存儲(chǔ)消息以及消息被消費(fèi)的逡逑格式和過(guò)程［１２］如圖２－２：逡逑生產(chǎn)者逡逑寫入逡逑ｙ逡逑Ｉ逡逑Ｉ逡逑０１２３４５６７８９！逡逑Ｉ逡逑Ｉ逡逑Ｉ逡逑邐邐邐邐邐邐邐，」邐１邐邐ｊ逡逑Ｊ邋讀取逡逑消費(fèi)者Ａ邐消費(fèi)者Ｂ逡逑０ｆｆｓｅｔ＝６邐０ｆｆｓｅｔ＝８逡逑圖２－２流引擎生產(chǎn)消費(fèi)模式逡逑流數(shù)據(jù)以生產(chǎn)－消費(fèi)的模式出現(xiàn)，通過(guò)發(fā)布－訂閱機(jī)制來(lái)完成數(shù)據(jù)的生產(chǎn)和消逡逑８逡逑

首先是數(shù)據(jù)存儲(chǔ)形式，采用主題（Ｔｏｐｉｃ）－分區(qū)（Ｐａｒｔｉｔｉｏｎ）模式來(lái)表現(xiàn)流。逡逑下圖顯示了對(duì)這種主題分區(qū)形式的流定義的日志存儲(chǔ)表示，數(shù)據(jù)存儲(chǔ)在磁盤文件逡逑系統(tǒng)中，對(duì)數(shù)據(jù)的訪問(wèn)則通過(guò)圖２－３的形式：逡逑９逡逑

【參考文獻(xiàn)】

相關(guān)期刊論文 前2條

1 唐海東;武延軍;;分布式同步系統(tǒng)Zookeeper的優(yōu)化[J];計(jì)算機(jī)工程;2014年04期

2 李汝光;趙俊;;基于ZooKeeper的分布式緩存的設(shè)計(jì)與實(shí)現(xiàn)[J];綿陽(yáng)師范學(xué)院學(xué)報(bào);2011年11期

本文編號(hào)：2777418