30.ISR、OSR、AR 是什么？
ISR：In-Sync Replicas 副本同步队列
OSR：Out-of-Sync Replicas
AR：Assigned Replicas 所有副本
ISR是由leader维护，follower从leader同步数据有一些延迟（具体可以参见 图文了解 Kafka 的副本复制机制），超过相应的阈值会把 follower 剔除出 ISR, 存入OSR（Out-of-Sync Replicas ）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。
31.LEO、HW、LSO、LW等分别代表什么
LEO：是 LogEndOffset 的简称，代表当前日志文件中下一条
HW：水位或水印（watermark）一词，也可称为高水位(high watermark)，通常被用在流式处理领域（比如Apache Flink、Apache Spark等），以表征元素或事件在基于时间层面上的进度。在Kafka中，水位的概念反而与时间无关，而是与位置信息相关。严格来说，它表示的就是位置信息，即位移（offset）。取 partition 对应的 ISR中 最小的 LEO 作为 HW，consumer 最多只能消费到 HW 所在的位置上一条信息。
LSO：是 LastStableOffset 的简称，对未完成的事务而言，LSO 的值等于事务中第一条消息的位置(firstUnstableOffset)，对已完成的事务而言，它的值同 HW 相同
LW：Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值。
32.Kafka 在什么情况下会出现消息丢失？
参考数据可靠性和数据一致性
33.怎么尽可能保证 Kafka 的可靠性
参考数据可靠性和数据一致性
34.消费者和消费者组有什么关系？
每个消费者从属于消费组。具体关系如下：
35.Kafka 的每个分区只能被一个消费者线程，如何做到多个线程同时消费一个分区？
36.数据传输的事务有几种？
数据传输的事务定义通常有以下三种级别：
最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输
最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输.
精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被
37.Kafka 消费者是否可以消费指定分区消息？
Kafa consumer消费消息时，向broker发出fetch请求去消费特定分区的消息，consumer指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer拥有了offset的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的
38.Kafka消息是采用Pull模式，还是Push模式？
Kafka最初考虑的问题是，customer应该从brokes拉取消息还是brokers将消息推送到consumer，也就是pull还push。在这方面，Kafka遵循了一种大部分消息系统共同的传统的设计：producer将消息推送到broker，consumer从broker拉取消息。
一些消息系统比如Scribe和Apache Flume采用了push模式，将消息推送到下游的consumer。这样做有好处也有坏处：由broker决定消息推送的速率，对于不同消费速率的consumer就不太好处理了。消息系统都致力于让consumer以最大的速率最快速的消费消息，但不幸的是，push模式下，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式。Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull模式下，consumer就可以根据自己的消费能力去决定这些策略。Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到t达。为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发
39.Kafka 消息格式的演变清楚吗？
Kafka 的消息格式经过了四次大变化，
0.8.x版本的消息格式如下：
这个版本的 Message 格式加入了 Key 相关的信息，以及 内容的长度等，各个字段的含义介绍如下：
crc：占用4个字节，主要用于校验消息的内容；
magic：这个占用1个字节，主要用于标识 Kafka 版本。
attributes：占用1个字节，这里面存储了消息压缩使用的编码。这个版本的 Kafka 仅支持 gzip、snappy 以及 lz4（0.8.2引入） 三种压缩格式；后四位如果是0001则标识gzip压缩，如果是0010则是snappy压缩，如果是0011则是snappy压缩，如果是0000则表示没有使用压缩。
key length：占用4个字节。主要标识 Key 的内容的长度 K；
key：占用 K 个字节。存储的是 key 的具体内容
value length：占用4个字节。主要标识 value 的内容的长度 V；
value：这个占用的字节为 V。value即是消息的真实内容，在 Kafka 中这个也叫做payload。
这个版本的MessageSet 格式和之前一样，就不介绍了。但是需要注意的是，这个版本 MessageSet 中的 offset 字段存储的已经不是消息物理偏移量了，而是逻辑地址，比如0,、1、2....。有了逻辑地址，我们就可以解决之前Kafka 0.7.0遇到的一些问题，比如可以在压缩消息内通过偏移量进行寻址，压缩消息可以checkpoint内部的消息等。
0.10.x版本的消息格式如下：
可以看出，这个版本相对于 Kafka 0.8.x版本的消息格式变化不大，各个字段的含义：这个版本的 Message 格式加入了 Key 相关的信息，以及 内容的长度等，各个字段的含义介绍如下：
crc：占用4个字节，主要用于校验消息的内容；
magic：这个占用1个字节，主要用于标识 Kafka 版本。Kafka 0.10.x magic默认值为1
attributes：占用1个字节，这里面存储了消息压缩使用的编码以及Timestamp类型。这个版本的 Kafka 仅支持 gzip、snappy 以及 lz4（0.8.2引入） 三种压缩格式；后四位如果是 0001 则表示 gzip 压缩，如果是 0010 则是 snappy 压缩，如果是 0011 则是 lz4 压缩，如果是0000则表示没有使用压缩。第4个bit位如果为0，代表使用create time；如果为1代表append time；其余位（第5~8位）保留；
key length：占用4个字节。主要标识 Key 的内容的长度 K；
key：占用 K 个字节。存储的是 key 的具体内容
value length：占用4个字节。主要标识 value 的内容的长度 V；
value：这个占用的字节为 V。value即是消息的真实内容，在 Kafka 中这个也叫做payload。
40.Kafka 偏移量的演变清楚吗？
参见官方文档，此问题很少问
41.Kafka 高效文件存储设计特点
Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。
通过索引信息可以快速定位message和确定response的最大大小。
通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作。
通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小
42.Kafka创建Topic时如何将分区放置到不同的Broker中
副本因子不能大于 Broker 的个数；
第一个分区（编号为0）的第一个副本放置位置是随机从 brokerList 选择的；
其他分区的第一个副本放置位置相对于第0个分区依次往后移。也就是如果我们有5个 Broker，5个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，依次类推；
剩余的副本相对于第一个副本放置位置其实是由 nextReplicaShift 决定的，而这个数也是随机产生的；
具体可以参见Kafka创建Topic时如何将分区放置到不同的Broker中。
43.Kafka新建的分区会在哪个目录下创建
我们知道，在启动 Kafka 集群之前，我们需要配置好 log.dirs 参数，其值是 Kafka 数据的存放目录，这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘上用于提高读写性能。当然我们也可以配置 log.dir 参数，含义一样。只需要设置其中一个即可。
如果 log.dirs 参数只配置了一个目录，那么分配到各个 Broker 上的分区肯定只能在这个目录下创建文件夹用于存放数据。
但是如果 log.dirs 参数配置了多个目录，那么 Kafka 会在哪个文件夹中创建分区目录呢？答案是：Kafka 会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为 Topic名+分区ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就是说，如果你给 log.dirs 参数新增了一个新的磁盘，新的分区目录肯定是先在这个新的磁盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。
44.谈一谈 Kafka 的再均衡
在Kafka中，当有新消费者加入或者订阅的topic数发生变化时，会触发Rebalance(再均衡：在同一个消费者组当中，分区的所有权从一个消费者转移到另外一个消费者)机制，Rebalance顾名思义就是重新均衡消费者消费。Rebalance的过程如下：
第一步：所有成员都向coordinator发送请求，请求入组。一旦所有成员都发送了请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader。第二步：leader开始分配消费方案，指明具体哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案发给coordinator。coordinator接收到分配方案之后会把方案发给各个consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。所以对于Rebalance来说，Coordinator起着至关重要的作用
45.谈谈 Kafka 分区分配策略
每个 Topic 一般会有很多个 partitions。为了使得我们能够及时消费消息，我们也可能会启动多个 Consumer 去消费，而每个 Consumer 又会启动一个或多个streams去分别消费 Topic 对应分区中的数据。我们又知道，Kafka 存在 Consumer Group 的概念，也就是group.id
一样的 Consumer，这些 Consumer 属于同一个Consumer Group，组内的所有消费者协调在一起来消费订阅主题(subscribed topics)的所有分区(partition)。当然，每个分区只能由同一个消费组内的一个consumer来消费。那么问题来了，同一个 Consumer Group 里面的 Consumer 是如何知道该消费哪些分区里面的数据呢？
如上图，Consumer1 为啥消费的是 Partition0 和 Partition2，而不是 Partition0 和 Partition3？这就涉及到 Kafka内部分区分配策略（Partition Assignment Strategy）了。
在 Kafka 内部存在两种默认的分区分配策略：Range 和 RoundRobin。当以下事件发生时，Kafka 将会进行一次分区分配：
同一个 Consumer Group 内新增消费者
消费者离开当前所属的Consumer Group，包括shuts down 或 crashes
订阅的主题新增分区
将分区的所有权从一个消费者移到另一个消费者称为重新平衡（rebalance），如何rebalance就涉及到本文提到的分区分配策略。下面我们将详细介绍 Kafka 内置的两种分区分配策略。本文假设我们有个名为 T1 的主题，其包含了10个分区，然后我们有两个消费者（C1，C2）来消费这10个分区里面的数据，而且 C1 的 num.streams = 1，C2 的 num.streams = 2。
Range strategy
Range策略是对每个主题而言的，首先对同一个主题里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。在我们的例子里面，排完序的分区将会是0, 1, 2, 3, 4, 5, 6, 7, 8, 9；消费者线程排完序将会是C1-0, C2-0, C2-1。然后将partitions的个数除于消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。在我们的例子里面，我们有10个分区，3个消费者线程， 10 3 = 3，而且除不尽，那么消费者线程 C1-0 将会多消费一个分区，所以最后分区分配的结果看起来是这样的：
C1-0 将消费 0, 1, 2, 3 分区C2-0 将消费 4, 5, 6 分区C2-1 将消费 7, 8, 9 分区
假如我们有11个分区，那么最后分区分配的结果看起来是这样的：
C1-0 将消费 0, 1, 2, 3 分区C2-0 将消费 4, 5, 6, 7 分区C2-1 将消费 8, 9, 10 分区
假如我们有2个主题(T1和T2)，分别有10个分区，那么最后分区分配的结果看起来是这样的：
C1-0 将消费 T1主题的 0, 1, 2, 3 分区以及 T2主题的 0, 1, 2, 3分区C2-0 将消费 T1主题的 4, 5, 6 分区以及 T2主题的 4, 5, 6分区C2-1 将消费 T1主题的 7, 8, 9 分区以及 T2主题的 7, 8, 9分区
可以看出，C1-0 消费者线程比其他消费者线程多消费了2个分区，这就是Range strategy的一个很明显的弊端。
RoundRobin strategy
使用RoundRobin策略有两个前提条件必须满足：
同一个Consumer Group里面的所有消费者的num.streams必须相等；
每个消费者订阅的主题必须相同。
所以这里假设前面提到的2个消费者的num.streams = 2。RoundRobin策略的工作原理：将所有主题的分区组成 TopicAndPartition 列表，然后对 TopicAndPartition 列表按照 hashCode 进行排序，这里文字可能说不清，看下面的代码应该会明白：
val allTopicPartitions = ctx.partitionsForTopic.flatMap {case(topic, partitions) =>
info("Consumer %s rebalancing the following partitions for topic %s: %s"
.format(ctx.consumerId, topic, partitions))
partitions.map(partition => {
TopicAndPartition(topic, partition)
})
}.toSeq.sortWith((topicPartition1, topicPartition2) => {
/*
* Randomize the order by taking the hashcode to reduce the likelihood of all partitions of a given topic ending
* up on one consumer (if it has a high enough stream count).
*/
topicPartition1.toString.hashCode < topicPartition2.toString.hashCode
})
最后按照round-robin风格将分区分别分配给不同的消费者线程。
在我们的例子里面，假如按照 hashCode 排序完的topic-partitions组依次为T1-5, T1-3, T1-0, T1-8, T1-2, T1-1, T1-4, T1-7, T1-6, T1-9，我们的消费者线程排序为C1-0, C1-1, C2-0, C2-1，最后分区分配的结果为：
C1-0 将消费 T1-5, T1-2, T1-6 分区；C1-1 将消费 T1-3, T1-1, T1-9 分区；C2-0 将消费 T1-0, T1-4 分区；C2-1 将消费 T1-8, T1-7 分区；
多个主题的分区分配和单个主题类似，这里就不在介绍了。
根据上面的详细介绍相信大家已经对Kafka的分区分配策略原理很清楚了。不过遗憾的是，目前我们还不能自定义分区分配策略，只能通过partition.assignment.strategy参数选择 range 或 roundrobin。partition.assignment.strategy参数默认的值是range。
46.Kafka Producer 是如何动态感知主题分区数变化的？
47.Kafka 是如何实现高吞吐率的？
Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失。kafka主要使用了以下几个方式实现了超高的吞吐率：
顺序读写；
零拷贝
文件分段
批量发送
数据压缩。
48.Kafka 监控都有哪些？
比较流行的监控工具有：
KafkaOffsetMonitor
KafkaManager
Kafka Web Console
Kafka Eagle
JMX协议（可以用诸如jdk自带的jconsole来进行连接获取状态信息）
49.如何为Kafka集群选择合适的Topics/Partitions数量
参见《如何为Kafka集群选择合适的Topics/Partitions数量》
50.谈谈你对 Kafka 事务的了解？
参见这篇文章：http://www.jasongj.com/kafka/transaction/
51.谈谈你对 Kafka 幂等的了解？
参见这篇文章：https://www.jianshu.com/p/b1599f46229b
52.Kafka 缺点？
由于是批量发送，数据并非真正的实时；
对于mqtt协议不支持；
不支持物联网传感数据直接接入；
仅支持统一分区内消息有序，无法实现全局消息有序；
监控不完善，需要安装插件；
依赖zookeeper进行元数据管理；
53.Kafka 新旧消费者的区别
旧的 Kafka 消费者 API 主要包括：SimpleConsumer（简单消费者） 和 ZookeeperConsumerConnectir（高级消费者）。SimpleConsumer 名字看起来是简单消费者，但是其实用起来很不简单，可以使用它从特定的分区和偏移量开始读取消息。高级消费者和现在新的消费者有点像，有消费者群组，有分区再均衡，不过它使用 ZK 来管理消费者群组，并不具备偏移量和再均衡的可操控性。
现在的消费者同时支持以上两种行为，所以为啥还用旧消费者 API 呢？
54.Kafka 分区数可以增加或减少吗？为什么？
我们可以使用 bin/kafka-topics.sh 命令对 Kafka 增加 Kafka 的分区数据，但是 Kafka 不支持减少分区数。Kafka 分区数据不支持减少是由很多原因的，比如减少的分区其数据放到哪里去？是删除，还是保留？删除的话，那么这些没消费的消息不就丢了。如果保留这些消息如何放到其他分区里面？追加到其他分区后面的话那么就破坏了 Kafka 单个分区的有序性。如果要保证删除分区数据插入到其他分区保证有序性，那么实现起来逻辑就会非常复杂。
55.kafka消息的存储机制
kafka通过 topic来分主题存放数据，主题内有分区，分区可以有多个副本，分区的内部还细分为若干个 segment。都是持久化到磁盘，采用零拷贝技术。
1、高效检索
分区下面，会进行分段操作，每个分段都会有对应的素引，这样就可以根据 offset二分查找定位到消息在哪一段，根据段的索引文件，定位具体的 mle ssage
2、分区副本可用性(1 eader选举，zk来协调
如果1eader宕机，选出了新的1eader，而新的 leader并不能保证已经完全同步了之前1eader的所有数据，只能保证HW(高水位设置)之前的数据是同步过的，此时所有的 follower都要将数据截断到W的位置，再和新的 leader同步数据，来保证数据一致。
当宕机的 leader恢复，发现新的1eader中的数据和自己持有的数据不一致，此时宕机的1 eader会将自己的数据截断到宕机之前的hw位置，然后同步新1 eader的数据。宕机的1eader活过来也像 follower一样同步数据，来保证数据的一致性。
56.相比较于传统消息队列，kafka的区别
1、分区性:存储不会受单一服务器存储空间的限制
2、高可用性:副本1 eader选举
3、消息有序性:一个分区内是有序的。
4、负载均衡性:分区内的一条消息，只会被消费组中的一个消费者消费，主题中的消息，会均衡的发送给消费者组中的所有消费者进行消费。
57.消息丢失和消息重复
同步:这个生产者写一条消息的时候，它就立马发送到某个分区去。
异步:这个生产者写一条消息的时候，先是写到某个缓冲区，这个缓冲区里的数据还没写到 broker集群里的某个分区的时候，它就返回到 client去了
针对消息丢失:同步模式下，确认机制设置为-1，即让消息写入 Leader和 Fol lower之后再确认消息发送成功:
异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态
针对消息重复，将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可
五.Hbase
1.Hbase调优
高可用
在HBase中Hmaster负责监控RegionServer的生命周期，均衡RegionServer的负载，如果Hmaster挂掉了，那么整个HBase集群将陷入不健康的状态，并且此时的工作状态并不会维持太久。所以HBase支持对Hmaster的高可用配置。
预分区
每一个region维护着startRow与endRowKey，如果加入的数据符合某个region维护的rowKey范围，则该数据交给这个region 维护。那么依照这个原则，我们可以将数据所要投放的分区提前大致的规划好，以提高HBase性能。
优化RowKey设计
一条数据的唯一标识就是rowkey，那么这条数据存储于哪个分区，取决于rowkey处于哪个一个预分区的区间内，设计rowkey 的主要目的 ，就是让数据均匀的分布于所有的region中，在一定程度上防止数据倾斜
内存优化
HBase操作过程中需要大量的内存开销，毕竟Table是可以缓存在内存中的，一般会分配整个可用内存的70%给HBase的Java堆。但是不建议分配非常大的堆内存，因为GC过程持续太久会导致RegionServer处于长期不可用状态，一般16~48G内存就可以了，如果因为框架占用内存过高导致系统内存不足，框架一样会被系统服务拖死。
2.hbase的rowkey怎么创建好？列族怎么创建比较好？
hbase存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)
一个列族在数据底层是一个文件，所以将经常一起查询的列放到一个列族中，列族尽量少，减少文件的寻址时间。
设计原则
1）rowkey 长度原则
2）rowkey 散列原则
3）rowkey 唯一原则
如何设计
1）生成随机数、hash、散列值
2）字符串反转
3) 字符串拼接
3.hbase过滤器实现用途
增强hbase查询数据的功能
减少服务端返回给客户端的数据量
4.HBase宕机如何处理
答：宕机分为HMaster宕机和HRegisoner宕机，如果是HRegisoner宕机，HMaster会将其所管理的region重新分布到其他活动的RegionServer上，由于数据和日志都持久在HDFS中，该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。
如果是HMaster宕机，HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行。即ZooKeeper会保证总会有一个HMaster在对外提供服务。
5.hive跟hbase的区别是？
共同点：
1.hbase与hive都是架构在hadoop之上的。都是用hadoop作为底层存储
区别：
2.Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。
3.想象你在操作RMDB数据库，如果是全表扫描，就用Hive+Hadoop,如果是索引访问，就用HBase+Hadoop 。
4.Hive query就是MapReduce jobs可以从5分钟到数小时不止，HBase是非常高效的，肯定比Hive高效的多。
5.Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑。
6.hive借用hadoop的MapReduce来完成一些hive中的命令的执行
7.hbase是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作。
8.hbase是列存储。
9.hdfs作为底层存储，hdfs是存放文件的系统，而Hbase负责组织文件。
10.hive需要用到hdfs存储文件，需要用到MapReduce计算框架。
6.hbase写流程
1/ 客户端要连接zookeeper, 从zk的/hbase节点找到hbase:meta表所在的regionserver（host:port）;
2/ regionserver扫描hbase:meta中的每个region的起始行健，对比r000001这条数据在那个region的范围内；
3/ 从对应的 info:server key中存储了region是有哪个regionserver(host:port)在负责的；
4/ 客户端直接请求对应的regionserver；
5/ regionserver接收到客户端发来的请求之后，就会将数据写入到region中
7.hbase读流程
1/ 首先Client连接zookeeper, 找到hbase:meta表所在的regionserver;
2/ 请求对应的regionserver，扫描hbase:meta表，根据namespace、表名和rowkey在meta表中找到r00001所在的region是由那个regionserver负责的；
3/找到这个region对应的regionserver
4/ regionserver收到了请求之后，扫描对应的region返回数据到Client
(先从MemStore找数据，如果没有，再到BlockCache里面读；BlockCache还没有，再到StoreFile上读(为了读取的效率)；
如果是从StoreFile里面读取的数据，不是直接返回给客户端，而是先写入BlockCache，再返回给客户端。)
8.hbase数据flush过程
1）当MemStore数据达到阈值（默认是128M，老版本是64M），将数据刷到硬盘，将内存中的数据删除，同时删除HLog中的历史数据；
2）并将数据存储到HDFS中；
3）在HLog中做标记点。
9.数据合并过程
当数据块达到4块，hmaster将数据块加载到本地，进行合并
当合并的数据超过256M，进行拆分，将拆分后的region分配给不同的hregionserver管理
当hregionser宕机后，将hregionserver上的hlog拆分，然后分配给不同的hregionserver加载，修改.META.
注意：hlog会同步到hdfs
10.Hmaster和Hgionserver职责
Hmaster
1、管理用户对Table的增、删、改、查操作；
2、记录region在哪台Hregion server上
3、在Region Split后，负责新Region的分配；
4、新机器加入时，管理HRegion Server的负载均衡，调整Region分布
5、在HRegion Server宕机后，负责失效HRegion Server 上的Regions迁移。
Hgionserver
HRegion Server主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBASE中最核心的模块。
HRegion Server管理了很多table的分区，也就是region。
11.HBase列族和region的关系？
HBase有多个RegionServer，每个RegionServer里有多个Region，一个Region中存放着若干行的行键以及所对应的数据，一个列族是一个文件夹，如果经常要搜索整个一条数据，列族越少越好，如果只有一部分的数据需要经常被搜索，那么将经常搜索的建立一个列族，其他不常搜索的建立列族检索较快。
12.请简述Hbase的物理模型是什么
13.请问如果使用Hbase做即席查询，如何设计二级索引
14.如何避免读、写HBaes时访问热点问题？
（1）加盐
这里所说的加盐不是密码学中的加盐，而是在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。给多少个前缀？这个数量应该和我们想要分散数据到不同的region的数量一致（类似hive里面的分桶）。
（ 自己理解：即region数量是一个范围，我们给rowkey分配一个随机数，前缀（随机数）的范围是region的数量）
加盐之后的rowkey就会根据随机生成的前缀分散到各个region上，以避免热点。
（2）哈希
哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一个行数据。
（3）反转
第三种防止热点的方法是反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。反转rowkey的例子：以手机号为rowkey，可以将手机号反转后的字符串作为rowkey，从而避免诸如139、158之类的固定号码开头导 致的热点问题。
（4）时间戳反转
一个常见的数据处理问题是快速获取数据的最近版本，使用反转的时间戳作为rowkey的一部分对这个问题十分有用，可以用Long.Max_Value – timestamp追加到key的末尾，例如[key][reverse_timestamp] ,[key] 的最新值可以通过scan [key]获得[key]的第一条记录，因为HBase中rowkey是有序的，第一条记录是最后录入的数据。
（5）尽量减少行和列的大小
在HBase中，value永远和它的key一起传输的。当具体的值在系统间传输时，它的rowkey，列名，时间戳也会一起传输。如果你的rowkey和列名很大，HBase storefiles中的索引（有助于随机访问）会占据HBase分配的大量内存，因为具体的值和它的key很大。可以增加block大小使得storefiles索引再更大的时间间隔增加，或者修改表的模式以减小rowkey和列名的大小。压缩也有助于更大的索引。
（6）其他办法
列族名的长度尽可能小，最好是只有一个字符。冗长的属性名虽然可读性好，但是更短的属性名存储在HBase中会更好。也可以在建表时预估数据规模，预留region数量，例如create ‘myspace:mytable’, SPLITS => [01,02,03,,…99]
15.布隆过滤器在HBASE中的应用
主要提高随机读的性能
16.Hbase是用来干嘛的?什么样的数据会放到hbase
17.Hbase和Hive的区别与适用场景
18.Hbase在建表时的设计原则(注意事项)
1、预分区
Hbase默认建表时有一个 region，这个 region的 rowkey是没有边界的，即没有 startkey和 endkey在数据写入时，所有数据都会写入这个默认的 region，随着数据量的不断增加，会进行 split，分成2个 region在此过程中，会产生两个问题:
1.数据往一个 region写，会有写热点问题。2. region split会消耗宝贵的集群I/0资源。我们可以控制在建表的时候，创建多个空 region，并确定每个 region的 startkey和 endkey，这样只要我们的 rowkey设计能均匀的命中各个 region，就不会存在写热点问题。自然 split的几率也会大大降低。
2、 rowkey设计原则
(1) rowkey长度越短越好。数据的持久化文件 Hfile中是按照 Keyvalue存储的，如果 rowkey过长会极大影响File的存储效率; Memstore将缓存部分数据到内存，如果 rowk-ey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率。
2) rowkey尽量散列。建议将 rowkey的高位作为散列字段，将提高数据均衡分布在每个 Regionserver以实现负载均衡的几率。(哈希、反转等也可以避免热点问题
(3) rowkey保证唯一性。
3、列族设计原则
(1)建表至少指定一个列族，但一般不超过三个，一般一个，因为 flush和 compact是以 region为单位，所以，某个 column family在 flush的时候，它邻近的 column family也会因关联效应被触发f1ush，最终导致系统产生更多的1/0
2)列族名字不宜过长，会冗余存储。
3)不同列族的记录的数量级不易相差太大，比如A，B两个列族，A为100万条，B为100亿条，则A会被分散到多个 region(可能会跨 reglon server)，导致对A的扫描效率低下
19.hbase优化方法
1、减少调整
(1)减少 region分裂
根据你的 Rowkey设计来进行预建分区，减少 region的动态分裂。
2)给HFi1设定合适大小
Hfile是数据底层存储文件，在每个 memstore进行刷新时会生成一 Hfile，当 Hfile增加到一定程度时，会将属于一个 region的HFi1e进行合并，这个步骤会带来开销但不可避免，但是合并后 reglon大小如果大于设定的值，那么 region会进行分裂。为了减少这样的无谓的1/0开销，建议估计项目数据量大小，给 Hfile设定一个合适的值
2、减少启停
Hbase中也存在频繁开启关闭帯来的问题。
(1)关闭 Compaction，在闲时进行手动 Compact ion0因为 Hbase中存在 Minor Compaction和
Ma jor Compaction，合并就是1/0读写，大量的 Hfile进行肯定会带来I/0开销，甚至是1/0风暴所以为了避免这种不受控制的意外发生，建议关闭自动 Compact ion，在闲时进行 compaction o2)当需要写入大量离线数据时建议使用 Bul kloado
3、减少数据量
(1)开启过滤，提高查询速度，可以减少网络102)使用压缩:一般推荐使用 Snappy和LZ0压缩。
4、合理设计(建表注意事项)
分区、 Rowkey设计、列族的设计
20.Hbase中的region server发生故障后的处理方法(zk-->WAL)
Hbase检测宕机是通过 Zookeeper实现的，正常情况下 Regionserver会周期性向 Zookeeper发送心跳，一旦发生宕机，心跳就会停止，超过一定时间( Sessi ontimeout) Zookeeper就会认为 Regionserver宕机离线，并将该消息通知给 Master0一台 Regionserver只有一个Hog文件，然后，将og按照
Region进行分组，切分到每个 regionserver中，因此在回放之前首先需要将og按照 Region进行分组，每个 Region的日志数据放在一起，方便后面按照 Region进行回放。这个分组的过程就称为HLog切分。然后再对 region重新分配，并对其中的Hog进行回放将数据写入 memstore刷写到磁盘，完成最终数据恢复。
六.数仓
1.维表和宽表的考查（主要考察维表的使用及维度退化手法）
维表数据一般根据ods层数据加工生成，在设计宽表的时候，可以适当的用一些维度退化手法，将维度退化到事实表中，减少事实表和维表的关联
2.数仓表命名规范
OneData方法论在XX的实践
3.拉链表的使用场景
你真的了解全量表,增量表及拉链表吗？
4.一亿条数据查的很慢,怎么查快一点
5.有什么维表
时间维表，用户维表，医院维表等
6.数据源都有哪些
业务库数据源:mysql,oracle,mongo
日志数据：ng日志，埋点日志
爬虫数据
7.你们最大的表是什么表,数据量多少
ng日志表，三端(app,web,h5)中app端日志量最大，清洗入库后的数据一天大概xxxxW
8.数仓架构体系
9.数据平台是怎样的，用到了阿里的那一套吗？
没用到阿里那一套，数据平台为自研产品
10.你了解的调度系统有那些？，你们公司用的是哪种调度系统
airflow，azkaban，ooize，我们公司使用的是airflow
11.你们公司数仓底层是怎么抽数据的？
业务数据用的是datax
日志数据用的是logstash
12.为什么datax抽数据要比sqoop 快？
Sqoop or Datax
13.埋点数据你们是怎样接入的
logstash-->kafka-->logstash-->hdfs
14.如果你们业务库的表有更新，你们数仓怎么处理的？
你真的了解全量表,增量表及拉链表吗？
15.能独立搭建数仓吗
可以
16.搭建过CDH 集群吗
17.说一下你们公司的大数据平台架构？你有参与吗？
18.介绍一下你自己的项目和所用的技术
19.对目前的流和批处理的认识？就是谈谈自己的感受
20.你了解那些OLAP 引擎，MPP 知道一些吗？clickHouse 了解一些吗？你自己做过测试性能吗？
OLAP引擎—Kylin介绍
clickhouse概念篇
clickhouse实践篇-数据类型
clickhouse实践篇-表引擎
clickhouse实践篇-SQL语法
21.Kylin 有了解吗？介绍一下原理
OLAP引擎—Kylin介绍
22.datax 源码有改造过吗
Datax-数据抽取同步利器
23.你们数仓的APP 层是怎么对外提供服务的？
1.直接存入mysql业务库，业务方直接读取
2.数据存入mysql，以接口的形式提供数据
3.数据存入kylin，需求方通过jdbc读取数据
24.数据接入进来，你们是怎样规划的，有考虑数据的膨胀问题吗
25.简述拉链表，流水表以及快照表的含义和特点
你真的了解全量表,增量表及拉链表吗？
26.全量表(df),增量表(di),追加表(da)，拉链表(dz)的区别及使用场景
27.你们公司的数仓分层，每一层是怎么处理数据的
数据仓库分层架构
28.什么是事实表，什么是维表
29.星型模型和雪花模型
全方位解读星型模型,雪花模型及星座模型
30.缓慢变化维如何处理，几种方式
缓慢变化维(SCD)常见解决方案
31.datax与sqoop的优缺点
Sqoop or Datax
32.datax抽数碰到emoji表情怎么解决
33.工作中碰到什么困难，怎么解决的
34.如何用数据给公司带来收益
35.需求驱动和业务驱动，数据开发和ETL开发，实战型和博客型
36.如何用数据实现业务增长，黑客增长？
37.什么是大数据？千万级别的数据完全可以用传统的关系型数据库集群解决，为什么要用到大数据平台。
38.数据质量，元数据管理，指标体系建设，数据驱动
数据质量那点事
39.什么是数仓,建设数仓时碰到过什么问题
40.实时数仓技术选型及保证exactly-once
41.维度建模和范式建模的区别；
42.埋点的码表如何设计；
43.集市层和公共层的区别；
44.缓慢变化维的处理方式
缓慢变化维(SCD)常见解决方案
45.聊聊数据质量
数据质量那点事
46.说说你从0-1搭建数仓都做了什么？你觉得最有挑战的是什么？
47.数据模型如何构建，星型、雪花、星座的区别和工作中如何使用；
全方位解读星型模型,雪花模型及星座模型
48.如何优化整个数仓的执行时长，比如7点所有任务跑完，如何优化到5点；
49.数据倾斜，遇到哪些倾斜，怎么发现的？怎么处理的？；
Hive调优，数据工程师成神之路
50.如何保证数据质量；
数据质量那点事
51.如何保证指标一致性；
52.了解onedata吗，说说你的理解；
OneData方法论在XX的实践
53.数据漂移如何解决；
54.实时场景如何解决的；
55.拉链表如何设计，拉链表出现数据回滚的需求怎么解决。
56.平台选型依据；
57.数仓分层、模型、每层都是做什么的？为什么这么做？
数据仓库分层架构
58.交叉维度的解决方案？
59.数据质量如何保证（DQC）？
数据质量那点事
60.任务延迟如何优化（SLA）？
61.聊一下数据资产。
62.如果让你设计实时数仓你会如何设计，为什么？
63.指标如何定义？
64.sql问题：连续活跃n天用户的获取；
大厂高频面试题-连续登录问题
65.数据倾斜的sql如何优化；数据量大的sql如何优化？
Hive调优，数据工程师成神之路
66.数据仓库主题的划分，参考Teradata的LDM模型；
67.Kimball和Inmon的相同和不同；
68.数据质量管理、数据治理有什么好的方案？知识库管理有什么好的思路？血缘关系图。
69.元数据管理相关问题，集群存储不够了，需要清理不需要的任务和数据该怎么做？
70.业务库2亿数据入仓的策略，一次全量，之后每次增量；
71.什么场景会出现数据倾斜，怎么解决？比如select user_id,count(1) from table group by user_id,其中某些user_id的访问量很大，查询不出结果该怎么办？
Hive调优，数据工程师成神之路
72.sql里面on和where有区别吗？
left join(on&where)
73.聊一下技术架构，整个项目每个环节用的什么技术这个样子；
74.hive、hbase、spark。。。。这些大数据组件，熟悉哪个或者哪些？我说hive和hbase，对方就问hive和hbase的原理，差异等问题；
75.有没有实时数仓的经验，数据实时入仓思路，canal；
76.你对当前的项目组有没有什么自己的看法、意见或者需要改进的地方，这个改进对你有没有什么影响
77.ods的增量能否做成通用的？
78.公共层和数据集市层的区别和特点？
79.从原理上说一下mpp和mr的区别
80.对了中间还有问数仓数据的输出主要是哪些还有数仓的分层；
81.报表如何展示
82.数据库和数据仓库有什么区别
1、数据库是面向事务的，数据是由日常的业务产生的，常更新:
数据仓库是面向主题的，数据来源于数据库或文件，经过一定的规则转换得到，用来分析的。
2、数据库一般是用来存储当前交易数据，
数据仓库存储一般存储的是历史数据
3、数据库的设计一般是符合三范式的，有最大的精确度和最小的冗余度，有利于数据的插入;
数据仓库的设计一般是星型的，有利于査询。
七.Flink
1.Flink实时计算时落磁盘吗
不落，是内存计算
2.日活DAU的统计需要注意什么
3.Flink调优
4.Flink的容错是怎么做的
定期checkpoint存储oprator state及keyedstate到stateBackend
5.Parquet格式的好处？什么时候读的快什么时候读的慢
6.flink中checkPoint为什么状态有保存在内存中这样的机制？为什么要开启checkPoint?
开启checkpoint可以容错，程序自动重启的时候可以从checkpoint中恢复数据
7.flink保证Exactly_Once的原理？
1.开启checkpoint
2.source支持数据重发
3.sink支持事务，可以分2次提交，如kafka；或者sink支持幂等，可以覆盖之前写入的数据，如redis
满足以上三点，可以保证Exactly_Once
8.flink的时间形式和窗口形式有几种？有什么区别，你们用在什么场景下的？
9.flink的背压说下？
10.flink的watermark机制说下，以及怎么解决数据乱序的问题？
11.flink on yarn执行流程
Flink任务提交后，Client向HDFS上传Flink的Jar包和配置，之后向Yarn ResourceManager提交任务，ResourceManager分配Container资源并通知对应的NodeManager启动ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置构建环境，然后启动JobManager，之后ApplicationMaster向ResourceManager申请资源启动TaskManager，ResourceManager分配Container资源后，由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager，NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager，TaskManager启动后向JobManager发送心跳包，并等待JobManager向其分配任务。
12.说一说spark 和flink 的区别
八.Java
1.hashMap底层源码，数据结构
2.写出你用过的设计模式，并举例说明解决的实际问题
3.Java创建线程的几种方式
继承Thread类，重写run方法
实现Runnable接口，实现run方法
通过线程池获取线程
实现Callable接口并实现call方法，创建该类的实例，使用FutureTask类包装Callable对象，使用FutureTask对象作为Thread对象的target创建并启用新线程
4.请简述操作系统的线程和进程的区别
5.Java程序出现OutOfMemoryError:unable to create new native thread 的原因可能有哪些？如何分析和解决？
6.采用java或自己熟悉的任何语言分别实现简单版本的线性表和链表，只需实现add,remove方法即可
7.ArrayList和LinkedList的区别
8.JVM 内存分哪几个区，每个区的作用是什么?
9.Java中迭代器和集合的区别？
集合是将所有数据加载到内存，然后通过集合的方法去内存中获取，而迭代器是一个对象，实现了Iterator接口，实现了接口的hasNext和Next方法。
10.HashMap 和 HashTable 区别
1) 线程安全性不同
HashMap 是线程不安全的，HashTable 是线程安全的，其中的方法是 Synchronize 的，
在多线程并发的情况下，可以直接使用 HashTabl，但是使用 HashMap 时必须自己增加同步
处理。
2) 是否提供 contains 方法
HashMap 只有 containsValue 和 containsKey 方法；HashTable 有 contains、containsKey
和 containsValue 三个方法，其中 contains 和 containsValue 方法功能相同。
3) key 和 value 是否允许 null 值
Hashtable 中，key 和 value 都不允许出现 null 值。HashMap 中，null 可以作为键，这
样的键只有一个；可以有一个或多个键所对应的值为 null。
4) 数组初始化和扩容机制
HashTable 在不指定容量的情况下的默认容量为 11，而 HashMap 为 16，Hashtable 不
要求底层数组的容量一定要为 2 的整数次幂，而 HashMap 则要求一定为 2 的整数次幂。
Hashtable 扩容时，将容量变为原来的 2 倍加 1，而 HashMap 扩容时，将容量变为原
来的 2 倍。
11.线程池使用注意哪些方面？
线程池分为单线程线程池，固定大小线程池，可缓冲的线程池
12.HashMap和TreeMap的区别？TreeMap排序规则？
TreeMap会自动进行排序，根据key的Compare方法进行排序
13.用java实现单例模式
14.使用递归算法求n的阶乘：n! ,语言不限
15.HashMap和Hashtable的区别是什么
16.TreeSet 和 HashSet 区别
HashSet 是采用 hash 表来实现的。其中的元素没有按顺序排列，add()、remove()以及
contains()等方法都是复杂度为 O(1)的方法。
TreeSet 是采用树结构实现（红黑树算法）。元素是按顺序进行排列，但是 add()、
remove()以及 contains()等方法都是复杂度为 O(log (n))的方法。它还提供了一些方法来处理
排序的 set，如 first()，last()，headSet()，tailSet()等等。
17.Stringbuffer 和 Stringbuild 区别
1、StringBuffer 与 StringBuilder 中的方法和功能完全是等价的。
2、只是 StringBuffer 中的方法大都采用了 synchronized 关键字进行修饰，因此是线程
安全的，而 StringBuilder 没有这个修饰，可以被认为是线程不安全的。
3、在单线程程序下，StringBuilder 效率更快，因为它不需要加锁，不具备多线程安全
而 StringBuffer 则每次都需要判断锁，效率相对更低
18.Final、Finally、Finalize
final：修饰符（关键字）有三种用法：修饰类、变量和方法。修饰类时，意味着它不
能再派生出新的子类，即不能被继承，因此它和 abstract 是反义词。修饰变量时，该变量
使用中不被改变，必须在声明时给定初值，在引用中只能读取不可修改，即为常量。修饰
方法时，也同样只能使用，不能在子类中被重写。
finally：通常放在 try…catch 的后面构造最终执行代码块，这就意味着程序无论正常执
行还是发生异常，这里的代码只要 JVM 不关闭都能执行，可以将释放外部资源的代码写在
finally 块中。
finalize：Object 类中定义的方法，Java 中允许使用 finalize() 方法在垃圾收集器将对象
从内存中清除出去之前做必要的清理工作。这个方法是由垃圾收集器在销毁对象时调用
的，通过重写 finalize() 方法可以整理系统资源或者执行其他清理工作。
19..==和 Equals 区别
== : 如果比较的是基本数据类型，那么比较的是变量的值
如果比较的是引用数据类型，那么比较的是地址值（两个对象是否指向同一块内
存）
equals:如果没重写 equals 方法比较的是两个对象的地址值。
如果重写了 equals 方法后我们往往比较的是对象中的属性的内容
equals 方法是从 Object 类中继承的，默认的实现就是使用==
20.比较ArrayList，LinkedList的存储特性和读写性能
21.Java 类加载过程
Java类加载需要经历一下几个过程：
加载
加载时类加载的第一个过程，在这个阶段，将完成一下三件事情：
通过一个类的全限定名获取该类的二进制流。
将该二进制流中的静态存储结构转化为方法去运行时数据结构。
在内存中生成该类的Class对象，作为该类的数据访问入口。
验证
验证的目的是为了确保Class文件的字节流中的信息不回危害到虚拟机.在该阶段主要完成以下四钟验证:
文件格式验证：验证字节流是否符合Class文件的规范，如主次版本号是否在当前虚拟机范围内，常量池中的常量是否有不被支持的类型.
元数据验证:对字节码描述的信息进行语义分析，如这个类是否有父类，是否集成了不被继承的类等。
字节码验证：是整个验证过程中最复杂的一个阶段，通过验证数据流和控制流的分析，确定程序语义是否正确，主要针对方法体的验证。如：方法中的类型转换是否正确，跳转指令是否正确等。
符号引用验证：这个动作在后面的解析过程中发生，主要是为了确保解析动作能正确执行。
准备
准备阶段是为类的静态变量分配内存并将其初始化为默认值，这些内存都将在方法区中进行分配。准备阶段不分配类中的实例变量的内存，实例变量将会在对象实例化时随着对象一起分配在Java堆中。
解析
该阶段主要完成符号引用到直接引用的转换动作。解析动作并不一定在初始化动作完成之前，也有可能在初始化之后。
初始化
初始化时类加载的最后一步，前面的类加载过程，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的Java程序代码。
22.java中垃圾收集的方法有哪些?
23.如何判断一个对象是否存活?(或者GC对象的判定方法)
判断一个对象是否存活有两种方法:
引用计数法
可达性算法(引用链法)
24.jvm、堆栈
25.java基本数据类型
九.Elasticsearch
1.为什么要用es？存进es的数据是什么格式的，怎么查询
十.Flume
1.什么是flume
a.Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。
b.Flume可以采集文件，socket数据包等各种形式源数据，又可以将采集到的数据输出到HDFS、hbase、hive、kafka等众多外部存储系统中
c.一般的采集需求，通过对flume的简单配置即可实现
d.ume针对特殊场景也具备良好的自定义扩展能力，因此，flume可以适用于大部分的日常数据采集场景
2.flume运行机制
Flume分布式系统中最核心的角色是agent，flume采集系统就是由一个个agent所连接起来形成
每一个agent相当于一个数据传递员，内部有三个组件：
Source：采集源，用于跟数据源对接，以获取数据
Sink：下沉地，采集数据的传送目的，用于往下一级agent传递数据或者往最终存储系统传递数据
Channel：angent内部的数据传输通道，用于从source将数据传递到sink
3.Flume采集数据到Kafka中丢数据怎么办
4.Flume怎么进行监控?
5.Flume的三层架构，collector、agent、storage
十一.Sqoop
1.Sqoop底层运行的任务是什么
只有Map阶段，没有Reduce阶段的任务。
2.sqoop的迁移数据的原理
3.Sqoop参数
/opt/module/sqoop/bin/sqoop import \
--connect \
--username \
--password \
--target-dir \
--delete-target-dir \
--num-mappers \
--fields-terminated-by \
--query "$2" ' and $CONDITIONS;'
4.Sqoop导入导出Null存储一致性问题
Hive中的Null在底层是以“\N”来存储，而MySQL中的Null在底层就是Null，为了保证数据两端的一致性。在导出数据时采用--input-null-string和--input-null-non-string两个参数。导入数据时采用--null-string和--null-non-string。
5.Sqoop数据导出一致性问题
1）场景1：如Sqoop在导出到Mysql时，使用4个Map任务，过程中有2个任务失败，那此时MySQL中存储了另外两个Map任务导入的数据，此时老板正好看到了这个报表数据。而开发工程师发现任务失败后，会调试问题并最终将全部数据正确的导入MySQL，那后面老板再次看报表数据，发现本次看到的数据与之前的不一致，这在生产环境是不允许的。
2）场景2：设置map数量为1个（不推荐，面试官想要的答案不只这个）
多个Map任务时，采用–staging-table方式，仍然可以解决数据一致性问题。
6.通过sqoop把数据加载到mysql中，如何设置主键？
十二.Redis
1.缓存穿透、缓存雪崩、缓存击穿
1）缓存穿透是指查询一个一定不存在的数据。由于缓存命不中时会去查询数据库，查不到
数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿
透。
解决方案：
① 是将空对象也缓存起来，并给它设置一个很短的过期时间，最长不超过 5 分钟
② 采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定
不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力
2）如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，
就会造成缓存雪崩。
解决方案：
尽量让失效的时间点不分布在同一个时间点
3）缓存击穿，是指一个 key 非常热点，在不停的扛着大并发，当这个 key 在失效的瞬间，
持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
可以设置 key 永不过期
2.数据类型
3.持久化
1）RDB 持久化：
① 在指定的时间间隔内持久化
② 服务 shutdown 会自动持久化
③ 输入 bgsave 也会持久化
2）AOF : 以日志形式记录每个更新操作
Redis 重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。
保存策略：
推荐（并且也是默认）的措施为每秒持久化一次，这种策略可以兼顾速度和安全性。
缺点：
1 比起 RDB 占用更多的磁盘空间
2 恢复备份速度要慢
3 每次读写都同步的话，有一定的性能压力
4 存在个别 Bug，造成恢复不能
选择策略：
官方推荐：
string
字符串
list
可以重复的集合
set
不可以重复的集合
hash
类似于 Map
zset(sorted set）
带分数的 set
如果对数据不敏感，可以选单独用 RDB；不建议单独用 AOF，因为可能出现 Bug;如果只是做纯内存缓存，可以都不用
4.悲观锁和乐观锁
悲观锁：执行操作前假设当前的操作肯定（或有很大几率）会被打断（悲观）。基于这个假设，我们在做操作前就会把相关资源锁定，不允许自己执行期间有其他操作干扰。
乐观锁：执行操作前假设当前操作不会被打断（乐观）。基于这个假设，我们在做操作前不会锁定资源，万一发生了其他操作的干扰，那么本次操作将被放弃。Redis 使用的就是乐观锁。
5.redis 是单线程的，为什么那么快
1)完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。
2)数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的
3)采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗
4)使用多路 I/O 复用模型，非阻塞 IO
5)使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，
Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求
6.redis的热键问题？怎么解决？
十三.Mysql
1.请写出mysql登录命令，用户名user，密码123456，地址192.168.1.130
mysql -h192.168.1.130-uuser -p123456 -P3306 -Dwemeta_test
2.为什么MySQL的索引要使用B+树而不是其它树形结构?比如B树？
B树
B树不管叶子节点还是非叶子节点，都会保存数据，这样导致在非叶子节点中能保存的指针数量变少（有些资料也称为扇出）
指针少的情况下要保存大量数据，只能增加树的高度，导致IO操作变多，查询性能变低；
B+树
1.单一节点存储更多的元素，使得查询的IO次数更少。
2.所有查询都要查找到叶子节点，查询性能稳定。
3.所有叶子节点形成有序链表，便于范围查询,远远高于B-树
十四.数据结构与算法
1.二分查找
package com.wedoctor.search;
public class Binarysearch {
public static int bsearchWithoutRecursion(int arr[], int key) {
int low = 0;
int high = arr.length - 1;
while (low <= high) {
int mid = low + (high - low) 2;
if (arr[mid] > key)
high = mid - 1;
else if (arr[mid] < key)
low = mid + 1;
else
return mid;
}
return -1;
}
public static void main(String[] args) {
int arr[] = {1,3,5,6,8,9,11,14,23};
int num = bsearchWithoutRecursion(arr, 9);
System.out.println(num);
}
}
2.快排
3.归并排序
4.冒泡排序
package com.wedoctor.sort;
import java.util.Arrays;
public class BubbleSort {
public static void main(String[] args) {
int[] arr = new int[] { 2, 8, 7, 9, 4, 1, 5, 0 };
bubbleSort(arr);
}
public static void bubbleSort(int[] arr) {
//控制多少轮
for (int i = 1; i < arr.length; i++) {
//控制每一轮的次数
for (int j = 0; j <= arr.length -1 - i; j++) {
if (arr[j] > arr[j + 1]) {
int temp;
temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
}
}
}
System.out.println(Arrays.toString(arr));
}
}
5.字符串反转
package com.wedoctor.str;
public class StrReverse {
public static String getNewStr(String str){
StringBuffer sb = new StringBuffer(str);
String newStr = sb.reverse().toString();
return newStr;
}
public static void main(String[] args) {
System.out.println(getNewStr("thjymhr"));
}
}
6.Btree简单讲一下
B树(B-树)是一种适合外查找的搜索树，是一种平衡的多叉树
B树的每个结点包含着结点的值和结点所处的位置
7.动态规划 最大连续子序列和
package com.wedoctor;
import java.util.Arrays;
public class MaxSum {
public static int findMax(int arr[]){
if (arr.length == 1){
return arr[0];
}
int mid = (arr.length) / 2;
int[] leftArr = Arrays.copyOfRange(arr, 0, mid);
int[] rightArr = Arrays.copyOfRange(arr, mid, arr.length);
int lenLeft = findMax(leftArr);
int lenRight = findMax(rightArr);
int lenMid = maxInMid(leftArr, rightArr);
int max = Math.max(Math.max(lenLeft,lenRight),lenMid);
return max;
}
public static int maxInMid(int left[],int right[]){
int maxLeft = 0;
int maxRight = 0;
int tmpLeft = 0;
int tmpRight = 0;
for (int i = 0;i< left.length;i++){
tmpLeft = tmpLeft + left[left.length - 1 - i];
maxLeft = Math.max(tmpLeft,maxLeft);
}
for (int i = 0;i< right.length;i++){
tmpRight = tmpRight + right[i];
maxRight = Math.max(tmpRight,maxRight);
}
return maxRight + maxLeft;
}
public static void main(String[] args) {
int arr[] = {3,-1,10};
System.out.println(findMax(arr));
}
}
8.二叉树概念，特点及代码实现
二叉树是n(n>=0)个结点的有限集合，该集合或者为空集（称为空二叉树），或者由一个根结点和两棵互不相交的、分别称为根结点的左子树和右子树组成。
特点：
每个结点最多有两颗子树，所以二叉树中不存在度大于2的结点。
左子树和右子树是有顺序的，次序不能任意颠倒。
即使树中某结点只有一棵子树，也要区分它是左子树还是右子树。
实现：
package com.wedoctor;
public class BinaryTreeNode {
int data;
BinaryTreeNode left;
BinaryTreeNode right;
BinaryTreeNode (int x) {
data= x;
}
public BinaryTreeNode(int data, BinaryTreeNode left, BinaryTreeNode right) {
this.data = data;
this.left = left;
this.right = right;
}
public int getData() {
return data;
}
public void setData(int data) {
this.data = data;
}
public BinaryTreeNode getLeft() {
return left;
}
public void setLeft(BinaryTreeNode left) {
this.left = left;
}
public BinaryTreeNode getRight() {
return right;
}
public void setRight(BinaryTreeNode right) {
this.right = right;
}
}
9.链表
十五.Linux
1.怎么查看用户组
2.怎么修改文件权限
3.常用的命令有哪些
4.怎么修改文本文件第一行字符
5.查看内存
top
6.查看磁盘存储情况
df -h
7.查看磁盘IO读写(yum install iotop安装）
iotop
8.直接查看比较高的磁盘读写程序
iotop -o
9.查看端口占用情况
netstat -tunlp | grep 端口号
10.查看报告系统运行时长及平均负载
uptime
11.查看进程
ps aux