首页 » 面试

1.kafka处理持续流动的数据

  • 不像关系数据库和kv数据库,把数据堪称持续变化continous evolving 和不断增长 ever growing的流。
  • kafka最初使用在社交网络的实时应用和数据流中。现在是 一个流平台Stream platform,可以发布和订阅数据。

2.kafka的比较

3.和普通的消息系统比,如ActiveMQ,RabbitMQ。尽管非常相像。

  • kafka可以自由伸缩,可以作为一个公司的消息中心平台。处理整个公司所有的数据流。而其他消息系统一系列是独立的brokers
  • kafka是一个存储系统,可以按你的要求时间存储数据。即可副本保存(高可用),可持久话。
  • 一般流queue系统只会传递数据,而kafka可以用很少的代码处理派生流/数据集。(derived treams 和datasets)

4.和存储系统相比,可以看成一个实时版本的hadoop

  • kafka可以存储和定期处理大量的数据文件
  • hadoop长处是数据分析,但是kafka具有实时性,可以用于核心业务的处理

5.和ETL相比,都擅长移动数据。但是kafka只是把数据拆解出来,塞给另一个系统,实际上是一个数据平台。
6.发布订阅消息模式

  • 发布者发布消息给broker,不关心谁是reciever
  • 消费者只消费他关心类型的消息

7.kafka通用数据类型

  • kafka存储的是字节数组(Arrays of bytes),对kafka来说,这些消息对kafka来说,没有特别的格式和含义
  • kafka消息可以有一个可选的Optional key,同样是字节数组,对kafka来说,没有特别的格式和含义。key可以用来生成hash来决定分区

8.kafka批次消息

  • kafka写入消息是按批次(一组消息)写的。这些消息属于同一个topic和分区partion。这样会节约网络开销,但是批次大也会导致单个消息的传输时间变长。所以要在latency和throughput之间权衡。
  • 通常会对批次进行压缩处理,提高传输效率,同时增加了计算处理。

9.kafka message schemas 消息模式

  • kafka 被建议用JSON和XML,但是这两者缺乏强类型约束和健壮性,而且不同版本兼容性也不好
  • kafka开发者大多采用 Apche Avro ( 最初开发为hadoop使用的序列化框架),作为kafka消息的schemas。Avro提供一种紧凑的序列化格式,Schemas和message payloads是分开的,Schemas变化,不需要重新序列化,向前和向后兼容
  • kafka需要这种一致性数据,不能发布端的数据格式变化,引起所有消费端升级。即数据格式的接偶

10.kafka的主题topics

  • topic是消息的分类方式,好比数据库中的table,topic会被分区,类似数据库中的分表,这也是kafka可以水平扩展的原因。
  • kafka 只能保证分区内的有序性,不能保证整个topic的有序性 (time Ordering)。
  • 一个分区类似一个commit log,只能追加的方式吸入。
  • 这中无界的commit log 一般被描述为流。如果忽略分区,一个topic会被视为一个流。即代表单个数据流 从生产者移动到消费者。
  • 流处理框架,有kafka Stream,Storm,及实时real time的操作数据。与之对比的是离线offline处理框架。如hadoop

11.kafka的client----生产者和消费者

  • 一般使用key做hash,来决定消息写到哪个分区。也可以自定义分区器partioner。这样根据业务把需要顺序性的业务数据分到同一个分区。
  • 消费者使用一种元数据(每个消息生成的时候,都会分配一个offset并保存到消息中,这个类似数据库中的主键,自增的整数)----offset来标记是否已经处理过。
  • 消费者把每个分区的读取的偏移量offset,保存到zookeeper,或者kafka本身。如果消费者关闭,那么读取的状态不会丢失。
  • 多个消费者会按组划分,但是会保证一个partion只会分给组中特定某一个消费者,以保证分区的顺序性。即一个分区不会分给同一个组内的多个消费者。

12.kafka broker,单个kafka的server被成为brokder

  • brokder接收生产者发送的消息,并且分配offset给这个消息

13.kafka消息保留retention

  • 可以设置保留时间。或者topic保留的容量大小,比如某个topic设置了最大保留数据1GB,一旦超过时间或者容量,消息就会被失效,或者删除。所以任何时刻,kafka的消息总量不会超过配置的大小。
  • 可以为某个topic单独设置过期时间和容量。
  • 还可以设置为log compacted ---紧凑型日志。kafka只会保留最后的一条消息。

14.kafka 多集群

  • kafka 集群 内置了副本机制,保证同一个集群可以互为副本
  • MirrorMaker 用来同步多个集群之间。MirrorMaker的本质包含了一个Producer和Consumer,Consumer从一个集群上读取消息,然后用Producer发送到另一个集群上
  • 多集群的原因有三1.隔离数据类型2.隔离安全级别3多数据中心容灾

15.kafka的使用场景

  • 活动记录----Activity Tracking
  • Messaging----用户通知等,如邮件,格式化消息(装饰)
  • 度量指标和日志记录
  • commit log ----事务的基本使用
  • Stream processing 流处理

16.kafka 安装环境

  • JAVA8,最好安装jdk
  • zookeeper---保存Broker和Topic的metadata,另外老版本中,还保存consumer的offset指针,可以使用srvr命令验证zookeeper安装是否正确
  • zookeeper的群组叫做Ensemble,由于zookeeper使用了一致性协议,所以最好群组内的节点使用奇数个。这样才能少数服从多数。如果有3个节点,允许1个节点失败,如果有5个节点,那么允许2个节点失败

1.JPA包括一下:

  • API
  • MAPPING ----xml 和注解两种方式
  • JPQL ----查询语言

2.mybatis和hibernate的区别

  • hibernate符合jpa规范,传统公司更喜欢,mybatis互联网公司更喜欢,因为mybatis不会带来i性能问题,hibernate不会优化则有行能问题
  • hibernate 更倾向于 以对象为中心,mybatis以数据为中心(面向对象),把sql映射给方法(面向关系)
  • hibernate 使用存储过程不方便,mybatis不存在这个问题。

3.为什么ElasticSearch要在7.X版本去掉type?
4.sql mode 的使用
5.kafka的路由,除了topic

大数据相关的总结,大数据产生的背景,读取速度的增长速度,更不上容量的增长速度。所以需要多个硬盘的读取速度进行叠加。另外一点---寻址速度,跟不上读取速度(这个也是关系数据库不适合做大量数据分析的原因,全局搜索会非常慢,单点搜索和更新是强项。注:hadoop侧重与流读取,即一次读取大块的数据,而不是点寻)
  1. 数据放到多个硬件遇到的问题
  • 多个磁盘的失败率增高,解决方案是副本 replication,如RAID和HDFS
  • 多个硬件的数据如何聚合分析:Map Reduce 提出一个编程模型---把对各个磁盘的读和写,转换为对数据集sets(包含keys和values)的计算。计算分为两部---map 和reduce

2.map reduce 是一个批处理系统,不太适合实时系统,适合offline使用.设计初衷是对整个数据,或者很大一部分数据进行处理。

3.Hadoop设计初衷并不仅仅是批处理,hadoop现在被认为一个更大的,多个项目组成的生态系统,包括

  • hadoop支持非结构化数据,即没有固定存储格式的数据,如图片,原始文本,plain text,mysql强调非冗余(第二范式)。而hadoop 恰好相反,冗余更利于map reduce的统计和分析。
  • map reduce 保证了线性伸缩,即随着数据的增大,算法时间也会同比增大。我们只需要扩充同比的集群就能达到相应的速度。
  • hbase数据库,键值对存储,底层用的hDFS
  • yarn---集群资源管理系统
  • hive---交互式sql,分布式查询引擎。去掉了map reduce,使用索引和事务特性
  • spark---好多算法具有迭代性,而map reduce不允许迭代的获取数据。。spark探索了这种风格处理,每次保存中间结果在内存。
  • spark stream/storm ,实时无边界的流Stream处理。
  • solr 在hdfs上索引和查询。

4.大数据计算方法

  • HPC高性能计算和Grid计算,分散(distribute)work到cluster的各个机器,cluster的机器使用SAN(storage area network)共享文件系统----适合计算密集型,但是不适合数据较大(几百GB)的计算,因为网络network也是一种昂贵的资源,很多计算节点因为等待数据而闲下来
  • hadoop 数据本地化---核心,即在计算节点上存储数据

5.Map Reduce 计算流程

  • map计算本地话,block分块不大于128M,按当前HDFS设置的分区块大小---实现本地化计算
  • map输入结果本地化,不会存储到HDFS系统
  • map的计算结果传递给多个reducer时,一个会按key进行分区(分区方法一般用hash,默认的。备注:让我想起了kafka的路由方法是----Round-ribon和hash,传递到不同的分区。原理差不多),同一个分区交给同一个reducer进行计算---这个分区传给ruceer的过程一般成为shuffle(混洗)。
  • 注意shuffle后有一个merge的过程,但是也有的结果可以完全并行,即,无需shuffle时,没有reduce这一步,直接将结果存放到HDFS
  • Reduce的结果会存放到HDFS中,即先存本地,然后存副本到其他节点
  • Map的输出,可以指定一个Combiner。Combiner做了处理后,再传递给Reducer。从而优化网络传输。
  • 可以把combiner看成一个本地化的reducer

6.Hadoop Streaming

  • 在java api中,每个reducer会被分配给一个keygroup,即shuffle后在同一个key中。而ruby中需要自己处理边界,key是排好序的。

7.HDFS设计

  • 文件比较大,GB,ZB级别
  • 流式数据访问,一次读取全部/或者大部分的数据的速度,而不是第一次读到数据的速度。
  • 普通商用硬盘支持,允许故障的发生

8.不适合HDFS的场景

  • 低延迟的数据访问,毫秒级别,请选择HBASE
  • 大量的小文件,HDFS的nameNode存储于内存中。大量的小文件ke导致namenode内存不够用
  • 多用户写入,任意修改文件----HDFS只支持单个用户写入,而且总是在文件末尾写入,即append only。也不支持,在文件的任意位置修改

9.HDFS的概念

  • Blocks数据块,128M,大数据快,减少seek的时间
  • 分块的好处1:一个大文件可能比磁盘还大,那么可以切成Block分布到不同的磁盘。
  • 好处2:抽象为Block,比File更加简化了存储子系统的设计。块的权限,可以单独管理。不需要存储到子系统
  • 提高了容错性。每个块会把副本到别的磁盘,一般是3个,如果一个不可用,那么系统会切换到另一个磁盘读取。甚至有的系统会提高副本的个数来应对读取的负载。
  • NameNode 和DataNode
  • HDFS 以管理节点(master---NameNode)和数据节点(workers节点----DataNode)运行
  • NameNode 管理文件系统的命名空间----管理整个文件系统树和树内的文件和目录。这些信息有两种文件格式format就----namespace image 和edit log。
  • namenode还记录每个文件的各个块的数据节点信息,但不是永久,每次系统重启会重建。
  • 客户端代表用户访问clientNode和NameNode。并提供一个类似POSIX的文件系统接口
  • datanode是文件系统的工作节点,存储和获取blocks(受namenode和client控制)。并且定期向nameNode发送他们存储的节点
  • 没有NameNode,文件系统无法工作。如果NameNode损坏,整个文件系统将丢失。那么Hadoop提供两种机制保证
  • 备份组成文件系统元数据的文件。一般是:写入本地的同时,写入远程的一个NFS
  • 另一种,运行一个辅助的Secondary NameNode,定期合并edit log 到 namespace image,防止editlog过大。一般secodnary namenode 会放到一个单独的物理机上,因为他CPU和内存占用比较多。但是secondary namenode 有延迟(所以一旦NanmeNode 失效,就会丢失数据)常用的做法是结合copy NFS上的数据。
  • Blocking cache块缓存
  • 经常读取的文件,会缓存到datanode的内存,off heap block cache
  • 一个快只会缓存到一个datanode的内存中
  • HDFS Federation 联邦HDFS
  • Namenode 的集群版,因为NameNode在内存中存储block的元信息。但是内存会是一个限制。随意出现了Federation版。
  • 每个NameNode维护一个命名空间卷----包含一个元数据和一个数据快池组成。client使用文件路径挂name nodes

  1. IO,每个Process 有三个Stream,STD_ID,STD_OUT,STD_ERRO

2.TCP/IP 四层网络模型

  • 应用层 如telnet,ftp ,email
  • 运输层 如TCP UDP
  • 网络层 IP ICMP IGMP,
  • 链路层 设备驱动程序及接口卡,操作系统中的设备驱动程序,计算机中对应的网络接口卡

1.什么是Consistent Hashing

  • 一致性hash,使用hash(job)生成2的32次方的int,然后落到最近的hash环,计算机会虚拟出来几个vnode,均匀分布到hash环。

2.分布式architeture---空间---时间解偶(如邮件,两个人发送邮件不需要同时在发送接收,如qq的发送文件就需要点接收),三层OSI7层
3.p2p ,dns---非结构够点对点。cdn--cs+p2p
3.中间件----所有application的general通用部分,可以用于解决遗留系统问题---如拦截器interceptor

  1. client ----switch 然后直接和server交流,---称之为tcp hand off

5.上下文切换,包括---cpu上下文,线程上下文,进程上下文

  1. out of bind communication ,超界呼叫,有点类似cpu的中断,提供专门的端口来紧急处理紧急的事情。
  2. 代码管理code migration
  • cs模式,client server,代码状态和代码文件都在服务端
  • REV
  • CoD
  • MA

8.系统资源管理的3中方式---by identifier,by value ,by type
9.osi七层--概括

  • 硬件层----》物理层(bit级别的交换)---数据链路层(建立帧frame级别的传输,错误和flow控制)
  • 软件层----》网络层(包packet的路由,注意好多分布式系统把这个作为最低层)----传输层(分布式系统的交流基础设施,TCP,UDP,IP广播)
  • 事务层----》Session会话,如:两阶段提交----(和表示层合成---中间件middleware层)
    ++ midleware layer---提供了common的协议protocol和服务services ,给many应用applications使用
    +++ 提供---

    ++++a set ofcommunication protocols,
    ++++(un)marshaling of datafor integerated systems
    ++++security protocols
    ++++naming protocols----easy sharing resources如zookeeper 使用文件路径来命令services
    ++++scaling mechanisms,like replication and cashing.
  • 表示层----》表示层-----RPC调用,使用相同的格式,client server 用同一种语言说话,如json xml
  • 应用层

---------------------------------------系统交流communication---------------------
10.系统交流类型 communication types,使用中间件,如kafka

  • 同步,发送请求,等待返回
  • 异步,发送请求,等待回调(利用transmision interrupt传输中断)

-----以上是双向交流,下面是单向交流

  • 只管发送,不等返回和回调。如UDP

11.RPC远程过程调用,

  • 需要解决调用远程交流透明性,PC是一种机制,可以隐藏caller和callee的communication
  • 需要解决消息传递marshaling,machine independent,client server agree on same encoding
  • 需要关注传参问题,a.传递指针(指向一个global data)还是value,b.还有一种方式copy in /out 没有副作用

12.socket

  • socket 创建一个端点endpoint
  • bind 附加一个本地地址给socket
  • listen 告诉系统需要足够的buffer来接收客户端请求
  • accept 等待一个连接
  • connect 客户端发起三次握手,和accept对应
  • send/receive ---当作文件操作
  • close

13.中间件---queue (对比socket,时间解偶异步化)

  • 异步持久化交流
  • PUT append 一个message到指定队列
  • GET 线程阻塞,一直等到队列非空,获取并删除地一个message
  • POLL 检查队列,删除第一个msg,但是不阻塞
  • NOTIFY 加装一个处理器handler,当消息被PUT时调用。

14.消息代理 message broker ----对比queue,空间的解偶,不再是点到点,而是全部发送给broker,相当与中间商

  • 消息队列假定一个通用协议protocal,message broker是一个中心化组件,允许异构系统在同一个消息系统中。
  • 转化消息到固定的目标格式 target format
  • 经常充当application gateway的角色
  • 用topic进行路由
  • 一般用来拯救遗留系统application的交流
  1. 面向流Stream的交流
  • 之前讨论的交流是一种非连续的,即时间无关的time-independent信息交流(exchange),而流是一种时间有关的time dependent,如连续媒体continous media---audio video animations ,那么Stream就是一个面向连接的设施---支持等时数据传输isochronous data transmission,如视频,音乐audio
  • 流一般是不定向的undirectional
  • 一般是一个源source 流向多个槽 sinks
  1. 广播

------------------------------------------Naming命名--------------------------

  1. 分布式需要命名一个计算机或者其他端点进行访问,如dns,如一些注册中心,feign访问服务也是通过application name访问
  • naming
  • identifier ---无意义的符号,随机字符,一对一,如身份证号
  • flat naming ,如arp使用的名字,DHT---一致性hash,fingers tables,hirecal location service 层次化
  • 上面都是非结构化的,那么不适合人类阅读,结构化的,如name space(java程序员应该很熟悉)
  • 基于attribute的命名---如ldap

------------------------同步 sychronisation-------------------
物理时钟----网络时钟
逻辑时钟---happens before ---并行
------------------------consistency & replication

  1. 复制的原因----可靠性和性能
  • 操作冲突----读和写
  • 操作冲突----写和写
  • 全局顺序保证的操作冲突,成本会很高,我们采取稍微弱点的一致性要求

--------------------- 宽松的一致性模型------数据中心--------------------

  1. 数据中心一致性模型
  • 基本模型约定----读操作读的值一定是最后一次写操作的值,但是在没有全局时钟的情况下,怎么确定哪一次写是最后一次写是个难题,所以催生了多种一致性模型。
  1. 持续一致性continous consistency
  • Yu and Vahdat (2002) 提出的度量不一致性的三个坐标轴:
  • 副本之间值偏差--numeric value differ between replicas,如:同一支股票的值差不能超过0.02美元
  • 副本之间的新旧程度偏差----relative staleness differ,如天气预报允许时间上的偏差
  • 副本之间更新顺序的偏差,ordering of update operations,可以用向量时钟保证vector clock
  1. 顺序一致性sequential consistency
  • 所有process的计算结果都是一致的,如果他们的操作顺序都是按一个顺序(Program指定)来的

6.因果一致性 causal consistency

  • lamport提出的,如果一个操作B是由另一个操作A引起的,那么我们应当保证他们的顺序性。如通过logic clock
  1. 分组操作---如java的sychronized 把一组操作分组加锁,又如innodb的按行锁,其他操作可以不一致(顺序),但是这个同一行必须一致,还有redis对同一个key的写。

--------------------- 宽松的一致性模型------client中心一致性模型--------------------

我们讨论这个基于这种系统-----很少发生同时更新同一个数据,或者发生了也很好解决。
  • 最终一致性eventualy consitency,现代好多数据库系统中,大部分进程是读操作,很少部分有写的操作。如DNS,只有供应商可以更改,所以不会有写写冲突,只会有读写冲突,这种允许懒惰传播,即更改一段时间后,用户才看到变化。即在一段时间内,允许副本有不一致性。
  • 单调读 ----
  • 单调写 monotoic
  • read your writes
  • write follow read

--------------------- 宽松的一致性模型------replica(集群) 管理--------------------

  • 副本放置

----------------------------------异地多活-------------------------
http://afghl.github.io/2018/02/11/distributed-system-multi-datacenter-1.html