首页 » 面试

1.mysql 的隔离级别和锁

  • mysql 的锁分为共享锁(又叫S锁)和拍他锁(又叫X锁),S锁----允许多个事务并发的读取同一个资源,互补干扰。X锁----事务T加上排他锁后,其他事务不能再加任何锁。
  • read uncommit ---没有锁,所以会出现脏读
  • read commit ----共享锁,允许读,但是不允许写。---会出现,不可重复读(一个事务范围内,多次读取的结果不一样)
  • 可重复读--- X锁,读写都不允许,保证了可重复读。但是不能保证幻读,mysql引入了mvcc来解决这个问题。

2.Spring bean的生命周期

  • instantiation ---实例化
  • properties injection ---属性注入
  • setBeanName ---of bean name Aware接口的实现调用
  • setBeanClassLoader----BeanClassLoaderAare接口的方法
  • setBeanFactory ----BeanFactoryAware接口
  • PostProcessBeforeInitialization-----BeanPostProcessor接口
  • afterPropertiesSet-----InitializingBean 接口
  • 自定义的init-method----在spring xml中
  • postProcessAfterInitilazation ---BeanPostProcessor接口
  • destroy----DisposableBean 接口
  • 自定义的destroy method

3.设计一个抢红包系统

4.分布式锁的公平竞争、线程锁的公平竞争

  • 大多是通过单机,或者单线程里面的锁或者时钟顺序性来保证。
  • zookeeper在一个指定节点的lockpath下创建临时会话顺序节点(类似于mysql的自增)。谁创建的节点序号小,谁有限获得锁。其他节点都会监听比自己小的节点,在监听事件中判断自己是否最小,从而获得锁
  • redis 通过lua的原子性脚本,保证setnx+pexpire的执行原子性(防止没有expire,其他获取锁的机器渴死),类似与MULTI / EXEC 和单线程来保证事务,其实利用了单线程带来的隔离性,串行化,不被打断。不算严格的原子性
  • mysql的唯一键保证,其他线程不能插入
  • 线程的公平竞争,使用队列,公平不允许插队,非公平允许插队。见问题8

5.线程wait和sleep的区别
6.dubbo自定义注解的实现

  • 调用端---- 实现spring提供的NamespaceHandler 接口,向Spring 容器注册 BeanDifinationParser,通过parser转换相关的xml到Spring 的bean
  • 服务端----- Service Bean,dubbo服务提供者都实现 dubbo:service,Spring把 dubbo:service 解析成一个ServiceBean,ServiceBean实现了ApplicationListener和InitializingBean接口,afertPorpertiesSet中调用export方法暴露这些服务方法。即注册到provider的map里面

7.类的加载
8.ReentrantLock 机制,公平和非公平

9.DDD理解,战略,战术

  • 首先领域---就是问题域,即我们要研究的问题边界,不要把所有问题放到一起,我们的问题有自己的边界,是为领域。首先我们系统要做成什么样,然后对问题进行拆分,划分边界,成为领域。比如一个电商可以接拆为---会员中心,商品中心,订单中心,交易中心,库存中心,营销促销中心。但是领域划分有时候会产生领域复杂问题,比如商品中心,有商品和库存,那么随着维护困难,可以再次拆分子领域,也就是我们常说的垂直切分。会员包括用户和账户,也可以垂直切分。
  • 按功能可以分为核心域(赚钱的)、通用域、支撑域
  • 战略是对系统整体的规划,划分,DDD的战略设计主要包括领域/子域、通用语言、限界上下文和架构风格等概念。
  • 战术是设计模式,领域对象,entity,值对象。聚合。Domain Service,Repository,Domain Event

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,
  • 链路层 设备驱动程序及接口卡,操作系统中的设备驱动程序,计算机中对应的网络接口卡