Kafka的部分集群参数

没有运维就得啥都自己干，整了个Kafka集群，代码测试了几天都跑的挺好，但是学习使用过程中也发现了问题，查了查与相关参数配置有关系，做个笔记👀

1、Broker.id: 每个 broker 都需要有一个标识符，使用broker.id来表示，默认值是0，也可以被设置成其他任意整数。这个值在整个Kafka集群里必须是唯一的。

2、listeners：监听器，告知外部连接者要通过什么协议访问指定主机名和端口开放的Kafka服务。

#   FORMAT:
#     listeners = listener_name://host_name:port
#   EXAMPLE:
#     listeners = PLAINTEXT://your.host.name:9092

配置文件的格式为:协议名称:主机名:端口号，比如PLAINTEXT表示明文传输、SSL表示使用SSL或TLS加密传输等。

注: Broker端和Client端应用配置中全部填写主机名。如果在某些地方使用了IP地址进行连接，可能会发生无法连接的问题。

3、replication.factor >= 3: 最好将消息多保存几份。

4、min.insync.replicas > 1: 控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于1可以提升消息持久性。

5、确保replication.factor > min.insync.replicas: 如果两者相等，那么只要有一个副本挂机，整个分区就无法正常工作了。推荐设置成replication.factor = min.insync.replicas + 1。

auto.create.topics.enable：是否允许自动创建Topic
这个问题在代码测试中遇到过，因为大小写没写对(尴尬)，自动就创建了一个新的Topic…设置为false就可以了。
unclean.leader.election.enable：是否允许Unclean Leader选举
unclean.leader.election.enable会关闭Unclean Leader选举。如果设置成false，会禁止落后太多的副本竞选Leader。假设保存数据比较多的副本都挂了，这样做的后果是这个分区就不可用了。反之如果是true，那么Kafka允许从那些“跑得慢”的副本中选一个出来当Leader。这样做的后果是数据有可能就丢失了，因为这些副本保存的数据本来就不全。
auto.leader.rebalance.enable：是否允许定期进行Leader选举
设置它的值为true表示允许Kafka定期地对一些Topic分区进行Leader重选举更换Leader，它要满足一定的条件才会发生。比如Leader A一直表现得很好，但若设置为true，那么有可能一段时间后Leader A就要被强行换成Leader B，原本向A发送请求的所有客户端都要切换成向B发送请求，这种换Leader本质上没有任何性能收益。
offsets.topic.replication.factor: 内部Topic__consumer_offset和__transaction_state的备份份数，建议设置大于1保证更高的可用性。

log.retention.{hour|minutes|ms}：控制一条消息数据被保存多长时间。从优先级上来说ms设置最高、minutes次之、hour最低。比如log.retention.hour=168表示默认保存7天的数据，自动删除7天前的数据。

1、acks参数指定了必须要有多少个分区副本收到消息，生产者才会认为消息写入是成功的。这个参数对消息丢失的可能性有重要影响。该参数有如下选项。

acks=0: 生产者在成功写入消息之前不会等待任何来自服务器的响应。也就是说，如果当中出现了问题，导致服务器没有收到消息，那么生产者就无从得知，消息也就丢失了。不过，因为生产者不需要等待服务器的响应，所以它可以以网络能够支持的最大速度发送消息，从而达到很高的吞吐量。
acks=1: 只要集群的Leader节点收到消息，生产者就会收到一个来自服务器的成功响应。如果消息无法到达Leader节点(比如Leader节点崩溃，新的Leader还没有被选举出来)，生产者会收到一个错误响应，为了避免数据丢失，生产者会重发消息。不过，如果一个没有收到消息的节点成为Leader，消息还是会丢失。这个时候的吞吐量取决于使用的是同步发送还是异步发送。
acks=all: 只有当所有参与复制的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应。这种模式是最安全的，它可以保证不止一个服务器收到消息，就算有服务器发生崩溃，整个集群仍然可以运行，它的延迟比acks=1时更高。

2、retries
生产者从服务器收到的错误有可能是临时性的错误(比如分区找不到Leader)。在这种情况下，retries参数的值决定了生产者可以重发消息的次数，如果达到这个次数，生产者会放弃重试并返回错误。

3、compression.type
默认情况下，消息发送时不会被压缩。该参数可以设置为snappy、gzip、lz4、Zstandard算法，它指定了消息被发送给broker之前使用哪一种压缩算法进行压缩。

暂时就用到这么多，后面有啥用到的再补充吧😳