Kafka入门-认知+配置优化

1.kafka整体概念
不仅仅是一个消息中间件， 可以看作是一个流平台、可以订阅发布数据流，并且把数据保存起来进行处理。是一个分布式的以集群形式运行的中间件。kafka的低延时所以被用来作为核心的业务应用上。消息天生持久化：数据存储平台，流平台。主要用在数据的流处理上，所以因为他的低延时被主要用在核心的业务应用上。
1.1kafka内部相关的概念
1）消息：可以包括键的一个字节数组
批次：为了提高效率，消息是被分批次写入broke的（同一个主题中消息），消息也是可以被压缩。
主题：个人理解是和topick关联的，一个topick对应一个主题。
分区：一个主题可以被分为许多分区，每个分区内的消息是以追加的形式加入到消息中的。所以单个分区内的消息肯定是顺序 的。分区的个数是自定义的，broke接受到消息后就可以根据内部的分区器来对消息进行映射（主要是用来实现数据的冗余和伸缩性）
生产者：生产者默认情况下把消息均衡分布到主题的所有分区上，如果需要指定分区，则需要使用消息里的消息键和分区器。
消费者：消费者订阅主题，一个或者多个，并且按照消息的生成顺序读取。消费者通过检查所谓的偏移量来区分消息是否读取过。
偏移量：移量是一种元数据，一个不断递增的整数值，创建消息的时候，Kafka会把他加入消息。在一个分区里，每个消息的偏移量是唯一的。每个分区最后读取的消息偏移量会保存到Zookee
消费者群组：groupID。一个主题可以被多个消费者群组消费

消费者群组和partition之间的关系：一个分区只可以被一个消费者群组里面一个consumer消费，一个消费者群组里的consumer可以消费多个分区。个人理解这样的优点：可以保证一个消费者群组内的消费者对消息的无重复消费，提高consumer消费的效率。

在这里有个疑问：偏移量一个分区只有一个，但是如果不同的消费者群组里面的consumer消费同一个分区的话，难道使用的是偏移量是一个吗？

broke和集群

2.kafka相关文件的配置
配置文件放在Kafka目录下的config目录中，主要是server.properties文件
broker.id
在单机时无需修改，但在集群下部署时往往需要修改。它是个每一个broker在集群中的唯一表示，要求是正数。当该服务器的IP地址发生改变时，broker.id没有变化，则不会影响consumers的消息情况
zookeeper.connect
zookeeper集群的地址，可以是多个，多个之间用逗号分割
log.dirs
Kafka把所有的消息都保存在磁盘上，存放这些数据的目录通过log.dirs指定。可以指定多个，充分利用磁盘的并行读写能力

num.recovery.threads.per.data.dir
每数据目录用于日志恢复启动和关闭时的线程数量。因为这些线程只是服务器启动和关闭时会用到。所以完全可以设置大量的线程来达到并行操作的目的。注意，这个参数指的是每个日志目录的线程数，比如本参数设置为8，而log.dirs设置为了三个路径，则总共会启动24个线程。
auto.create.topics.enable
是否允许自动创建主题。如果设为true，那么produce，consume或者fetch metadata一个不存在的主题时，就会自动创建。缺省为true。
主题配置（topic配置）
num.partitions
每个新建主题的分区个数。这个参数一般要评估，比如，每秒钟要写入和读取1GB数据，如果现在每个消费者每秒钟可以处理50MB的数据，那么需要20个分区，这样就可以让20个消费者同时读取这些分区，从而达到设计目标。
log.retention.hours
日志保存时间，默认为7天（168小时）。超过这个时间会清理数据。bytes和minutes无论哪个先达到都会触发。与此类似还有log.retention.minutes和log.retention.ms，都设置的话，优先使用具有最小值的那个。
log.retention.bytes
topic每个分区的最大文件大小，一个topic的大小限制 = 分区数*log.retention.bytes。-1没有大小限制。log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除。
log.segment.bytes
分区的日志存放在某个目录下诸多文件中，这些文件将分区的日志切分成一段一段的，我们称为日志片段。这个属性就是每个文件的最大尺寸；当尺寸达到这个数值时，就会关闭当前文件，并创建新文件。被关闭的文件就开始等待过期。默认为1G。
如果一个主题每天只接受100MB的消息，那么根据默认设置，需要10天才能填满一个文件。而且因为日志片段在关闭之前，消息是不会过期的，所以如果log.retention.hours保持默认值的话，那么这个日志片段需要17天才过期。因为关闭日志片段需要10天，等待过期又需要7天。
log.segment.ms
作用和log.segment.bytes类似，只不过判断依据是时间。同样的，两个参数，以先到的为准。这个参数默认是不开启的。
message.max.bytes
表示一个服务器能够接收处理的消息的最大字节数，注意这个值producer和consumer必须设置一致，且不要大于fetch.message.max.bytes属性的值。该值默认是1000000字节，大概900KB~1MB。
3.硬件配置对Kafka性能的影响
磁盘吞吐量/磁盘容量
磁盘吞吐量会影响生产者的性能。因为生产者的消息必须被提交到服务器保存，大多数的客户端都会一直等待，直到至少有一个服务器确认消息已经成功提交为止。也就是说，磁盘写入速度越快，生成消息的延迟就越低。
磁盘容量的大小，则主要看需要保存的消息数量。如果每天收到1TB的数据，并保留7天，那么磁盘就需要7TB的数据。
内存
Kafka本身并不需要太大内存，内存则主要是影响消费者性能。在大多数业务情况下，消费者消费的数据一般会从内存中获取，这比在磁盘上读取肯定要快的多。
网络
网络吞吐量决定了Kafka能够处理的最大数据流量。
CPU
Kafka对cpu的要求不高，主要是用在对消息解压和压缩上。所以cpu的性能不是在使用Kafka的首要考虑因素。
4.为何需要Kafka集群
1.负载均衡：同一个主题的不同分区可以处在不同的broke中，生产者和消费者对当前主题进行操作可以落在不通的服务器上，减少服务器压力
2.容灾性。分区之间会发生复制功能，提供数据冗余，当某一集群挂掉后，会选出新的首领，再次把流量拉取到新的首领broke上即可。
3.性能提升，由于磁盘I/O或者内存等导致性能问题，可以通过添加机器来实现提升性能。
5.如何估算Kafka集群中Broker的数量
需要多少磁盘空间保留数据，和每个broker上有多少空间可以用。比如，如果一个集群有10TB的数据需要保留，而每个broker可以存储2TB，那么至少需要5个broker。如果启用了数据复制，则还需要一倍的空间，那么这个集群需要10个broker。
6.Broker如何加入Kafka集群
非常简单，只需要两个参数。第一，配置zookeeper.connect，第二，为新增的broker设置一个集群内的唯一性id。

    画一个自己对kafka的理解图