大数据相关企业面试问题 二（Kafka、Spark）

1.Kafka

1.Kafka如何保证数据一致性

答：一致性定义:若某条消息对Consumer可见,那么即使Leader宕机了,在新Leader上数据依然可以被读到
1.HighWaterMark简称HW: Partition的高水位，取一个partition对应的ISR中最小的LEO作为HW，消费者最多只能消费到HW所在的位置，另外每个replica都有highWatermark，leader和follower各自负责更新自己的highWatermark状态，highWatermark <= leader. LogEndOffset
2.对于Leader新写入的msg，Consumer不能立刻消费，Leader会等待该消息被所有ISR中的replica同步后,更新HW,此时该消息才能被Consumer消费，即Consumer最多只能消费到HW位置
这样就保证了如果Leader Broker失效,该消息仍然可以从新选举的Leader中获取。对于来自内部Broker的读取请求,没有HW的限制。同时,Follower也会维护一份自己的HW,Folloer.HW = min(Leader.HW, Follower.offset)

2.Kafka的message中有哪些信息

答：①crc32：4个字节，消息的校验码
②magic：1字节，魔数标识，与消息格式有关，取值0或1，为0时，消息的offset使用绝对offset，且消息格式中没有时间戳部分，为1时，消息的offset使用的相对offset且消息格式中存在时间戳部分，所以magic的值不同，消息的长度是不同的
③attributes：1字节，消息的属性，其中第0~2位的组合表示消息使用的压缩类型，0表示无压缩，1表示gzip压缩，2表示snappy压缩，3表示lz4压缩。第3位表示时间戳类型，0表示创建时间，1表示追加时间
④timestamp：时间戳，其含义由attributes的第3位确定
⑤key length：消息key的长度
⑥key：消息的key
⑦value length：消息的value的长度
⑧value：消息的内容

3.kafka如何保证不丢消息，即数据的可靠性保证

答：Kafka不丢消息主要是依赖于broker中的ISR机制：
①首先Kafka消息在broker的存储形式是以log的形式存在的，打开Kafka的存储的文件夹时就能发现有.log.index.timeindex三类文件，其中index、timeindex是索引文件，而.log就是具体的消息的存储文件。不同的文件存在于不同的分区，这个是由分区选择器确定的。按照常识，要想保证高可用保证不丢失，最直观的就是制造冗余，多做备份，Kafka也是这么去做的。

②在Kafka中备份日志文件被称为replica，replica又分为leaderreplica和followerreplica，而followerreplica存在的唯一目的就是防止消息丢失，并不参与具体的业务逻辑的交互。只有leader才参与服务，follower的作用就是充当leader的候补，平时的操作也只有信息同步。
ISR（in-syncreplica）也就是这组与leader保持同步的replica集合，我们要保证不丢消息，首先要保证ISR的存活（至少有一个备份存活），并且消息提交成功。那存活的概念是什么呢，就是说不仅需要机器正常，还需要跟上leader的消息进度，当达到一定程度的时候就会认为“非存活”状态。

③brokeroffset大致分为：baseoffset、highwatemark（HW）、logendoffset（LEO）这个几个概念。baseoffset：起始位移，replica中第一条消息的offset；HW：replica高水印值，副本中最新一条已提交消息的位移。leader的HW值也就是实际已提交消息的范围，每个replica都有HW值，但仅仅leader中的HW才能作为标示信息。就是说当按照参数标准成功完成消息备份（成功同步给followerreplica后）才会更新HW的值，代表消息理论上已经不会丢失，可以认为“已提交”。LEO：日志末端位移，也就是replica中下一条待写入消息的offset，注意哈，是下一条并且是待写入的，并不是最后一条。这个LEO个人感觉也就是用来标示follower的同步进度的。

④broker从收到消息到返回响应过程中发生了什么：
1、broker收到producer的请求
2、leader收到消息，并成功写入，LEO值+1
3、broker将消息推给followerreplica，follower成功写入LEO+1
4、所有LEO写入后，leaderHW+1
5、消息可被消费，并成功响应

⑤这里具体需要同步完成的follower的数量是由acks参数来确定的，当设定为1的时候仅需要同步给一个follower即可，如果为-1（all），则需要同步所有的follower，如果为0的话就代表不需要同步给follower，记下消息之后立马返回，这样的吞吐量是最好的，但是对消息的也就不能保证丢了，其实常规环境对消息丢失要求没有那么严苛的环境还是可以使用的。常规使用最多的环境应该是设置为1，同步一份就ok了。
ISR（insyncreplica）的含义是同步的replica，相对的就有outofsyncreplica，也就是跟不上同步节奏的replica，现在面临的有两个问题，
当replica跟不上进度时该怎么处理（或原本跟不上节奏的现在又跟上节奏了该如何处理）、如何去判定跟不跟得上节奏。第一个问题很简单，跟上节奏就加入ISR，跟不上节奏就踢出ISR。

⑥关键是如何判定：