一、背景
有一些時候,多個團隊需要共同完成一個任務,比如,A團隊將Hadoop集群計算的結果交給B團隊繼續(xù)計算,B完成了自己任務再交給C團隊繼續(xù)做。這就有點像業(yè)務系統(tǒng)的工作流一樣,一環(huán)一環(huán)地傳下
去,直到最后一部分完成。在業(yè)務系統(tǒng)中,我們經常會用SOA的架構來解決這種問題,每個團隊在ESB(企業(yè)服務股總線)服務器上部署自己的服務,然后通過消息中間件完成調度任務。對亍分步式的多個
Hadoop集群系統(tǒng)的協(xié)作,同樣可以用這種架構來做只要把消息中間件引擎換成支持分步式的消息中間件的引擎就行了。
本文樓主將使用zookeeper做為分步式消息中間件構造一個大型超市的部分數(shù)據(jù)計算模型來完成各個區(qū)域利潤計算的業(yè)務需求。
由于采購和銷售分別是由不同廠商進行的軟件開發(fā)和維護,而且業(yè)務往來也在不同的城市和地區(qū)。 所以在每月底結算時,工作量都特別大。 比如,計算利潤表: 當月利潤 = 當月銷售金額 - 當月采購
額 - 當月其他支出(樓主只是粗略計算)。如果采購系統(tǒng)是單獨的系統(tǒng),銷售是另外單獨的系統(tǒng),及以其他幾十個大大小小的系統(tǒng), 如何能讓多個系統(tǒng),配合起來完成該需求?
二、系統(tǒng)構思
樓主基于zookeeper來構建一個分步式隊列的應用,來解決上面的功能需求。排除了ESB的部分,只保留zookeeper進行實現(xiàn)。
采購數(shù)據(jù):海量數(shù)據(jù),基于Hadoop存儲和分析(樓主環(huán)境有限,只使用了很少的數(shù)據(jù))
銷售數(shù)據(jù):海量數(shù)據(jù),基于Hadoop存儲和分析(樓主環(huán)境有限,只使用了很少的數(shù)據(jù))
其他費用支出:為少量數(shù)據(jù),基于文件或數(shù)據(jù)庫存儲和分析
我們設計一個同步隊列,這個隊列有3個條件節(jié)點,分別對應采購(purchase),銷售 (sell),其他費用(other)3個部分。當3個節(jié)點都被創(chuàng)建后,程序會自動觸發(fā)計算利潤, 幵創(chuàng)建利潤(profit)節(jié)點。上面3個節(jié)點的創(chuàng)建,無順序要求。每個節(jié)點只能被創(chuàng)建一次 。
Hadoop mapreduce1,Hadoop mapreduce2 是2個獨立的Hadoop集群應用。 Java App 是2個獨立的Java應用 。ZooKeeper集群的有3個節(jié)點 。
/queue,是znode的隊列目錄,假設隊列長度為3
/queue/purchase,是znode隊列中,1號排對者,由Hadoop mapreduce1提交,用于統(tǒng)計采購金額
/queue/sell,是znode隊列中,2號排對者,由Hadoop mapreduce2提交,用于統(tǒng)計銷售金額
/queue/other,是znode隊列中,3號排對者,由Java App提交,用于統(tǒng)計其他費用支出金額
/queue/profit,當znode隊列中滿了,觸發(fā)創(chuàng)建利潤節(jié)點。
當/qeueu/profit被創(chuàng)建后,利潤java app被啟動,所有zookeeper的連接通知同步程序(紅色線),隊列已完成,所有程序結束。
三、環(huán)境準備
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉無線電——不安全的藍牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現(xiàn)JSON轉Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應用分析 2017-07-26
- 集合結合數(shù)據(jù)結構來看看(二) 2017-07-26