笔试总结基础面试题详解

PAGEPAGE1熟练掌握Java语言中集合、动 、IO与NIO等知识 java如果涉及到堆栈，队列等操作，应该考虑用List，对于需要快速插入，删除元素，应该使用LinkedList，如果需要快速随机 ArrayListLinkedListHashMap通过hashcode对其内容进行快速查找，而TreeMapHashMapHashMap(intinitialCapacity,floatloadFactor)：以指定初始容量、指定的负载因子创建一个HashMap。因为随着map中元素增加导致扩容比较消耗资源，因此如果知道大概需要存入多少元素，可以设定初始容量。以此优化hashmap性ConcurrentHashMap（hashtable动 定义InvocationHandlertarget（目标对象getInstance（target）使 创建target 对重写invokeIO与第式：我从硬盘数据，然后程序一直等，数据读完后，继续操作。这种方式是最简单的，叫阻塞IO。第二种方式：我从硬盘数据，然后程序继续向下执行，等数据完后，即处理数据，也可以执行完当前操作在数据。在一起的JavaIO中，都是阻塞式IO，NIO引入了非阻塞式IO还有一种就是同步IO和异步IO。经常说的一个术语就是“异步非阻塞”，至于JavaNIO的Selector，在旧的JavaIO系统中，是基于Stream的，即“流”，流式IO。当程序从硬盘往内存数据的时候，操作系统使用了2个“小伎俩”来提高性能，那就是预读，如果我了第一扇区的第三磁道的内容，那么你很有可前出来，放在内存中，即缓存。通过上面可以看到，操作系统是按块Block从硬盘拿数据，就如同一个大脸盆，一下子就放入了一盆水。但是，当Java使用的时候，旧的IO确实基于流Stream原来的I/O库(在java.io.*中)与NIO最重要的区别是式。正如前面提到的，原来的I/O以流的方式处理数据，而NIO以块的方式通道是对原I/O包中的流的模拟。到任何目的地(或来自任何地方)的所有数据都必须通过一个Channel对象。一个Buffer实质上是一个容器对象。发送给一个通道的所有对象都必须首先放到缓冲区中；同样地，从通道中的任何redisredisRedis是一个开源的key-value系统，它通常被称为一个数据结构服务器，因为keys可以包含strings，hashes，lists，sets和sortedsets。当需要除key/value之外的数据类型支持时，使用Redis更合适。当的数据不能被剔除时，使用Redis更合适。（相比memcached）构建消息系统 的就是使用消息队列。通过消息队列，将短时间高并发产生的事务消息在消息队列中，从而削平 如果要实现任务队列，只需要让生产者将任务使用LPUSH某个键中，另一边让消费者不断地使用RPOP命令从该键中取出任务即可。一个sentinel实例可以监视多个主服务器（及其下的从服务器），多个sentinel服务器共同监视一个主服务器（及其下的从服务器）sentinel （ip one（取消其作为从服务器Sentinelmonitormymaster127.0.0.163792mymaster，他的ip地址为127.0.0.1端为6397，而确认这个主服务器已下Sentinel 分片（shard）这项技术的原理是将整个数据库分为多个部分，使用不同的服务器来不同的部分，并负责处理相应部分令请求（包括读请求和写-ketama：hash，主要用于在实现缓存服务时，防止某个服务器下线而造Twem允许用户通过设置配置选项，让twem在某个服务器下线时，自动地将原本由下线服务器负责处理的数据库键转交给池中的其他服务器来处理；并且用户还可以设置一个重试时间，让twem在一段时间之后，的话，twem就会重新将数据库键交给该服务器来处理分布式的Redis群的性能瓶颈，它具有、高可用和分片特性集群的行为和我们之前介绍的单机特性的行为是完全一样Redis集群的主节点内置了类似RedisSentinel16384个槽slot（分片创建集群的操作可以通过使用位于Redis安装文件夹内的redis-trib.rb程序来完成，这是一个使用Ruby编写的Redis集群管理程序集群中的主节点负责处理槽（数据），而从节点则是主节点的主节点只会执行和自己负责的槽有关令，当节点接收到不属于自己处理的槽令时，它将会处理指定槽的节点的地址返回给客户端，而客户端会向正熟悉linux命令，熟练使用s，部署高可用集服务器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系统信息),unamea（yumcleanall,yumupdate,yumlistinstalledcat/proc/cpuinfo,cat/proc/meminfo-m内存信息)，uptime，catcutdf1/etc/passwd,cutdf1/etc/groupcrontabl(计划任务),chkconfiglist（系统服务w（活动用户），idroot（用户信息），last（登陆日志）tail-f.log,tar-zxvf.gz.tar if[$var1/>$var2]thenecho1elseecho2if[]&&[]||[]forvarinlistdoecho$varifecho$var|egrep-q'^[0-9]+$'thenecho1elseecho2四层：tcp之上的第四层协议LVSIP,端口，在操作系统内核中。熟悉MySQL,Oracle关系数据库，完成千万级sql语句优化，搭建mysql千万级sql对查询进行优化，应尽量避免全表扫描，首先应考虑在where及order涉及的列上建立索引应尽量避免在where子句中对字段进行null值判断，否则将导致引擎放弃应尽量避免在where子句中使用!=或<>操作符应尽量避免在where子句中使用or来连接条件（unionin和notin也要慎用如果在whereSQL应尽量避免在where子句中对字段进行表达式操作应尽量避免在where不要在where会降低查询和连接的性能，并会增加开销任何地方都不要使用select*fromt，用具体的字段列表代替“*”，不要尽量把所有的列设置为NOTNULL，如果你要保存NULL，手动去设置果你的数据只有你所知的少量的几个。最好使用ENUMmysql 最强大的一项功能是实现“读写分离(Read/WriteSplitting)”。基本的原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库被用来把事务性查询导致的变更同步到集群中的从数据库。当然，主服务主从服务器上。可以利用数据库的这能，实现数据库的读写分离，从而改利用数据库的读写分离，Web（Master），主数据库通过主 （Slave），Web这一方案使得在大量读操作的Web应用可以轻松地数据，而主数据库也只MySQL数据原理：Masterbinarylog)中（这些记录叫做二进制日志事件，binarylogevents）；Slave将Master的二进制日志(binarylogevents)拷贝到它的中继日志(relaylog)；Slave服务器中有一个I/OI/OThread)在不停地Master的二进制日志(BinaryLog)是否有更新：如果没有它会睡眠等待Master产生新的日志事11件；如果有新的日志(LogEvents)，则会将其拷贝至Slave服务器中的中继日志(RelayLog)。Slave重做中继日志(RelayLog)中的，将Master上的改变反映到它自己的数据库中。slave服务器中有一个SQL线程(SQLThread)从中继日志事件，并重做其中的从而更新Slave的数据，使其与Master中的数据一致。只要该线程与I/OOSmysql开启二进制日志log-bin=master-使用二进制日志的索引文件log-bin-为服务器添加唯一的编号server-HDFShdfs高容错性（副本策略移动计算而非数据（适合批处理适合大数据处理（GBTBPB10k+节点廉价机器（多副 容 恢复机制hdfs不适合低延迟（毫秒级）和高吞吐率数 （数据落地磁盘不适合大量小文件存取（占用namenode内存，寻道时间长）（块不适合并发写入，文件随机修改（副本机制，namenodedatanodehadoop1.x中hdfs保存元数据（文件权限信息，文件包含那些块，blockdatanode：heartbeat+datasecondarynamenode：backup执行合并时间：根据配置文件设置的fs.checkpoint.period默认3600editslog大小fs.checkpoint.size规定edits是64MBSNNeditsfsimage到editsfsimagefsimage.ckpt到nn重命名edits.new HDFS数据单元Block大小和副本数通过 变更，BlockSize不可变更HDFS >create命令 >create命令(namenode)(记录元据，分配DN)>块信息>DFS( >write命令-- )-->writepacket>DN1 DN3->DN2-->DN1>ackpacket ：NN记录元数据信息，分配数据在哪些DN；客户端切分数据块，客户端直接向DN传输数据HDFS hdfs文件权限： 好人做错事，不做坏事；hdfs相信你告诉我是谁hadoopnamenodefsimageedits>建立文件系统元数据映射fsimage此阶段NN运行在安全模式（只读），此阶段NN收集DN的报告，当数据块达到最小副本数以上时，会被认为是“安全”的，在一定比例（可设置）的数数据块的位置并不是由namenode 的，而是以块列表形式在datanodemapreduceMap-reduceMapper–“简单的任务”有几个含义：数据或计算规模相对任务要大大缩小主JobTracker:负责调度分配每一个子任务task运行于TaskTrackertask就重新分配其任务到其他节点。每一个hadoop集群中只一个JobTracker,一般它运行在Master节点上。–从TaskTracker主动与JobTracker为了减少网络带宽TaskTrackerHDFS的DataNodemapreduce 重写write和readFields（序列化自定义比较规则 paratorClass（分组策略GroupByYear 重写 parable parable自定义MyPartition重写getPartition(ClimateWritablekeyTextint自定义比较规则 paratorClass（组内排序SortHot SortHot()重写 parable parable定义reduce数hadoop在并行计算中我们总希望分配的每一个task都能以差不多的粒度来切分并且完hadoop中数据倾斜会极大影响性能的一个背景是mapreduce框架中总是不分条件的进行sort.在通用情况下mapsort+partition+reducesort可以得到结果，但是这个过程不一定是最优的.对于关系型计算,其中数据倾斜影响最大的地方在reduce的sort,reduce处理的数据量的大小如果超过给定的reducejvm的大小的2倍不到的阈值的时候(这个阈值是我猜测的，具体以实际 准)，reduce端会发生multi-passmergesort的情况，这个时候观察这些运行较慢的reducetask的metrics会发现reduce跟IO相关的metrics会比其他reduce在map端和reduce端都有可能发生数据倾斜。在map的数据集的处理效率更低。在reduce端的数据倾斜常常来源于MapReduce的默正常的数据分布理论上都是倾斜的，就是我们所说的20-80原理：80%的 中在20%的人手中,80%的用户只使用20%的功能,20%的用户贡献了80%的访既然reduce本身的计算需要以合适的内存作为支持，在硬件环境容许的情况下，增加reduce的内存大小显然有改善数据倾斜的可能，这种方式尤其适合数据分布第一种情况，单个值有大量记录,这种值的所有已经超过了分配给reduce的内存，无论你怎么样分区这种情况都不会改变.当然这种情况的限制也非常明显,1.内存的限制存在，2.可能会对集群其他任务的运行产生不稳定增加reduce个数：缓解偶然情况下的某些reduce不分配了多个较多记可以预测某个固定组合的数据分布情况,对于特定的查询如果前面两种方式都没用，实现自己的partitioner也许是一个好的方式.map端combiner（减少数据创建job时可以添加需要cache的文件：对于key分布不均匀的数据并且数据量不大，可以使用DistributedCachemap的时候直接从内存中数据不需要到reduce阶段处理从而提高性能。reduce分配的内存远小于处理的数据量时，会产生multi-passsort的情况是瓶颈，那么就要问：这种排序是有必要的嘛？是否有其他排序算法或优化可以根据特定情况降低他瓶颈的阈值?mapreduce适合处理这种情况嘛（6）?某一个key分配了过多的记录数，对于只有一次partittion的机会，分配错map-reduce-reduce的方式计算，那么对于同一个key不需要分配到同一个reduce中，在第一个reduce中得到的结果可以在第二个reduce才汇总去重，第二个reduce不需要sort–merge的步骤，因为前一个reduce已经排过序了，中间的reduce处理的数据不用关心partition怎么分，处理的数据量都是一样大，而第二个reduce又不使用sort-merge来排序，不会遇到现在的内存大小的问题减小ReduceReduce数据倾斜一般是指map抽样和范围分区：Hadoop默认的分区器是基于map区。例如，如果map输出键的单词来源于一本书。其中大部分必然是省略词reduce实例。而将其他的都发送给剩余的reduce使用Combine况下，combine的目的就是聚合并精简数据。hbase预先划分hbasehadoop2.xHadoop1.0HDFS和MapReduceNameNode和JobTrackerMapReduce难以支持除MapReduceSpark、StormHDFS2.x如何解决这些问题单点故障：HA,NameNode（如果主NameNode换到备NameNode上）解决内存受限问题：HDFSFederation(水平扩展，支持多个每个NameNode分管一部 所有NameNode共享所有DataNodexHDFS,HDFS1.x命令和API仍可以使用HDFS主NameNode对外提供服务，备NameNode同步主NameNode换,所有DataNode同时向两个NameNode汇报数据块信息HDFS自动切换：基于Zookeeper实现基于ZookeeperZookeeperFailoverController： NameNode健康状态，并向ZookeeperNameNode,NameNode挂掉后，ZKFCNameNodeZKFC锁的NameNode变为activeHDFS2.x通过多个namenode/namespace把元数据的和管理分散到多个节点中，使namenode/namespace能把单个namenode的负载分散到多个节点中，在HDFS数据规模较大的时候会也降低HDFS的性能。可以通过多个namespace来不同类型的应用，把不同类型应用的HDFS元数据的和管理分派到不同的namenode中。YARN：YetAnotherResourceNegotiator；Hadoop2.0新引入的资源管理系统，直接从MRv1思想：将MRv1中JobTracker的资源管理和任务调度两个功能分开，分别由ResourceManager和ApplicationMaster进程实现 YARN的引入，使得多个计算框架可运行在一个集群中每个应用程序对应一个ApplicationMasterYARNMapReduce、Spark、StormmapreduceonYARN22 和容错MapTask/ReduceTask：MRv1每个MapRduce作业对应一个MRAppMasterMRAppMaster任务调度YARN将资源分配给MRAppMasterMRAppMasterMRAppMaster容错失败后，由YARN任务失败后，MRAppMasterhiveHive编译器的执行过为：将SQL转换成抽象语法树（Parser）->将抽象语法树 yzer)->将查询块转换成逻辑查询计划(Logic Generator)->重写逻辑查询计划(LogicalOptimizer)->将逻辑计划转成物理计划M/Rjobs(Physical nGenerator)->选择最佳的Join策略(PhysicalOptimizer)。hbase架构：zookeeper（分布式协同服务，保存元数据）+HDFS（文件系统+MapReduce(海量数据处理)+Master（region，regionserver理增删改）+RegionServer（region，处理对region的IO，切分region）（写）一个region由多个store组成，一个store对应一个CF（列族）；store包括位于内存中的memstore和位于磁盘的storefile，写操作先写入memstore，当memstore中的数据达到某个阈值，hregionserver会启动flashcache进程写入storefile，每次写入形成单独的一个storefile；当storefile文件的数量增长到一定阈值后，系统会进行合并（minor、majorcompaction），在合并过程中会进行版本合并和删除工作（majar），形成更大的storefile；当一个region所有storefile的大小和超过一定阈值后，会把当前的region分割为两个，并由hmaster分配到相应的regionserver服务器，实现负载均衡；（读）客户端检索数据，zookeeper-->-ROOT>RegionServer->Regionsmemstore找，找不到再找storefile->DFS;region，直接读HBase自动把表水平划分成多个区域(region)，每个region会保存一个表里面某段连续的数据；每个表一开始只有一个region，随着数据不断插入表，region断增大，当增大到一个阀值的时候，region就会等分会两个新的region（裂变hbase加快批量写入速度：预先创建一些空的rowkey优化：定长（10-100bytes）；以字典序（充分利用，将可能被一块的数据在一起）；flush时，因hbaseregion为单位进行，因此与此列族相邻的列族（store）也会因关联效应触发flush，导致频繁IOHtable对象，共用Configuration：HTablePool线程安全storm编程模型：DAG,Spout，BoltStorm数据不经过磁盘，处理完就没有了，数据交换经过网络，没有磁盘IO开销Nimbus:集群管理（Master）（slaves向zookeeper写信息，nimbus通过zk获取slaves节点信息（状态，运行任务）），调度topology（ worker分配到supervisor）调用topolopy，将调度信息写入检查supervisor和worker（如重新调度处理topology kill，rebalance(使topology分布均匀)等请cluster和topology状态的thrift （thrift接口实现）（所以当程序规模比较大的时候呢，各个节点都去nimbus节点 JAR包，那么nimbus的带宽很快就会成为瓶Supervisorworker（slaves）（nimbusworker）（每个supervisor会启动多个worker，默认为四个）Worker：（jvm）executortopolopy中的worker输，向zk写心跳Executor：实际工作的线程（执行spout和bolt中的nextTuple和execute）,传输 receivequeue> >executortransferqueue>(wokerrtransferqueue>workertransferZookeeper：状态信息，调度信息，心跳，错误信rebalance的话也是需要经过nimbus，rebalance的话就是能使得topology更加均匀，比如说给topology增加worker4个worker，我现在给它增加到20个worker，rebalance会把topology重新调度一次用zookeeperStorm用zookeeperKV来使用，storm使用zookeeper呢需求非常简单，就是说让整个集群别变成无状态nimbus这种master到一个KV里面去，到一个系统里面去，最简单的就是一个KV就解决了，之所以选用zookeeperKV一个系统，它里面一般是3个或者5个机器，当它的机器坏掉的数目不超过一半的时候呢，zookeeper还是可用的，所以zookeeper在这里起到了一个高可用5和hadoophadoop中slave直接向mastermaster向slavemaster储slave信息和元数据信息storm中nimbus和supvisor之间不通信，各个节点都把状态信息往zk上写。storm用zookeeper呢，和其它的master/slave的技术使用zookeeper呢还是有点不一样，比如hadoop他是一个典型的master/slave架构，但是在hadoop里面呢，所有的salve都会向master去汇报状态，比如mapreduce里面的tracker向jobtracker汇报，这样呢在jobtracker里面的内存呢就会有所有tracker的状态，同时在tracker向jobtracker汇报心跳的时候呢，jobtracker会在回应里面呢，带上你要执行的task，tracker你要执行什么taskhadoop方式的好处是比较直接，slave向mastermaster给slave简单很清晰，storm务如果延迟10分钟什么的话，影响是很大的，storm就是要保证当任何挂掉的时候，业务可以稳定运行，所以它需要各个进程都是无状态的，比如nimbus，如果各个节点都向它汇报，如果nimbus一旦挂了，那就存在这些个状态信息怎么恢复的问题，各个节点连不上的时候，怎么处理的问题，所以storm它的做法是各个节点都把状态信息往zk上写，因为zk我们认为是可靠地，这样比如说如果nimbus挂了，那再新起一个nimbus，它去zk上面去取Supervisor的信息，它就可以立刻知道supervisor处于一个什么状态，supervisor也一样，它不需要与nimbus通信，它的心跳是往zk上面写的，而它启动task的时候呢，也不是从nimbus上面要task，而是nimbus把Task放到zookeeper上面去，然后supervisorzk上面去读，然后读到task之后呢再去启动task，所以相互之间通过zkzkhadoopsupervisortopolopytopolopy（包括topology多少个worker啊，每个worker有个id号啊，worker分配到哪些机器啊），worker心跳，spout/bolt错误信息（最近20条信息）why需要解决和其他系统耦合的问题，storm没有自己的 ，没有数据功能，因上游产生数据量大而造成雪崩）；输出结果数据同样需要消息队列；DRPC是请求响应式的，kafka是流式的读写kafka系统之间解耦合（队列模型，订阅发布模型kafka：高吞吐分布式消息系统架构：producer，consumer，broker（server，负责处理消息读，写请求，存一个topic分成多个partition；partition内部消息强有序，都有一个producer自己决定往哪个partition写消息，可以是轮询或者kafka里面的消息是有topic来组织的，简单的我们可以想象为一个队列，一个队列就是一个topic，然后它把每个topic又分为很多个partition，这个是为了做并行的，在每个partition里面是有序的，相当于有序的队列，其中每个消息都有个序号，比如0到12，从前面读往后面写，一个partition对应一个brokerbroker可以管多个partition6个partition，有两个broker，那每个broker3个这个partition可以很简单想象为一个文件，当数据发过来的时候它就往这个partition上面append，追加就行，kafka和很多消息系统不一样，很多消息系统是消费完了我就把它删掉，而kafka是根据时间策略删除，而不是消费完就删除，在kafkaconsumer自 消费到哪个consumer都有对应的group内是queueconsumer消费不同的partition，因此一个消息在group内只消费一次group间是publish-subscribe消费模型:各个group消息在被每个group消费一次kafka 直接写到磁盘里面去，就是直接append分布式，数据副本，也就是同一份数据可以到不同的broker一份数据，磁盘坏掉的时候，数据不会丢失，比如33均衡，可扩展，扩展，不需要停服务的等，第二消费状态自己消费到哪个地方了，Queue的模型，发布订阅（广zerocopy（copy有人可能会说kafka，其实不会而且是非常好的，为什么是非常好的，因为kafka写磁盘是顺序的，所以不断的往前产生，不断的往后写，kafka还用了sendFile的0拷贝技术，提高速度，而且还用到了批量读写，一批批往里写，64K为单位，100K为单位，每一次网络传输量不会特别小，RTT（RTT:Round-TripTime）的开销就会微不足道，对文件的操作不会是很小的IO，也会是比较大块的IO我们看到“零拷贝”是指计算机操作的过程中，CPU不需要为数据在内存之间容拷贝到用户空间（UserSpace）而直接在内核空间（KernelSpace）中传输到网络的方式。Linux中的sendfileJavaNIO中的FileChannel.transferTo()方法都实现了零拷贝的功能，而在Netty中也通过在FileRegion中包装了NIO的NIOnettykafka块IOkafka+storm的优点：kafkakafka的分布式、高性能和stormpub-sub模型可以让多个stormkafka灵活消费的模式能配合storm（exactly-once）的处理模sparkRDD:ResilientDistributedDataset它是不变的数据结构它是支持跨集群的可以根据数据记录的key提供了粗粒度它将数据在内存中，从而提供了低延迟transformations延迟执行--针对RDDAction操作算子Lineage（血统）：RDD(Lineage)记住了它是如何从其它RDD中演变过来的。相比其它系统的细颗粒度的内存数据更新级别的备份或者LOG机制，RDD的Lineage记录的是粗颗粒度的特定数据转换（Transformation）操作（filtermapjoinetcRDD丢失时，它可以通过Lineage获取足够的信息来重新运算和恢复丢失的数据分RDD如何保障数据处理效率RDD的分区特性与并行计算能力（persistence和patitioning）(RDD定义了parallerizeSparkRDD将操作分为两类：transformation与action。无论执行了多少次transformation操作，RDD都不会真正执行运算，只有当action操作被执行时，运算才会触发。而在RDD的内部实现机制中，底层接口则是基于迭代器的， 33RDD对容错的支持：支持容错通常采用两种方式：数据 贝大量数据，毕竟带宽的数据远远低于内存。RDD天生是支持容错的。首先，（GraphofOperation），因此当执行任务的Worker失败时，完全可以通过操作图获得之前执行的操作，进行重新计算。（每个RDD都会记录自己依赖与哪个或哪些RDD，万一某个RDD的某些partition挂了，可以通过其它RDD计算迅速恢复出来）由于无需采用replication方式支持容错，很好地降RDD的窄依赖是指父RDD的所有输出都会被指定的子RDD路径是固定的；宽依赖是指父RDD的输出会由不同的子RDD消费，即输出路调度器会计算RDDRDD一个Stage中，而宽依赖则作为划分不同Stage的判断标准。导致窄依赖的Transformationmap、flatMap、filter、sample；导致宽依赖的Transformation操作：sortByKey、reduceByKey、groupByKey、任务调度：RDD >DAGScheduler(splitgraph oftasks eachstagasready) (Clustermanager,launchtaskviaclustermanager,retryfailedorstragglingtasks) >Worker(executetasks,storeandserveDAGStage构建DAG记录哪个RDDStage将taskset传给底层调度器重新提交shuffle输出丢失的stageTaskScheduler:提交taskset(⼀task)到集群运⾏