筆試總結(jié)基礎(chǔ)面試題詳解

PAGEPAGE1熟練掌握J(rèn)ava語言中集合、動(dòng) 、IO與NIO等知識(shí) java如果涉及到堆棧，隊(duì)列等操作，應(yīng)該考慮用List，對(duì)于需要快速插入，刪除元素，應(yīng)該使用LinkedList，如果需要快速隨機(jī) ArrayListLinkedListHashMap通過hashcode對(duì)其內(nèi)容進(jìn)行快速查找，而TreeMapHashMapHashMap(intinitialCapacity,floatloadFactor)：以指定初始容量、指定的負(fù)載因子創(chuàng)建一個(gè)HashMap。因?yàn)殡S著map中元素增加導(dǎo)致擴(kuò)容比較消耗資源，因此如果知道大概需要存入多少元素，可以設(shè)定初始容量。以此優(yōu)化hashmap性ConcurrentHashMap（hashtable動(dòng) 定義InvocationHandlertarget（目標(biāo)對(duì)象getInstance（target）使 創(chuàng)建target 對(duì)重寫invokeIO與第式：我從硬盤數(shù)據(jù)，然后程序一直等，數(shù)據(jù)讀完后，繼續(xù)操作。這種方式是最簡單的，叫阻塞IO。第二種方式：我從硬盤數(shù)據(jù)，然后程序繼續(xù)向下執(zhí)行，等數(shù)據(jù)完后，即處理數(shù)據(jù)，也可以執(zhí)行完當(dāng)前操作在數(shù)據(jù)。在一起的JavaIO中，都是阻塞式IO，NIO引入了非阻塞式IO還有一種就是同步IO和異步IO。經(jīng)常說的一個(gè)術(shù)語就是“異步非阻塞”，至于JavaNIO的Selector，在舊的JavaIO系統(tǒng)中，是基于Stream的，即“流”，流式IO。當(dāng)程序從硬盤往內(nèi)存數(shù)據(jù)的時(shí)候，操作系統(tǒng)使用了2個(gè)“小伎倆”來提高性能，那就是預(yù)讀，如果我了第一扇區(qū)的第三磁道的內(nèi)容，那么你很有可前出來，放在內(nèi)存中，即緩存。通過上面可以看到，操作系統(tǒng)是按塊Block從硬盤拿數(shù)據(jù)，就如同一個(gè)大臉盆，一下子就放入了一盆水。但是，當(dāng)Java使用的時(shí)候，舊的IO確實(shí)基于流Stream原來的I/O庫(在java.io.*中)與NIO最重要的區(qū)別是式。正如前面提到的，原來的I/O以流的方式處理數(shù)據(jù)，而NIO以塊的方式通道是對(duì)原I/O包中的流的模擬。到任何目的地(或來自任何地方)的所有數(shù)據(jù)都必須通過一個(gè)Channel對(duì)象。一個(gè)Buffer實(shí)質(zhì)上是一個(gè)容器對(duì)象。發(fā)送給一個(gè)通道的所有對(duì)象都必須首先放到緩沖區(qū)中；同樣地，從通道中的任何redisredisRedis是一個(gè)開源的key-value系統(tǒng)，它通常被稱為一個(gè)數(shù)據(jù)結(jié)構(gòu)服務(wù)器，因?yàn)閗eys可以包含strings，hashes，lists，sets和sortedsets。當(dāng)需要除key/value之外的數(shù)據(jù)類型支持時(shí)，使用Redis更合適。當(dāng)?shù)臄?shù)據(jù)不能被剔除時(shí)，使用Redis更合適。（相比memcached）構(gòu)建消息系統(tǒng) 的就是使用消息隊(duì)列。通過消息隊(duì)列，將短時(shí)間高并發(fā)產(chǎn)生的事務(wù)消息在消息隊(duì)列中，從而削平 如果要實(shí)現(xiàn)任務(wù)隊(duì)列，只需要讓生產(chǎn)者將任務(wù)使用LPUSH某個(gè)鍵中，另一邊讓消費(fèi)者不斷地使用RPOP命令從該鍵中取出任務(wù)即可。一個(gè)sentinel實(shí)例可以監(jiān)視多個(gè)主服務(wù)器（及其下的從服務(wù)器），多個(gè)sentinel服務(wù)器共同監(jiān)視一個(gè)主服務(wù)器（及其下的從服務(wù)器）sentinel （ip one（取消其作為從服務(wù)器Sentinelmonitormymaster127.0.0.163792mymaster，他的ip地址為127.0.0.1端為6397，而確認(rèn)這個(gè)主服務(wù)器已下Sentinel 分片（shard）這項(xiàng)技術(shù)的原理是將整個(gè)數(shù)據(jù)庫分為多個(gè)部分，使用不同的服務(wù)器來不同的部分，并負(fù)責(zé)處理相應(yīng)部分令請求（包括讀請求和寫-ketama：hash，主要用于在實(shí)現(xiàn)緩存服務(wù)時(shí)，防止某個(gè)服務(wù)器下線而造Twem允許用戶通過設(shè)置配置選項(xiàng)，讓twem在某個(gè)服務(wù)器下線時(shí)，自動(dòng)地將原本由下線服務(wù)器負(fù)責(zé)處理的數(shù)據(jù)庫鍵轉(zhuǎn)交給池中的其他服務(wù)器來處理；并且用戶還可以設(shè)置一個(gè)重試時(shí)間，讓twem在一段時(shí)間之后，的話，twem就會(huì)重新將數(shù)據(jù)庫鍵交給該服務(wù)器來處理分布式的Redis群的性能瓶頸，它具有、高可用和分片特性集群的行為和我們之前介紹的單機(jī)特性的行為是完全一樣Redis集群的主節(jié)點(diǎn)內(nèi)置了類似RedisSentinel16384個(gè)槽slot（分片創(chuàng)建集群的操作可以通過使用位于Redis安裝文件夾內(nèi)的redis-trib.rb程序來完成，這是一個(gè)使用Ruby編寫的Redis集群管理程序集群中的主節(jié)點(diǎn)負(fù)責(zé)處理槽（數(shù)據(jù)），而從節(jié)點(diǎn)則是主節(jié)點(diǎn)的主節(jié)點(diǎn)只會(huì)執(zhí)行和自己負(fù)責(zé)的槽有關(guān)令，當(dāng)節(jié)點(diǎn)接收到不屬于自己處理的槽令時(shí)，它將會(huì)處理指定槽的節(jié)點(diǎn)的地址返回給客戶端，而客戶端會(huì)向正熟悉linux命令，熟練使用s，部署高可用集服務(wù)器netstat-tnlp,chkconfigiptablesdu-sh/etc/hosts,du-sh(遞歸查詢當(dāng) 下所有文件大小dfhl(磁盤利用率file/etc/hostsrpm-qa,rpm-qlredissudofind/var/log/-typef-mtime+30-execrm-f{}30file/bin/ls系統(tǒng)信息),unamea（yumcleanall,yumupdate,yumlistinstalledcat/proc/cpuinfo,cat/proc/meminfo-m內(nèi)存信息)，uptime，catcutdf1/etc/passwd,cutdf1/etc/groupcrontabl(計(jì)劃任務(wù)),chkconfiglist（系統(tǒng)服務(wù)w（活動(dòng)用戶），idroot（用戶信息），last（登陸日志）tail-f.log,tar-zxvf.gz.tar if[$var1/>$var2]thenecho1elseecho2if[]&&[]||[]forvarinlistdoecho$varifecho$var|egrep-q'^[0-9]+$'thenecho1elseecho2四層：tcp之上的第四層協(xié)議LVSIP,端口，在操作系統(tǒng)內(nèi)核中。熟悉MySQL,Oracle關(guān)系數(shù)據(jù)庫，完成千萬級(jí)sql語句優(yōu)化，搭建mysql千萬級(jí)sql對(duì)查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在where及order涉及的列上建立索引應(yīng)盡量避免在where子句中對(duì)字段進(jìn)行null值判斷，否則將導(dǎo)致引擎放棄應(yīng)盡量避免在where子句中使用!=或<>操作符應(yīng)盡量避免在where子句中使用or來連接條件（unionin和notin也要慎用如果在whereSQL應(yīng)盡量避免在where子句中對(duì)字段進(jìn)行表達(dá)式操作應(yīng)盡量避免在where不要在where會(huì)降低查詢和連接的性能，并會(huì)增加開銷任何地方都不要使用select*fromt，用具體的字段列表代替“*”，不要盡量把所有的列設(shè)置為NOTNULL，如果你要保存NULL，手動(dòng)去設(shè)置果你的數(shù)據(jù)只有你所知的少量的幾個(gè)。最好使用ENUMmysql 最強(qiáng)大的一項(xiàng)功能是實(shí)現(xiàn)“讀寫分離(Read/WriteSplitting)”?；镜脑硎亲屩鲾?shù)據(jù)庫處理事務(wù)性查詢，而從數(shù)據(jù)庫處理SELECT查詢。數(shù)據(jù)庫被用來把事務(wù)性查詢導(dǎo)致的變更同步到集群中的從數(shù)據(jù)庫。當(dāng)然，主服務(wù)主從服務(wù)器上。可以利用數(shù)據(jù)庫的這能，實(shí)現(xiàn)數(shù)據(jù)庫的讀寫分離，從而改利用數(shù)據(jù)庫的讀寫分離，Web（Master），主數(shù)據(jù)庫通過主 （Slave），Web這一方案使得在大量讀操作的Web應(yīng)用可以輕松地?cái)?shù)據(jù)，而主數(shù)據(jù)庫也只MySQL數(shù)據(jù)原理：Masterbinarylog)中（這些記錄叫做二進(jìn)制日志事件，binarylogevents）；Slave將Master的二進(jìn)制日志(binarylogevents)拷貝到它的中繼日志(relaylog)；Slave服務(wù)器中有一個(gè)I/OI/OThread)在不停地Master的二進(jìn)制日志(BinaryLog)是否有更新：如果沒有它會(huì)睡眠等待Master產(chǎn)生新的日志事11件；如果有新的日志(LogEvents)，則會(huì)將其拷貝至Slave服務(wù)器中的中繼日志(RelayLog)。Slave重做中繼日志(RelayLog)中的，將Master上的改變反映到它自己的數(shù)據(jù)庫中。slave服務(wù)器中有一個(gè)SQL線程(SQLThread)從中繼日志事件，并重做其中的從而更新Slave的數(shù)據(jù)，使其與Master中的數(shù)據(jù)一致。只要該線程與I/OOSmysql開啟二進(jìn)制日志log-bin=master-使用二進(jìn)制日志的索引文件log-bin-為服務(wù)器添加唯一的編號(hào)server-HDFShdfs高容錯(cuò)性（副本策略移動(dòng)計(jì)算而非數(shù)據(jù)（適合批處理適合大數(shù)據(jù)處理（GBTBPB10k+節(jié)點(diǎn)廉價(jià)機(jī)器（多副 容 恢復(fù)機(jī)制hdfs不適合低延遲（毫秒級(jí)）和高吞吐率數(shù) （數(shù)據(jù)落地磁盤不適合大量小文件存?。ㄕ加胣amenode內(nèi)存，尋道時(shí)間長）（塊不適合并發(fā)寫入，文件隨機(jī)修改（副本機(jī)制，namenodedatanodehadoop1.x中hdfs保存元數(shù)據(jù)（文件權(quán)限信息，文件包含那些塊，blockdatanode：heartbeat+datasecondarynamenode：backup執(zhí)行合并時(shí)間：根據(jù)配置文件設(shè)置的fs.checkpoint.period默認(rèn)3600editslog大小fs.checkpoint.size規(guī)定edits是64MBSNNeditsfsimage到editsfsimagefsimage.ckpt到nn重命名edits.new HDFS數(shù)據(jù)單元Block大小和副本數(shù)通過 變更，BlockSize不可變更HDFS >create命令 >create命令(namenode)(記錄元據(jù)，分配DN)>塊信息>DFS( >write命令-- )-->writepacket>DN1 DN3->DN2-->DN1>ackpacket ：NN記錄元數(shù)據(jù)信息，分配數(shù)據(jù)在哪些DN；客戶端切分?jǐn)?shù)據(jù)塊，客戶端直接向DN傳輸數(shù)據(jù)HDFS hdfs文件權(quán)限： 好人做錯(cuò)事，不做壞事；hdfs相信你告訴我是誰hadoopnamenodefsimageedits>建立文件系統(tǒng)元數(shù)據(jù)映射fsimage此階段NN運(yùn)行在安全模式（只讀），此階段NN收集DN的報(bào)告，當(dāng)數(shù)據(jù)塊達(dá)到最小副本數(shù)以上時(shí)，會(huì)被認(rèn)為是“安全”的，在一定比例（可設(shè)置）的數(shù)數(shù)據(jù)塊的位置并不是由namenode 的，而是以塊列表形式在datanodemapreduceMap-reduceMapper–“簡單的任務(wù)”有幾個(gè)含義：數(shù)據(jù)或計(jì)算規(guī)模相對(duì)任務(wù)要大大縮小主JobTracker:負(fù)責(zé)調(diào)度分配每一個(gè)子任務(wù)task運(yùn)行于TaskTrackertask就重新分配其任務(wù)到其他節(jié)點(diǎn)。每一個(gè)hadoop集群中只一個(gè)JobTracker,一般它運(yùn)行在Master節(jié)點(diǎn)上。–從TaskTracker主動(dòng)與JobTracker為了減少網(wǎng)絡(luò)帶寬TaskTrackerHDFS的DataNodemapreduce 重寫write和readFields（序列化自定義比較規(guī)則 paratorClass（分組策略GroupByYear 重寫 parable parable自定義MyPartition重寫getPartition(ClimateWritablekeyTextint自定義比較規(guī)則 paratorClass（組內(nèi)排序SortHot SortHot()重寫 parable parable定義reduce數(shù)hadoop在并行計(jì)算中我們總希望分配的每一個(gè)task都能以差不多的粒度來切分并且完hadoop中數(shù)據(jù)傾斜會(huì)極大影響性能的一個(gè)背景是mapreduce框架中總是不分條件的進(jìn)行sort.在通用情況下mapsort+partition+reducesort可以得到結(jié)果，但是這個(gè)過程不一定是最優(yōu)的.對(duì)于關(guān)系型計(jì)算,其中數(shù)據(jù)傾斜影響最大的地方在reduce的sort,reduce處理的數(shù)據(jù)量的大小如果超過給定的reducejvm的大小的2倍不到的閾值的時(shí)候(這個(gè)閾值是我猜測的，具體以實(shí)際 準(zhǔn))，reduce端會(huì)發(fā)生multi-passmergesort的情況，這個(gè)時(shí)候觀察這些運(yùn)行較慢的reducetask的metrics會(huì)發(fā)現(xiàn)reduce跟IO相關(guān)的metrics會(huì)比其他reduce在map端和reduce端都有可能發(fā)生數(shù)據(jù)傾斜。在map的數(shù)據(jù)集的處理效率更低。在reduce端的數(shù)據(jù)傾斜常常來源于MapReduce的默正常的數(shù)據(jù)分布理論上都是傾斜的，就是我們所說的20-80原理：80%的 中在20%的人手中,80%的用戶只使用20%的功能,20%的用戶貢獻(xiàn)了80%的訪既然reduce本身的計(jì)算需要以合適的內(nèi)存作為支持，在硬件環(huán)境容許的情況下，增加reduce的內(nèi)存大小顯然有改善數(shù)據(jù)傾斜的可能，這種方式尤其適合數(shù)據(jù)分布第一種情況，單個(gè)值有大量記錄,這種值的所有已經(jīng)超過了分配給reduce的內(nèi)存，無論你怎么樣分區(qū)這種情況都不會(huì)改變.當(dāng)然這種情況的限制也非常明顯,1.內(nèi)存的限制存在，2.可能會(huì)對(duì)集群其他任務(wù)的運(yùn)行產(chǎn)生不穩(wěn)定增加reduce個(gè)數(shù)：緩解偶然情況下的某些reduce不分配了多個(gè)較多記可以預(yù)測某個(gè)固定組合的數(shù)據(jù)分布情況,對(duì)于特定的查詢?nèi)绻懊鎯煞N方式都沒用，實(shí)現(xiàn)自己的partitioner也許是一個(gè)好的方式.map端combiner（減少數(shù)據(jù)創(chuàng)建job時(shí)可以添加需要cache的文件：對(duì)于key分布不均勻的數(shù)據(jù)并且數(shù)據(jù)量不大，可以使用DistributedCachemap的時(shí)候直接從內(nèi)存中數(shù)據(jù)不需要到reduce階段處理從而提高性能。reduce分配的內(nèi)存遠(yuǎn)小于處理的數(shù)據(jù)量時(shí)，會(huì)產(chǎn)生multi-passsort的情況是瓶頸，那么就要問：這種排序是有必要的嘛？是否有其他排序算法或優(yōu)化可以根據(jù)特定情況降低他瓶頸的閾值?mapreduce適合處理這種情況嘛（6）?某一個(gè)key分配了過多的記錄數(shù)，對(duì)于只有一次partittion的機(jī)會(huì)，分配錯(cuò)map-reduce-reduce的方式計(jì)算，那么對(duì)于同一個(gè)key不需要分配到同一個(gè)reduce中，在第一個(gè)reduce中得到的結(jié)果可以在第二個(gè)reduce才匯總?cè)ブ?，第二個(gè)reduce不需要sort–merge的步驟，因?yàn)榍耙粋€(gè)reduce已經(jīng)排過序了，中間的reduce處理的數(shù)據(jù)不用關(guān)心partition怎么分，處理的數(shù)據(jù)量都是一樣大，而第二個(gè)reduce又不使用sort-merge來排序，不會(huì)遇到現(xiàn)在的內(nèi)存大小的問題減小ReduceReduce數(shù)據(jù)傾斜一般是指map抽樣和范圍分區(qū)：Hadoop默認(rèn)的分區(qū)器是基于map區(qū)。例如，如果map輸出鍵的單詞來源于一本書。其中大部分必然是省略詞reduce實(shí)例。而將其他的都發(fā)送給剩余的reduce使用Combine況下，combine的目的就是聚合并精簡數(shù)據(jù)。hbase預(yù)先劃分hbasehadoop2.xHadoop1.0HDFS和MapReduceNameNode和JobTrackerMapReduce難以支持除MapReduceSpark、StormHDFS2.x如何解決這些問題單點(diǎn)故障：HA,NameNode（如果主NameNode換到備NameNode上）解決內(nèi)存受限問題：HDFSFederation(水平擴(kuò)展，支持多個(gè)每個(gè)NameNode分管一部 所有NameNode共享所有DataNodexHDFS,HDFS1.x命令和API仍可以使用HDFS主NameNode對(duì)外提供服務(wù)，備NameNode同步主NameNode換,所有DataNode同時(shí)向兩個(gè)NameNode匯報(bào)數(shù)據(jù)塊信息HDFS自動(dòng)切換：基于Zookeeper實(shí)現(xiàn)基于ZookeeperZookeeperFailoverController： NameNode健康狀態(tài)，并向ZookeeperNameNode,NameNode掛掉后，ZKFCNameNodeZKFC鎖的NameNode變?yōu)閍ctiveHDFS2.x通過多個(gè)namenode/namespace把元數(shù)據(jù)的和管理分散到多個(gè)節(jié)點(diǎn)中，使namenode/namespace能把單個(gè)namenode的負(fù)載分散到多個(gè)節(jié)點(diǎn)中，在HDFS數(shù)據(jù)規(guī)模較大的時(shí)候會(huì)也降低HDFS的性能?？梢酝ㄟ^多個(gè)namespace來不同類型的應(yīng)用，把不同類型應(yīng)用的HDFS元數(shù)據(jù)的和管理分派到不同的namenode中。YARN：YetAnotherResourceNegotiator；Hadoop2.0新引入的資源管理系統(tǒng)，直接從MRv1思想：將MRv1中JobTracker的資源管理和任務(wù)調(diào)度兩個(gè)功能分開，分別由ResourceManager和ApplicationMaster進(jìn)程實(shí)現(xiàn) YARN的引入，使得多個(gè)計(jì)算框架可運(yùn)行在一個(gè)集群中每個(gè)應(yīng)用程序?qū)?yīng)一個(gè)ApplicationMasterYARNMapReduce、Spark、StormmapreduceonYARN22 和容錯(cuò)MapTask/ReduceTask：MRv1每個(gè)MapRduce作業(yè)對(duì)應(yīng)一個(gè)MRAppMasterMRAppMaster任務(wù)調(diào)度YARN將資源分配給MRAppMasterMRAppMasterMRAppMaster容錯(cuò)失敗后，由YARN任務(wù)失敗后，MRAppMasterhiveHive編譯器的執(zhí)行過為：將SQL轉(zhuǎn)換成抽象語法樹（Parser）->將抽象語法樹 yzer)->將查詢塊轉(zhuǎn)換成邏輯查詢計(jì)劃(Logic Generator)->重寫邏輯查詢計(jì)劃(LogicalOptimizer)->將邏輯計(jì)劃轉(zhuǎn)成物理計(jì)劃M/Rjobs(Physical nGenerator)->選擇最佳的Join策略(PhysicalOptimizer)。hbase架構(gòu)：zookeeper（分布式協(xié)同服務(wù)，保存元數(shù)據(jù)）+HDFS（文件系統(tǒng)+MapReduce(海量數(shù)據(jù)處理)+Master（region，regionserver理增刪改）+RegionServer（region，處理對(duì)region的IO，切分region）（寫）一個(gè)region由多個(gè)store組成，一個(gè)store對(duì)應(yīng)一個(gè)CF（列族）；store包括位于內(nèi)存中的memstore和位于磁盤的storefile，寫操作先寫入memstore，當(dāng)memstore中的數(shù)據(jù)達(dá)到某個(gè)閾值，hregionserver會(huì)啟動(dòng)flashcache進(jìn)程寫入storefile，每次寫入形成單獨(dú)的一個(gè)storefile；當(dāng)storefile文件的數(shù)量增長到一定閾值后，系統(tǒng)會(huì)進(jìn)行合并（minor、majorcompaction），在合并過程中會(huì)進(jìn)行版本合并和刪除工作（majar），形成更大的storefile；當(dāng)一個(gè)region所有storefile的大小和超過一定閾值后，會(huì)把當(dāng)前的region分割為兩個(gè)，并由hmaster分配到相應(yīng)的regionserver服務(wù)器，實(shí)現(xiàn)負(fù)載均衡；（讀）客戶端檢索數(shù)據(jù)，zookeeper-->-ROOT>RegionServer->Regionsmemstore找，找不到再找storefile->DFS;region，直接讀HBase自動(dòng)把表水平劃分成多個(gè)區(qū)域(region)，每個(gè)region會(huì)保存一個(gè)表里面某段連續(xù)的數(shù)據(jù)；每個(gè)表一開始只有一個(gè)region，隨著數(shù)據(jù)不斷插入表，region斷增大，當(dāng)增大到一個(gè)閥值的時(shí)候，region就會(huì)等分會(huì)兩個(gè)新的region（裂變hbase加快批量寫入速度：預(yù)先創(chuàng)建一些空的rowkey優(yōu)化：定長（10-100bytes）；以字典序（充分利用，將可能被一塊的數(shù)據(jù)在一起）；flush時(shí)，因hbaseregion為單位進(jìn)行，因此與此列族相鄰的列族（store）也會(huì)因關(guān)聯(lián)效應(yīng)觸發(fā)flush，導(dǎo)致頻繁IOHtable對(duì)象，共用Configuration：HTablePool線程安全storm編程模型：DAG,Spout，BoltStorm數(shù)據(jù)不經(jīng)過磁盤，處理完就沒有了，數(shù)據(jù)交換經(jīng)過網(wǎng)絡(luò)，沒有磁盤IO開銷Nimbus:集群管理（Master）（slaves向zookeeper寫信息，nimbus通過zk獲取slaves節(jié)點(diǎn)信息（狀態(tài)，運(yùn)行任務(wù)）），調(diào)度topology（ worker分配到supervisor）調(diào)用topolopy，將調(diào)度信息寫入檢查supervisor和worker（如重新調(diào)度處理topology kill，rebalance(使topology分布均勻)等請cluster和topology狀態(tài)的thrift （thrift接口實(shí)現(xiàn)）（所以當(dāng)程序規(guī)模比較大的時(shí)候呢，各個(gè)節(jié)點(diǎn)都去nimbus節(jié)點(diǎn) JAR包，那么nimbus的帶寬很快就會(huì)成為瓶Supervisorworker（slaves）（nimbusworker）（每個(gè)supervisor會(huì)啟動(dòng)多個(gè)worker，默認(rèn)為四個(gè)）Worker：（jvm）executortopolopy中的worker輸，向zk寫心跳Executor：實(shí)際工作的線程（執(zhí)行spout和bolt中的nextTuple和execute）,傳輸 receivequeue> >executortransferqueue>(wokerrtransferqueue>workertransferZookeeper：狀態(tài)信息，調(diào)度信息，心跳，錯(cuò)誤信rebalance的話也是需要經(jīng)過nimbus，rebalance的話就是能使得topology更加均勻，比如說給topology增加worker4個(gè)worker，我現(xiàn)在給它增加到20個(gè)worker，rebalance會(huì)把topology重新調(diào)度一次用zookeeperStorm用zookeeperKV來使用，storm使用zookeeper呢需求非常簡單，就是說讓整個(gè)集群別變成無狀態(tài)nimbus這種master到一個(gè)KV里面去，到一個(gè)系統(tǒng)里面去，最簡單的就是一個(gè)KV就解決了，之所以選用zookeeperKV一個(gè)系統(tǒng)，它里面一般是3個(gè)或者5個(gè)機(jī)器，當(dāng)它的機(jī)器壞掉的數(shù)目不超過一半的時(shí)候呢，zookeeper還是可用的，所以zookeeper在這里起到了一個(gè)高可用5和hadoophadoop中slave直接向mastermaster向slavemaster儲(chǔ)slave信息和元數(shù)據(jù)信息storm中nimbus和supvisor之間不通信，各個(gè)節(jié)點(diǎn)都把狀態(tài)信息往zk上寫。storm用zookeeper呢，和其它的master/slave的技術(shù)使用zookeeper呢還是有點(diǎn)不一樣，比如hadoop他是一個(gè)典型的master/slave架構(gòu)，但是在hadoop里面呢，所有的salve都會(huì)向master去匯報(bào)狀態(tài)，比如mapreduce里面的tracker向jobtracker匯報(bào)，這樣呢在jobtracker里面的內(nèi)存呢就會(huì)有所有tracker的狀態(tài)，同時(shí)在tracker向jobtracker匯報(bào)心跳的時(shí)候呢，jobtracker會(huì)在回應(yīng)里面呢，帶上你要執(zhí)行的task，tracker你要執(zhí)行什么taskhadoop方式的好處是比較直接，slave向mastermaster給slave簡單很清晰，storm務(wù)如果延遲10分鐘什么的話，影響是很大的，storm就是要保證當(dāng)任何掛掉的時(shí)候，業(yè)務(wù)可以穩(wěn)定運(yùn)行，所以它需要各個(gè)進(jìn)程都是無狀態(tài)的，比如nimbus，如果各個(gè)節(jié)點(diǎn)都向它匯報(bào)，如果nimbus一旦掛了，那就存在這些個(gè)狀態(tài)信息怎么恢復(fù)的問題，各個(gè)節(jié)點(diǎn)連不上的時(shí)候，怎么處理的問題，所以storm它的做法是各個(gè)節(jié)點(diǎn)都把狀態(tài)信息往zk上寫，因?yàn)閦k我們認(rèn)為是可靠地，這樣比如說如果nimbus掛了，那再新起一個(gè)nimbus，它去zk上面去取Supervisor的信息，它就可以立刻知道supervisor處于一個(gè)什么狀態(tài)，supervisor也一樣，它不需要與nimbus通信，它的心跳是往zk上面寫的，而它啟動(dòng)task的時(shí)候呢，也不是從nimbus上面要task，而是nimbus把Task放到zookeeper上面去，然后supervisorzk上面去讀，然后讀到task之后呢再去啟動(dòng)task，所以相互之間通過zkzkhadoopsupervisortopolopytopolopy（包括topology多少個(gè)worker啊，每個(gè)worker有個(gè)id號(hào)啊，worker分配到哪些機(jī)器啊），worker心跳，spout/bolt錯(cuò)誤信息（最近20條信息）why需要解決和其他系統(tǒng)耦合的問題，storm沒有自己的 ，沒有數(shù)據(jù)功能，因上游產(chǎn)生數(shù)據(jù)量大而造成雪崩）；輸出結(jié)果數(shù)據(jù)同樣需要消息隊(duì)列；DRPC是請求響應(yīng)式的，kafka是流式的讀寫kafka系統(tǒng)之間解耦合（隊(duì)列模型，訂閱發(fā)布模型kafka：高吞吐分布式消息系統(tǒng)架構(gòu)：producer，consumer，broker（server，負(fù)責(zé)處理消息讀，寫請求，存一個(gè)topic分成多個(gè)partition；partition內(nèi)部消息強(qiáng)有序，都有一個(gè)producer自己決定往哪個(gè)partition寫消息，可以是輪詢或者kafka里面的消息是有topic來組織的，簡單的我們可以想象為一個(gè)隊(duì)列，一個(gè)隊(duì)列就是一個(gè)topic，然后它把每個(gè)topic又分為很多個(gè)partition，這個(gè)是為了做并行的，在每個(gè)partition里面是有序的，相當(dāng)于有序的隊(duì)列，其中每個(gè)消息都有個(gè)序號(hào)，比如0到12，從前面讀往后面寫，一個(gè)partition對(duì)應(yīng)一個(gè)brokerbroker可以管多個(gè)partition6個(gè)partition，有兩個(gè)broker，那每個(gè)broker3個(gè)這個(gè)partition可以很簡單想象為一個(gè)文件，當(dāng)數(shù)據(jù)發(fā)過來的時(shí)候它就往這個(gè)partition上面append，追加就行，kafka和很多消息系統(tǒng)不一樣，很多消息系統(tǒng)是消費(fèi)完了我就把它刪掉，而kafka是根據(jù)時(shí)間策略刪除，而不是消費(fèi)完就刪除，在kafkaconsumer自 消費(fèi)到哪個(gè)consumer都有對(duì)應(yīng)的group內(nèi)是queueconsumer消費(fèi)不同的partition，因此一個(gè)消息在group內(nèi)只消費(fèi)一次group間是publish-subscribe消費(fèi)模型:各個(gè)group消息在被每個(gè)group消費(fèi)一次kafka 直接寫到磁盤里面去，就是直接append分布式，數(shù)據(jù)副本，也就是同一份數(shù)據(jù)可以到不同的broker一份數(shù)據(jù)，磁盤壞掉的時(shí)候，數(shù)據(jù)不會(huì)丟失，比如33均衡，可擴(kuò)展，擴(kuò)展，不需要停服務(wù)的等，第二消費(fèi)狀態(tài)自己消費(fèi)到哪個(gè)地方了，Queue的模型，發(fā)布訂閱（廣zerocopy（copy有人可能會(huì)說kafka，其實(shí)不會(huì)而且是非常好的，為什么是非常好的，因?yàn)閗afka寫磁盤是順序的，所以不斷的往前產(chǎn)生，不斷的往后寫，kafka還用了sendFile的0拷貝技術(shù)，提高速度，而且還用到了批量讀寫，一批批往里寫，64K為單位，100K為單位，每一次網(wǎng)絡(luò)傳輸量不會(huì)特別小，RTT（RTT:Round-TripTime）的開銷就會(huì)微不足道，對(duì)文件的操作不會(huì)是很小的IO，也會(huì)是比較大塊的IO我們看到“零拷貝”是指計(jì)算機(jī)操作的過程中，CPU不需要為數(shù)據(jù)在內(nèi)存之間容拷貝到用戶空間（UserSpace）而直接在內(nèi)核空間（KernelSpace）中傳輸?shù)骄W(wǎng)絡(luò)的方式。Linux中的sendfileJavaNIO中的FileChannel.transferTo()方法都實(shí)現(xiàn)了零拷貝的功能，而在Netty中也通過在FileRegion中包裝了NIO的NIOnettykafka塊IOkafka+storm的優(yōu)點(diǎn)：kafkakafka的分布式、高性能和stormpub-sub模型可以讓多個(gè)stormkafka靈活消費(fèi)的模式能配合storm（exactly-once）的處理模sparkRDD:ResilientDistributedDataset它是不變的數(shù)據(jù)結(jié)構(gòu)它是支持跨集群的可以根據(jù)數(shù)據(jù)記錄的key提供了粗粒度它將數(shù)據(jù)在內(nèi)存中，從而提供了低延遲transformations延遲執(zhí)行--針對(duì)RDDAction操作算子Lineage（血統(tǒng)）：RDD(Lineage)記住了它是如何從其它RDD中演變過來的。相比其它系統(tǒng)的細(xì)顆粒度的內(nèi)存數(shù)據(jù)更新級(jí)別的備份或者LOG機(jī)制，RDD的Lineage記錄的是粗顆粒度的特定數(shù)據(jù)轉(zhuǎn)換（Transformation）操作（filtermapjoinetcRDD丟失時(shí)，它可以通過Lineage獲取足夠的信息來重新運(yùn)算和恢復(fù)丟失的數(shù)據(jù)分RDD如何保障數(shù)據(jù)處理效率RDD的分區(qū)特性與并行計(jì)算能力（persistence和patitioning）(RDD定義了parallerizeSparkRDD將操作分為兩類：transformation與action。無論執(zhí)行了多少次transformation操作，RDD都不會(huì)真正執(zhí)行運(yùn)算，只有當(dāng)action操作被執(zhí)行時(shí)，運(yùn)算才會(huì)觸發(fā)。而在RDD的內(nèi)部實(shí)現(xiàn)機(jī)制中，底層接口則是基于迭代器的， 33RDD對(duì)容錯(cuò)的支持：支持容錯(cuò)通常采用兩種方式：數(shù)據(jù) 貝大量數(shù)據(jù)，畢竟帶寬的數(shù)據(jù)遠(yuǎn)遠(yuǎn)低于內(nèi)存。RDD天生是支持容錯(cuò)的。首先，（GraphofOperation），因此當(dāng)執(zhí)行任務(wù)的Worker失敗時(shí)，完全可以通過操作圖獲得之前執(zhí)行的操作，進(jìn)行重新計(jì)算。（每個(gè)RDD都會(huì)記錄自己依賴與哪個(gè)或哪些RDD，萬一某個(gè)RDD的某些partition掛了，可以通過其它RDD計(jì)算迅速恢復(fù)出來）由于無需采用replication方式支持容錯(cuò)，很好地降RDD的窄依賴是指父RDD的所有輸出都會(huì)被指定的子RDD路徑是固定的；寬依賴是指父RDD的輸出會(huì)由不同的子RDD消費(fèi)，即輸出路調(diào)度器會(huì)計(jì)算RDDRDD一個(gè)Stage中，而寬依賴則作為劃分不同Stage的判斷標(biāo)準(zhǔn)。導(dǎo)致窄依賴的Transformationmap、flatMap、filter、sample；導(dǎo)致寬依賴的Transformation操作：sortByKey、reduceByKey、groupByKey、任務(wù)調(diào)度：RDD >DAGScheduler(splitgraph oftasks eachstagasready) (Clustermanager,launchtaskviaclustermanager,retryfailedorstragglingtasks) >Worker(executetasks,storeandserveDAGStage構(gòu)建DAG記錄哪個(gè)RDDStage將taskset傳給底層調(diào)度器重新提交shuffle輸出丟失的stageTaskScheduler:提交taskset(?task)到集群運(yùn)?