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

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