實(shí)時(shí)計(jì)算在點(diǎn)評(píng)的使用場(chǎng)景

類別一：Dashboard畜疾、實(shí)時(shí)DAU、新激活用戶數(shù)、實(shí)時(shí)交易額等

???Dashboard類：北斗(報(bào)表平臺(tái))舅柜、微信(公眾號(hào))和云圖(流量分析)等

???實(shí)時(shí)DAU：包括主APP(Android/iPhone/iPad)、團(tuán)APP躲惰、周邊快查致份、PC、M站

???新激活用戶數(shù)：主APP

???實(shí)時(shí)交易額：閃惠/團(tuán)購(gòu)交易額

以報(bào)表平臺(tái)為例础拨，下圖是一張APP UV的實(shí)時(shí)曲線圖氮块，它以分鐘級(jí)別粒度展現(xiàn)了 實(shí)時(shí)的DAU數(shù)據(jù)和曲線绍载。

從圖中可以看見一個(gè)尖點(diǎn)，這個(gè)尖點(diǎn)就是當(dāng)天push過后帶來的用戶滔蝉，這樣可以看到實(shí)時(shí)的運(yùn)營(yíng)效率击儡。

類別二：搜索、推薦蝠引、安全等

以搜索為例：用戶在點(diǎn)評(píng)的每一步有價(jià)值的操作(包括：搜索阳谍、點(diǎn)擊、瀏覽螃概、購(gòu)買矫夯、收藏等)，都將實(shí)時(shí)吊洼、智能地影響搜索結(jié)果排序训貌，從而顯著提升用戶搜索體驗(yàn)、搜索轉(zhuǎn)化率冒窍。

某用戶 搜索“ 火鍋 ”递沪，當(dāng)他 在搜索結(jié)果頁(yè) 點(diǎn)擊了“ 重慶高老九火鍋 ”后， 再次刷新搜索結(jié)果列表時(shí)综液，該商戶的排序就會(huì)提升到頂部 款慨。

再結(jié)合其他的一些實(shí)時(shí)反饋的個(gè)性化推薦策略，最終使團(tuán)購(gòu)的交易額有了明顯的增加意乓，轉(zhuǎn)化率提升了2個(gè)多點(diǎn)樱调。

實(shí)時(shí)計(jì)算在業(yè)界的使用場(chǎng)景

場(chǎng)景1：阿里JStorm

???雙11實(shí)時(shí)交易數(shù)據(jù)

場(chǎng)景2：360Storm

???搶票軟件驗(yàn)證碼自動(dòng)識(shí)別：大家用360瀏覽器在12306上買票的時(shí)候，驗(yàn)證碼自動(dòng)識(shí)別是在Storm上計(jì)算完成的届良。

???網(wǎng)盤圖片縮略圖生成：360網(wǎng)盤的縮略圖也是實(shí)時(shí)生成出來的笆凌，這樣可以節(jié)約大量的文件數(shù)量和存儲(chǔ)空間。

???實(shí)時(shí)入侵檢測(cè)

???搜索熱詞推薦

場(chǎng)景3：騰訊TDProcess

分布式K/V存儲(chǔ)引擎TDEngine和支持?jǐn)?shù)據(jù)流計(jì)算的TDProcess士葫，TDProcess是基于Storm的計(jì)算引擎乞而，提供了通用的計(jì)算模型，如Sum慢显、Count爪模、PV/UV計(jì)算和TopK統(tǒng)計(jì)等。

場(chǎng)景4：京東Samza

整個(gè)業(yè)務(wù)主要應(yīng)用訂單處理荚藻，實(shí)時(shí)分析統(tǒng)計(jì)出待定區(qū)域中訂單各個(gè)狀態(tài)的量：待定位屋灌、待派工、待揀貨应狱、待發(fā)貨共郭、待配送、待妥投等。

點(diǎn)評(píng)如何構(gòu)建實(shí)時(shí)計(jì)算平臺(tái)

點(diǎn)評(píng)的實(shí)時(shí)計(jì)算平臺(tái)是一個(gè)端到端的方案除嘹，從下面的平臺(tái)架構(gòu)圖写半，可以看出整體架構(gòu)是一個(gè)比較長(zhǎng)的過程，包括了數(shù)據(jù)源尉咕、數(shù)據(jù)的傳輸通道叠蝇、計(jì)算、存儲(chǔ)和對(duì)外服務(wù)等年缎。

實(shí)時(shí)計(jì)算平臺(tái)首先解決的問題是悔捶，數(shù)據(jù)怎么獲取，如何拿到那些數(shù)據(jù)』蘅睿現(xiàn)在做到了幾乎所有點(diǎn)評(píng)線上產(chǎn)生的數(shù)據(jù)都可以毫秒級(jí)拿到炎功，封裝對(duì)應(yīng)的數(shù)據(jù)輸入源Spout。

通過Blackhole支持日志類實(shí)時(shí)獲取缓溅，包括打點(diǎn)日志、業(yè)務(wù)Log赁温、Nginx日志等坛怪。 整合Puma Client第一時(shí)間獲取數(shù)據(jù)庫(kù)數(shù)據(jù)變更。整合Swallow獲取應(yīng)用消息股囊。Blackhole是團(tuán)隊(duì)開發(fā)的類Kafka系統(tǒng)袜匿，主要目標(biāo)是批量從業(yè)務(wù)方拉取日志時(shí)做到數(shù)據(jù)的完整性和一致性，然后也提供了實(shí)時(shí)的消費(fèi)能力稚疹。Puma是以MySQL binlog為基礎(chǔ)開發(fā)的居灯，這樣可以實(shí)時(shí)拿到數(shù)據(jù)庫(kù)的update、delete内狗、insert操作怪嫌。?

Swallow是點(diǎn)評(píng)的MQ系統(tǒng)。通過整合各種傳輸通道柳沙，并且封裝相應(yīng)的Spout岩灭，做業(yè)務(wù)開發(fā)的同學(xué)就完全不用關(guān)心數(shù)據(jù)怎樣可靠獲取，只需要寫自己的業(yè)務(wù)邏輯就可以了赂鲤。解決了數(shù)據(jù)和傳輸問題后噪径，計(jì)算過程則在Storm中完成。

如果在Storm計(jì)算過程中或計(jì)算出結(jié)果后数初，需要與外部存儲(chǔ)系統(tǒng)交互找爱，也提供了一個(gè)data-service服務(wù) ，通過點(diǎn)評(píng)的RPC框架提供接口泡孩，用戶不用關(guān)心實(shí)際Redis/HBase這些系統(tǒng)的細(xì)節(jié)和部署情況车摄， 以及這個(gè)數(shù)據(jù)到底是在Redis還是HBase中的，可以根據(jù)SLA來做自動(dòng)切換;

同時(shí)計(jì)算的結(jié)果也是通過data-service服務(wù)，再反饋到線上系統(tǒng)练般。就拿剛剛搜索結(jié)果的例子矗漾，搜索業(yè)務(wù)在用戶再次搜索的時(shí)候會(huì)根據(jù)userId請(qǐng)求一次data-service，然后拿到這個(gè)用戶的最近瀏覽記錄薄料，并重新排序結(jié)果敞贡，返回給用戶摄职。

這樣的好處就是實(shí)時(shí)計(jì)算業(yè)務(wù)和線上其他業(yè)務(wù)完全解耦，實(shí)時(shí)計(jì)算這邊出現(xiàn)問題蛔垢，不會(huì)導(dǎo)致線上業(yè)務(wù)出現(xiàn)問題。

Storm基礎(chǔ)知識(shí)簡(jiǎn)單介紹

Apache Storm( http://storm.apache.org/)是由Twitter開源的分布式實(shí)時(shí)計(jì)算系統(tǒng)鹏漆。Storm可以非常容易创泄、可靠地處理無限的數(shù)據(jù)流。對(duì)比Hadoop的批處理饭聚，Storm是個(gè)實(shí)時(shí)的、分布式以及具備高容錯(cuò)的計(jì)算系統(tǒng)秒梳。Storm可以使用何編程語言進(jìn)行開發(fā)。

Storm的集群表面上看和Hadoop的集群非常像箕速，但是在Hadoop上面運(yùn)行的是MapReduce的Job酪碘，而在Storm上面運(yùn)行的是Topology。

Storm和Hadoop一個(gè)非常關(guān)鍵的區(qū)別是Hadoop的MapReduce Job最終會(huì)結(jié)束弧满，而Storm的Topology會(huì)一直運(yùn)行(除非顯式地殺掉)婆跑。

Storm基本概念：

Nimbus和Supervisor之間的通訊是依靠ZooKeeper來完成，并且Nimbus進(jìn)程和Supervisor都是快速失敗(fail-fast)和無狀態(tài)的庭呜』可以用kill-9來殺死Nimbus和Supervisor進(jìn)程，然后再重啟它們募谎，它們可以繼續(xù)工作扶关。

在Storm中，Spout是Topology中產(chǎn)生源數(shù)據(jù)流的組件数冬。通常Spout獲取從Kafka节槐、MQ等的數(shù)據(jù)搀庶，然后調(diào)用nextTuple函數(shù)，發(fā)射數(shù)據(jù)出去供Bolt消費(fèi)铜异。

圖中的Spout就發(fā)射出去了兩條數(shù)據(jù)流哥倔。而Bolt是在Topology中接受Spout的數(shù)據(jù)，然后執(zhí)行處理的組件揍庄。Bolt在接收到消息后會(huì)調(diào)用execute函數(shù)咆蒿，用戶可以在其中執(zhí)行自己想要的操作。

為什么用Storm呢蚂子，因?yàn)镾torm有它的優(yōu)點(diǎn)：

易用性

只要遵守Topology沃测，Spout，Bolt的編程規(guī)范即可開發(fā)出一個(gè)擴(kuò)展性極好的應(yīng)用食茎，像底層RPC蒂破，Worker之間冗余，數(shù)據(jù)分流之類的操作别渔，開發(fā)者完全不用考慮。

擴(kuò)展性

當(dāng)某一級(jí)處理單元速度不夠時(shí)挟秤，直接配置一下并發(fā)數(shù)，即可線性擴(kuò)展性能截珍。

健壯性

當(dāng)Worker失效或機(jī)器出現(xiàn)故障時(shí)岗喉， 自動(dòng)分配新的Worker替換失效Worker钱床。

準(zhǔn)確性

采用Acker機(jī)制，保證數(shù)據(jù)不丟失滥壕。采用事務(wù)機(jī)制胁孙，保證數(shù)據(jù)準(zhǔn)確性涮较。剛剛介紹了一些Storm的基礎(chǔ)概念和特性候齿，再用一張比較完整的圖來回顧一下整個(gè)Storm的體系架構(gòu)：

Storm提交一個(gè)作業(yè)的時(shí)候毛肋，是通過Thrift的Client執(zhí)行相應(yīng)的命令來完成润匙。Nimbus針對(duì)該Topology建立本地的目錄孕讳，Nimbus中的調(diào)度器根據(jù)Topology的配置計(jì)算Task厂财，并把Task分配到不同的Worker上璃饱，調(diào)度的結(jié)果寫入Zookeeper中荚恶。

Zookeeper上建立assignments節(jié)點(diǎn)谒撼，存儲(chǔ)Task和Supervisor中Worker的對(duì)應(yīng)關(guān)系廓潜。在Zookeeper上創(chuàng)建workerbeats節(jié)點(diǎn)來監(jiān)控Worker的心跳辩蛋。Supervisor去Zookeeper上獲取分配的Tasks信息，啟動(dòng)一個(gè)或者多個(gè)Worker來執(zhí)行味滞。

每個(gè)Worker上運(yùn)行多個(gè)Task，Task由Executor來具體執(zhí)行爽醋。Worker根據(jù)Topology信息初始化建立Task之間的連接蚂四，相同Worker內(nèi)的Task通過DisrupterQueue來通信遂赠，不同Worker間默認(rèn)采用Netty來通信跷睦，然后整個(gè)Topology就運(yùn)行起來了抑诸。

如何保證業(yè)務(wù)運(yùn)行可靠性

首先Storm自身有很多容錯(cuò)機(jī)制，也加了很多監(jiān)控信息梗夸，方便業(yè)務(wù)同學(xué)監(jiān)控自己的業(yè)務(wù)狀態(tài)。

在Storm上称簿，遇到的一個(gè)很基本的問題就是，各個(gè)業(yè)務(wù)是運(yùn)行的Worker會(huì)跑在同一臺(tái)物理機(jī)上该酗。曾經(jīng)有位同學(xué)就在自己的Worker中起了200多個(gè)線程來處理json呜魄，結(jié)果就是這臺(tái)機(jī)器的CPU都被他的Worker吃光了爵嗅，其他的業(yè)務(wù)也跟著倒霉睹晒。

因此也使用CGroup做了每個(gè)Worker的資源隔離伪很，主要限制了CPU和Memory的使用锉试。相對(duì)而言JStorm在很多方面要完善一些呆盖，JStorm自己就帶資源隔離宙项。對(duì)應(yīng)監(jiān)控來說杉允，基本的主機(jī)維度的監(jiān)控在ganglia上可以看見叔磷，比如現(xiàn)在集群的運(yùn)行狀況改基。下圖是現(xiàn)在此時(shí)的集群的網(wǎng)絡(luò)和負(fù)載：

這些信息并不能保證業(yè)務(wù)就OK躁染，因此將Storm上的很多監(jiān)控信息和點(diǎn)評(píng)的開源監(jiān)控系統(tǒng)Cat集成在了一起我衬，從Cat上可以看見更多的業(yè)務(wù)運(yùn)行狀態(tài)信息挠羔。

比如在Cat中我可以看見整個(gè)集群的TPS，現(xiàn)在已經(jīng)從30多萬降下來了范舀。 然后我可以設(shè)置若干的報(bào)警規(guī)則， 如：連續(xù)N分鐘降低了50%可以報(bào)警端仰。然后也監(jiān)控了各個(gè)業(yè)務(wù)Topology的TPS、Spout輸入汽久、Storm的可用Slot等的變化臀稚。

這個(gè)圖就是某個(gè)業(yè)務(wù)的TPS信息吧寺， 如果TPS同比或者環(huán)比出現(xiàn)問題，也可以報(bào)警給業(yè)務(wù)方赖条。

Storm使用經(jīng)驗(yàn)分享

1.使用組件的并行度代替線程池

Storm自身是一個(gè)分布式、多線程的框架仿贬，對(duì)每個(gè)Spout和Bolt诅蝶，都可以設(shè)置其并發(fā)度;它也支持通過rebalance命令來動(dòng)態(tài)調(diào)整并發(fā)度，把負(fù)載分?jǐn)偟蕉鄠€(gè)Worker上募壕。

如果自己在組件內(nèi)部采用線程池做一些計(jì)算密集型的任務(wù)，比如JSON解析语盈，有可能使得某些組件的資源消耗特別高舱馅，其他組件又很低，導(dǎo)致Worker之間資源消耗不均衡刀荒，這種情況在組件并行度比較低的時(shí)候更明顯代嗤。

比如某個(gè)Bolt設(shè)置了1個(gè)并行度棘钞，但在Bolt中又啟動(dòng)了線程池，這樣導(dǎo)致的一種后果就是干毅，集群中分配了這個(gè)Bolt的Worker進(jìn)程可能會(huì)把機(jī)器的資源都給消耗光了，影響到其他Topology在這臺(tái)機(jī)器上的任務(wù)的運(yùn)行。如果真有計(jì)算密集型的任務(wù)，可以把組件的并發(fā)度設(shè)大，Worker的數(shù)量也相應(yīng)提高，讓計(jì)算分配到多個(gè)節(jié)點(diǎn)上痕寓。

為了避免某個(gè)Topology的某些組件把整個(gè)機(jī)器的資源都消耗光的情況礼仗，除了不在組件內(nèi)部啟動(dòng)線程池來做計(jì)算以外沪羔，也可以通過CGroup控制每個(gè)Worker的資源使用量篓吁。

2.不要用DRPC批量處理大數(shù)據(jù)

RPC提供了應(yīng)用程序和StormTopology之間交互的接口翼雀，可供其他應(yīng)用直接調(diào)用狈邑，使用Storm的并發(fā)性來處理數(shù)據(jù)蘸嘶，然后將結(jié)果返回給調(diào)用的客戶端。這種方式在數(shù)據(jù)量不大的情況下，通常不會(huì)有問題弥锄，而當(dāng)需要處理批量大數(shù)據(jù)的時(shí)候，問題就比較明顯了累盗。

(1)處理數(shù)據(jù)的Topology在超時(shí)之前可能無法返回計(jì)算的結(jié)果啊终。

(2)批量處理數(shù)據(jù)已卸，可能使得集群的負(fù)載短暫偏高惑申，處理完畢后绩脆，又降低回來主守，負(fù)載均衡性差。

批量處理大數(shù)據(jù)不是Storm設(shè)計(jì)的初衷程储，Storm考慮的 是時(shí)效性和批量之間的均衡帚呼，更多地看中前者。需要準(zhǔn)實(shí)時(shí)地處理大數(shù)據(jù)量，可以考慮Spark Stream等批量框架。

3.不要在Spout中處理耗時(shí)的操作

Spout中nextTuple方法會(huì)發(fā)射數(shù)據(jù)流，在啟用Ack的情況下酝润，fail方法和ack方法會(huì)被觸發(fā)。

需要明確一點(diǎn)糊昙，在Storm中Spout是單線程(JStorm的Spout分了3個(gè)線程辛掠，分別執(zhí)行nextTuple方法、fail方法和ack方法)释牺。如果nextTuple方法非常耗時(shí)萝衩，某個(gè)消息被成功執(zhí)行完畢后，Acker會(huì)給Spout發(fā)送消息船侧，Spout若無法及時(shí)消費(fèi)欠气，可能造成ACK消息超時(shí)后被丟棄，然后Spout反而認(rèn)為這個(gè)消息執(zhí)行失敗了镜撩，造成邏輯錯(cuò)誤预柒。反之若fail方法或者ack方法的操作耗時(shí)較多队塘，則會(huì)影響Spout發(fā)射數(shù)據(jù)的量，造成Topology吞吐量降低宜鸯。

4.注意fieldsGrouping的數(shù)據(jù)均衡性

fieldsGrouping是根據(jù)一個(gè)或者多個(gè)Field對(duì)數(shù)據(jù)進(jìn)行分組憔古，不同的目標(biāo)Task收到不同的數(shù)據(jù)，而同一個(gè)Task收到的數(shù)據(jù)會(huì)相同淋袖。

假設(shè)某個(gè)Bolt根據(jù)用戶ID對(duì)數(shù)據(jù)進(jìn)行fieldsGrouping鸿市，如果某一些用戶的數(shù)據(jù)特別多，而另外一些用戶的數(shù)據(jù)又比較少即碗，那么就可能使得下一級(jí)處理Bolt收到的數(shù)據(jù)不均衡焰情，整個(gè)處理的性能就會(huì)受制于某些數(shù)據(jù)量大的節(jié)點(diǎn)“粒可以加入更多的分組條件或者更換分組策略内舟，使得數(shù)據(jù)具有均衡性。

5.優(yōu)先使用localOrShuffleGrouping

localOrShuffleGrouping是指如果目標(biāo)Bolt中的一個(gè)或者多個(gè)Task和當(dāng)前產(chǎn)生數(shù)據(jù)的Task在同一個(gè)Worker進(jìn)程里面初橘，那么就走內(nèi)部的線程間通信验游，將Tuple直接發(fā)給在當(dāng)前Worker進(jìn)程的目的Task。否則保檐，同shuffleGrouping耕蝉。

localOrShuffleGrouping的數(shù)據(jù)傳輸性能優(yōu)于shuffleGrouping，因?yàn)樵赪orker內(nèi)部傳輸夜只，只需要通過Disruptor隊(duì)列就可以完成垒在，沒有網(wǎng)絡(luò)開銷和序列化開銷。因此在數(shù)據(jù)處理的復(fù)雜度不高盐肃，而網(wǎng)絡(luò)開銷和序列化開銷占主要地位的情況下爪膊，可以優(yōu)先使用localOrShuffleGrouping來代替shuffleGrouping。

6.設(shè)置合理的MaxSpoutPending值

在啟用Ack的情況下砸王，Spout中有個(gè)RotatingMap用來保存Spout已經(jīng)發(fā)送出去推盛，但還沒有等到Ack結(jié)果的消息。RotatingMap的最大個(gè)數(shù)是有限制的谦铃，為p*num-tasks耘成。其中p是topology.max.spout.pending值，也就是MaxSpoutPending(也可以由TopologyBuilder在setSpout通過setMaxSpoutPending方法來設(shè)定)驹闰，num-tasks是Spout的Task數(shù)瘪菌。如果不設(shè)置MaxSpoutPending的大小或者設(shè)置得太大，可能消耗掉過多的內(nèi)存導(dǎo)致內(nèi)存溢出嘹朗，設(shè)置太小則會(huì)影響Spout發(fā)射Tuple的速度师妙。

7.設(shè)置合理的Worker數(shù)

Worker數(shù)越多，性能越好?先看一張Worker數(shù)量和吞吐量對(duì)比的曲線(來源于JStorm文檔：

https://github.com/alibaba/jstorm/tree/master/docs/ 0.9.4.1jstorm性能測(cè)試.docx)屹培。

從圖可以看出默穴，在12個(gè)Worker的情況下怔檩，吞吐量最大，整體性能最優(yōu)蓄诽。這是由于一方面薛训，每新增加一個(gè)Worker進(jìn)程，都會(huì)將一些原本線程間的內(nèi)存通信變?yōu)檫M(jìn)程間的網(wǎng)絡(luò)通信仑氛，這些進(jìn)程間的網(wǎng)絡(luò)通信還需要進(jìn)行序列化與反序列化操作乙埃，這些降低了吞吐率。

另一方面锯岖，每新增加一個(gè)Worker進(jìn)程介袜，都會(huì)額外地增加多個(gè)線程(Netty發(fā)送和接收線程熊镣、心跳線程溅固、SystemBolt線程以及其他系統(tǒng)組件對(duì)應(yīng)的線程等)，這些線程切換消耗了不少CPU夭咬，sys系統(tǒng)CPU消耗占比增加趋箩，在CPU總使用率受限的情況下，降低了業(yè)務(wù)線程的使用效率加派。

8.平衡吞吐量和時(shí)效性

Storm的數(shù)據(jù)傳輸默認(rèn)使用Netty叫确。在數(shù)據(jù)傳輸性能方面，有如下的參數(shù)可以調(diào)整：

storm.messaging.netty.server_worker_threads和storm.messaging.netty.client_worker_threads分別為接收消息線程和發(fā)送消息線程的數(shù)量芍锦。

netty.transfer.batch.size是指每次 Netty Client向 Netty Server發(fā)送的數(shù)據(jù)的大小竹勉，如果需要發(fā)送的Tuple消息大于netty.transfer.batch.size，則Tuple消息會(huì)按照netty.transfer.batch.size進(jìn)行切分娄琉，然后多次發(fā)送次乓。

storm.messaging.netty.buffer_size為每次批量發(fā)送的Tuple序列化之后的TaskMessage消息的大storm.messaging.netty.flush.check.interval.ms表示當(dāng)有TaskMessage需要發(fā)送的時(shí)候， Netty Client檢查可以發(fā)送數(shù)據(jù)的頻率孽水。

降低storm.messaging.netty.flush.check.interval.ms的值票腰，可以提高時(shí)效性。增加netty.transfer.batch.size和storm.messaging.netty.buffer_size的值女气，可以提升網(wǎng)絡(luò)傳輸?shù)耐峦塘啃游浚沟镁W(wǎng)絡(luò)的有效載荷提升(減少TCP包的數(shù)量，并且TCP包中的有效數(shù)據(jù)量增加)炼鞠，通常時(shí)效性就會(huì)降低一些缘滥。因此需要根據(jù)自身的業(yè)務(wù)情況，合理在吞吐量和時(shí)效性直接的平衡谒主。

除了這些參數(shù)朝扼，怎么找到Storm中性能的瓶頸，可以通過如下的一些途徑來進(jìn)行：

在Storm的UI中霎肯，對(duì)每個(gè)Topology都提供了相應(yīng)的統(tǒng)計(jì)信息擎颖，其中有3個(gè)參數(shù)對(duì)性能來說參考意義比較明顯榛斯，包括Execute latency、Process latency和Capacity肠仪。

分別看一下這3個(gè)參數(shù)的含義和作用肖抱。

(1)Execute latency：消息的平均處理時(shí)間，單位為毫秒异旧。

(2)Process latency：消息從收到到被ack掉所花的時(shí)間意述，單位為毫秒。如果沒有啟用Acker機(jī)制吮蛹，那么Process latency的值為0荤崇。

(3)Capacity：計(jì)算公式為Capacity = Bolt或者Executor調(diào)用execute方法處理的消息數(shù)量 * 消息平均執(zhí)行時(shí)間 /時(shí)間區(qū)間。這個(gè)值越接近1潮针，說明Bolt或者Executor基本一直在調(diào)用execute方法术荤，因此并行度不夠，需要擴(kuò)展這個(gè)組件的Executor數(shù)量每篷。為了在Storm中達(dá)到高性能瓣戚，在設(shè)計(jì)和開發(fā)Topology的時(shí)候，需要注意以下原則焦读。

(1)模塊和模塊之間解耦子库，模塊之間的層次清晰，每個(gè)模塊可以獨(dú)立擴(kuò)展矗晃，并且符合流水線的原則仑嗅。

(2)無狀態(tài)設(shè)計(jì)，無鎖設(shè)計(jì)张症，水平擴(kuò)展支持仓技。

(3)為了達(dá)到高的吞吐量，延遲會(huì)加大;為了低延遲俗他，吞吐量可能降低脖捻，需要在二者之間平衡。

(4)性能的瓶頸永遠(yuǎn)在熱點(diǎn)兆衅，解決熱點(diǎn)問題郭变。

(5)優(yōu)化的前提是測(cè)量，而不是主觀臆測(cè)涯保。收集相關(guān)數(shù)據(jù)诉濒，再動(dòng)手，事半功倍夕春。

關(guān)于計(jì)算框架的后續(xù)問題

目前Hadoop/Hive專注于離線分析業(yè)務(wù)未荒，每天點(diǎn)評(píng)有1.6萬個(gè)離線分析任務(wù)。Storm專注于實(shí)時(shí)業(yè)務(wù)及志，實(shí)時(shí)每天會(huì)處理100億+條的數(shù)據(jù)片排。

在這兩個(gè)框架目前有很大的gap寨腔，一個(gè)是天級(jí)別，一個(gè)是秒級(jí)別率寡，然后有大量的業(yè)務(wù)是準(zhǔn)實(shí)時(shí)的迫卢，比如分鐘級(jí)別。因此會(huì)使用Spark來做中間的補(bǔ)充冶共。

Spark Streaming + Spark SQL也能夠降低很大的開發(fā)難度乾蛤。相對(duì)而言，目前Storm的學(xué)習(xí)和開發(fā)成本還是偏高捅僵。要做一個(gè)10萬+TPS的業(yè)務(wù)在Storm上穩(wěn)定運(yùn)行家卖，需要對(duì)Storm了解比較深入才能做到，不然會(huì)發(fā)現(xiàn)有這樣或者那樣的問題庙楚。