kafka知识总结

1.什么是kafka？

Kafka是一个分布式的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域。

2.流式计算？

大体包括storm、 sparkStreaming 、flink
storm：来一条数据，处理一条，实时性好
sparkStreaming ：微批处理，延迟性较差，但是兼容性好
flink：一个流系统，采用原生的流处理系统，保证了低延迟性，在API和容错性上也是做的比较完善，使用起来相对来说也是比较简单的，部署容易

3.JMS 消息传输模型？

• 点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）
  点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。
• 发布/订阅模式（一对多，数据生产后，推送给所有订阅者）
  发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即时当前订阅者不可用，处于离线状态。
  

4.总结flume？ source sink channel 常用的类型？

5.flume和 kafka 有甚区别？

6.Kafka与传统消息系统之间有三个关键区别？

• Kafka 持久化日志，这些日志可以被重复读取和无限期保留
• Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性
• Kafka 支持实时的流式处理

7.JMS消息传输模型？

与4一致

8.总结常用的 MQ？

• JMS消息服务器 ActiveMQ
• 分布式消息中间件 Metamorphosis
• 分布式消息中间件 RocketMQ
• NET消息中间件 DotNetMQ
• 基于HBase的消息队列 HQueue
• Go 的 MQ 框架 KiteQ
• AMQP消息服务器 RabbitMQ
• MemcacheQ 是一个基于 MemcacheDB 的消息队列服务器。

9.消息系统的核心作用？

解耦 异步 并行

10.Kafka核心组件和作用？

1）Producer ：消息生产者，就是向kafka broker发消息的客户端；
2）Consumer ：消息消费者，向kafka broker取消息的客户端；
3）Consumer Group （CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4）Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
5）Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic；
6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列；
7）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。
8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。
9）follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的leader。
10）Offset：kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka

11.CG 作用？

总的来说1.提高并发消费能力 2.故障容错
通常情况下，一个group中会包含多个consumer，这样不仅可以提高topic中消息的并发消费能力，而且还能提高"故障容错"性，如果group中的某个consumer失效，那么其消费的partitions将会有其他consumer自动接管。
对于Topic中的一条特定的消息，只会被订阅此Topic的每个group中的其中一个consumer消费，此消息不会发送给一个group的多个consumer；
那么一个group中所有的consumer将会交错的消费整个Topic，每个group中consumer消息消费互相独立，我们可以认为一个group是一个"订阅"者。

• 在kafka中,一个partition中的消息只会被group中的一个consumer消费(同一时刻)；一个Topic中的每个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以同时消费多个partitions中的消息。
• kafka的设计原理决定,对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。
• kafka只能保证一个partition中的消息被某个consumer消费时是顺序的；事实上，从Topic角度来说,当有多个partitions时,消息仍不是全局有序的。

12.CG的Consumer与topic下的partition关系？

一一对应的关系，一个partition同时只能被一个消费者消费

13.kafka 消息有序论？ 如何保证消息全局有序？

其实这是个伪命题 ，全局有序得是生产有序 存储有序 消费有序，在一个partition中可以保证
但是再全局有序，那只能是一个生产者，一个broker，一个消费者，那样的话，kafka的优越性就体现不出来了

14.Kafka消息的分发策略？

Producer客户端负责消息的分发

• kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"/"partitions
  leader列表"等信息；
• 当producer获取到metadata信息之后, producer将会和Topic下所有partition
  leader保持socket连接；
• 消息由producer直接通过socket发送到broker，中间不会经过任何"路由层"，事实上，消息被路由到哪个partition上由producer客户端决定；
• 比如可以采用"random"“key-hash”"轮询"等,如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。
• 在producer端的配置文件中,开发者可以指定partition路由的方式。

15.Producer消息发送的应答机制？ ACK机制？ 如果保证数据不丢失？

ack应答机制
对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。
所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。

acks参数配置：
acks：
0：producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；
1：producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；
-1（all）：producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。

16.partition本质？ 命名？ 保存的什么文件？

17.partition的数据如何保存在磁盘？

通过segment文件形式保存到磁盘中
“.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中message的物理偏移地址

18.partition如何分布在broker？

Partition的序号对broker的数量取模。
注：
Partition的序号命名规范：topic的名称+有序id

19.kafka 独特的特点？

pagecache
sendfile

20.pagecache？

kafka 充分利用当前物理机的空闲内存做缓存

21.消费者如何标记消费状态？

若在消费之前标记状态，容易造成数据丢失；
若在新消费之后标记状态，容易造成数据重复。
正解为通过zookeeper标记状态，不在乎前后。

22.sparkStreaming 消费kafka数据的两种方式？

receiver：高阶API zk管理偏移量 不能保证消息的可靠性
direct：低阶API 自己管理偏移量 可以保证消息的可靠性