kafka总结

注意：文字仅本人用于了解kafka的概念和基本使用，自己手敲加深概念，非原创，部分原创见：kafka究竟是干嘛的？

一、什么是kafka？

1.1 kafka来由
kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布\订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。此外，kafka可以通过kafka Connect连接到外部系统（用于数据输入/输出），并提供kafka Streams（一个Java流式处理库）。
重点：按照分布式事务日志架构的大规模发布/订阅消息队列。可以看到kafka也就是一个发布/订阅的消息队列。只是它具有分布式以及大规模（支持大数据量）的特征。

二、消息队列

2.1 消息队列概念
在计算机科学中，消息队列（message queue）是一种进程间通信或不同线程间的通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。消息队列提供了异步的通信协议，每一个贮列中的记录包含详细说明的资料，包含发生的时间，输入设备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列互交。消息会保存在队列中，直到接收者取回它。
重点：消息的发送者和接收者不需要同时与消息队列交互。消息会保存在队列中，直到接收者取回它。
解读：上面的重点可以提炼出，消息队列解耦了发送者和消费者，也就具有了保存消息的特性。
问题：
1.保存消息有什么作用？如果下游消费者消费的慢，那是不是可以慢慢消费了。想想现实生活中的秒杀活动，是不是经常挂掉？如果加入消息队列（假如存储、写入没有问题）那是不是消费者就不会因为数据量太大而挂掉，因为你可以慢慢消费（靠谱）,专业属于：削峰限流！
2.可以起多个消费者消费同一个消息，分别进行不同的处理。专业数据：异步处理！

2.2 发布/订阅消息队列
其实消息队列有两种模式，第一种是点对点模式(point to point , queue)，另一种是发布/订阅模式（publish/subscribe, topic）
点对点：顾名思义也就是生产者发送一条消息到queue，只有一个消费者能收到，当一个消费者消费了队列中的某条数据之后，该条数据则从消息队列中删除。该模式即使有多个消费者同时消费数据，也能保证数据处理的顺序。
发布/订阅模式：消息会被持久化到一个topic中，那么就可以起多个消费者去订阅一个或多个topic，那么topic中的同一条数据就可以被多个消费者消费，数据被消费后也不会立马删除。

三、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）Replication：副本。一个topic的每一个分区都有若干个副本，一个Leader和若干个Follower。
（8）Leader：每一个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是Leader。
（9）Follower：每个分区多个副本中的“从”，实时从Leader中同步数据，保持和Leader数据的同步。Leader发生故障时，某个Follower会成为新的Leader

四、参数详解

一、生产者
	1. acks：Producer需要Leader确认的Producer请求的应答数
		acks = 0 ，表示Producer请求立即返回，不需要等待Leader的任何确认。这种方案有最高的吞吐率，但是不保证消息是否真的发送成功。
		acks = -1，表示分区Leader必须等待消息被成功写入到所有的ISR副本（同步副本）中才认为Producer请求成功。这种方案提供最高的消息持久性保证，但是理论上吞吐率也是最差的。
		acks = 1，表示Leader副本必须应答此Producer请求并写入消息到本地日志，之后Producer请求被认为成功。如果此时Leader副本应答请求之后挂掉了，消息会丢失。这个方案，提供了不错的持久性保证和吞吐。
		
	2. buffer.memory：该参数用于指定Producer端用于缓存消息的缓冲区大小，单位为字节，默认值为：33554432，即32M。
	3. compression.type：压缩器，目前支持none（不压缩），gzip，snappy和lz4.
	4. retries：Producer发送消息失败重试的次数。重试时Producer会重新发送之前由于瞬时原因出现失败的消息。瞬时失败的原因可能包括：元数据信息失效、副本数量不足、超时、位移越界或未知分区等。倘若设置了retries > 0，那么这些情况下Producer会尝试重新发送。
	5. batch.size：默认值为16k，Producer按照batch进行发送，当batch满了后，Producer会把消息发送出去。
	6. linger.ms：Producer是按照batch进行发送的，但是还要看linger.ms的值，默认是0，表示不做停滞。为了减少了网络IO，提升整体的性能。建议设置5-100ms。
	
二、Broker
	1. replica.lag.time.max.ms：ISP中，如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR。该时间阈值，默认30s。
	2. auto.leader.rebalance.enable：默认是true。自动Leader Partion平衡。
	3. leader.imbalance.per.broker.percentage：默认是10%。每个Broker允许的不平衡的Leader的比率。如果每个Broker超过这个值，控制器会触发Leader的平衡。
	4. leader.imbalance.check.interval.seconds：默认值为300s。检查Leader负载是否平衡的间隔时间。
	5. log.segment.bytes：Kafka中log日志是分成一块块存储的，此配置是指log日志划分成块的大小，默认值1G。
	6. log.index.interval.bytes：默认4k，Kafka里面每当写入4kb大小的日志（.log），然后就往index文件里面记录一个索引。
	7. log.retention.hours：Kafka中数据保存的时间，默认7天
	8. log.retention.minutes：Kafka中数据保存的时间，分钟级别，默认关闭。
	9. log.retention.ms：Kafka中数据保存的时间，毫秒级别，默认关闭。
	10. log.retention.check.interval.ms：检查数据是否保存超时的间隔，默认是5分钟。
	11. log.retention.bytes：默认等于-1，表示无穷大。超过设置的所有日志总大小，删除最早的segment。
	12. log.cleanup.policy：默认是delete，表示所有数据启用删除策略；如果设置值为compact，表示所有数据启用压缩策略。
	13. num.io.threads：默认是8.负责写磁盘的线程数。整个参数值要占总核数的50%。
	14. num.replica.fetchers：副本拉取线程数，这个参数占总核数的50%的1/3。
	15. num.network.threads：默认是3.数据传输线程数，这个参数占总核数的50%的2/3。
	16. log.flush.interval.message：强制页缓存刷写到磁盘的条数，默认是long的最大值，9223372036854775807。一般不建议修改，交给系统自己管理。
	17. log.flush.interval.ms：每隔多久，刷数据到磁盘，默认是null。一般不建议修改，交给系统自己管理。
	
三、消费者
	1. bootstrap.servers：向Kfka集群建立初始连接用到的host/port列表。
	2. key.deserializer和value.deserializer：指定接收消息的key和value的反序列化类型。一定要写全类名。
	3. group.id：标记消费者所属的消费者组。
	4. enable.auto.commit：默认值为true，消费者会自动周期性的向服务器提交偏移量。
	5. auto.commit.interval.ms：如果设置了enable.auto.commit的值为true，则该值定义了消费者偏移量向Kafka提交的评率，默认为5s。
	6. auto.offset.reset：当Kafka中没有初始偏移量或当前偏移量在服务器中不存在（如，数据被删除了），该如何处理？
		（1）earliest：自动重置偏移量到最早的偏移量。
		（2）latest：默认，自动重置偏移量为最新的偏移量
		（3）none：如果消费组原来的偏移量不存在，则向消费者跑出异常。
	7. offsets.topic.num.partitions：_consumer_offsets的分区数，默认是50个分区。
	8. heartbeat.interval.ms：Kafka消费者和coordinator之间的心跳时间，默认3s。该条目的值必须小于session.timeout.ms，也不应该高于session.timeout.ms的1/3。
	9. session.timeout.ms：Kafka消费者和coordinator之间连接超时时间，默认45s。超过该值，该消费者被移除，消费者组执行再平衡。
	10. max.poll.interval.ms：消费者处理消息的最大时长，默认是5分钟。超过该值，该消费者被移除，消费者组执行再平衡。
	11. fetch.min.bytes：默认1个字节。消费者获取服务器端一批数据的最小字节数。
	12. fetch.max.wait.ms ：默认500ms。如果没有从服务器端获取一批数据的最小字节数，该时间到，仍然会返回数据
	13. fetch.max.bytes：默认值：52428800字节，即50M。消费者获取服务器一批消息最大的字节数。如果服务器端一批次的数据大于该值仍然可以拉取回来这批数据，因此，这不是一个绝对最大值。一批次的大小受message.max.bytes（broker config） or max.message.bytes（topic config）影响。
	14. max.poll.records：一次poll拉取数据返回消息的最大条数，默认500条。

五、kafka和zookeeper的关系
Kafka和Zookeeper是两个不同的开源项目，但在Kafka的分布式架构中，Zookeeper扮演了重要的角色。具体来说，Kafka通过使用Zookeeper来实现以下几个功能：
1、Broker管理：Zookeeper用于管理Kafka集群中的Broker节点，包括Broker的上线和下线、Broker节点的配置信息等。
2、Topic和Partition管理：Zookeeper用于存储Kafka集群中的Topic和Partition信息，包括Topic的创建、删除、分区数的变更等。
3、消费者管理：Zookeeper用于协调Kafka消费者的消费过程，包括消费者组的管理、消费者组内部的协调、消费位移的管理等。
4、集群元数据管理：Zookeeper用于存储Kafka集群的元数据信息，包括集群的配置信息、Broker节点的信息等。
总结：因此，可以看出，Zookeeper在Kafka的分布式架构中扮演着重要的角色，Kafka依赖Zookeeper来实现集群的管理和协调，确保Kafka集群的高可用性和可靠性。