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.设计一个抢红包系统
• 用redis + lua https://www.jianshu.com/p/b58ed2fe6976?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation
• 原理：生成一个正太分布的红包值，比如100元，生成10个包。然后利用redis+lua的原子性，把hongbaoList（-1操作）,hongbaoConsumedList（+1操作）,hongbaoConsumedMap（去重操作）放在一起执行。 注意jedis是和某太机器建立会话，发送lua脚本，采用用redis单线程来保证原子性和抢红包的单线程竞争。
  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可以存储和定期处理大量的数据文件
• 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，
• 链路层 设备驱动程序及接口卡，操作系统中的设备驱动程序，计算机中对应的网络接口卡