14.音讯队列

《深刻了解Kafka 外围设计与实际原理》

Kafka

说一下Kafka

Kafka是一款高性能的消息中间件，包含Producer,Consumer,Broker，以及Zookeeper，Zookeeper用来负责集群元数据管理，控制器的选举等操作，Producer将音讯发送到Broker，由Broker负责将收到的音讯存储到磁盘中，Consumer负责从Broker订阅并生产音讯。Kafka中的音讯是以主题为单位，主题能够散布在不同的分区，分区能够散布于不同的Broker，分区有Leader 与正本follower，follower负责从leader同步数据，leader负责读写申请

音讯的幂等性解决思路

次要是避免音讯反复生产，通过业务方去保障音讯的幂等性，每条音讯设置一个惟一Id，数据库的话通过惟一索引。

音讯队列如何保障高可用

kafka能够有多个Borker，一个topic会将数据存储在不同的partiton上, 并且有多个副原本同步数据，但只会有一个leader，数据以Log的模式存储在硬盘中，并且记录了生产的offset。如果leader挂掉，会从ISR汇合中的正本选出一个做为leader。

Kafka 新建的分区会在哪个目录下创立

在启动Kafka集群之前，咱们须要配置好log.dirs参数，其值是kafka数据的寄存目录，这个参数能够配置多个目录，目录之间应用逗号分隔，通常这些目录是散布在不同的磁盘上用于进步读写性能。

也能够配置log.dir参数，含意一样，只须要设置其中一个即可。如果log.dirs参数只配置了一个目录，那么调配到各个Broker上的分区必定只能在这个目录下创立文件夹用于存储数据。

然而如果log.dirs参数配置了多个目录，Kafka会在含有分区目录起码的文件夹中创立新的分区目录，分区目录名为Topic名 + 分区ID。留神，是分区文件夹总数起码的目录，而不是磁盘使用量起码的目录

Kafka的 ack 机制

ack 有三个值 0 1 -1

0 : 生产者不会期待borker返回，提早最低然而存储的保障最弱当server挂掉的时候就会丢数据

1 : 期待leader确认音讯返回，但如果Leader挂掉后不保障是否复制实现

-1: 期待所有的正本确认音讯返回

如何保障音讯可靠性

kafka保障音讯可靠性，能够通过如下几个配置:

生产者配置 acks = all (-1) ISR中的所有正本都写入胜利，才代表该音讯发送胜利
min.insync.replicas默认为1，指定了ISR汇合中最小的正本数，不满足条件就会抛出NotEnoughReplicasException 或 NotEnoughReplicasAfterAppendException,也就是必须保障有一个正本同步数据跟得上leader
unclean.leader.election.enable 默认为false, 当leader下线的时候能够从非ISR汇合中选举新的leader，这样能进步可用性，但会丢数据
配置log.flush.interval.messages 和 log.flush.interval.ms 同步刷盘策略
生产端手动提交位移，enable.auto.commit 设置为false，主动提交会带来反复生产和音讯失落的问题，客户端如果音讯生产失败应该放入死信队列，以便前期排除故障
回溯生产性能，音讯貌似曾经胜利生产，但理论音讯失败了，不晓得是什么谬误造成的，就能够通过回溯生产弥补，或者复现 “失落”，seek()办法

音讯积压问题

如果音讯积压了太多，始终生产不了，须要查看是不是consumer有问题，或者服务端磁盘是否快满了。

consumer有问题就修复问题。但因为积压的数据太多，用原程序生产还是太慢。就须要扩容，新建长期topic,将分区改为原来的10倍，写程序将原来积压的音讯发送到新建的topic中，启动10倍的机器来生产这些数据
服务端磁盘满，就只能扩容服务端磁盘，再采纳第一种方法来修复问题

kafka的分区策略

消费者客户端参数partition.assignment.strategy 来配置生产分区策略

RangeAssignor 默认调配策略通过分区数/消费者总数来取得一个跨度进行调配
RoundRobinAssignor 轮询调配策略
StickyAssignor 可能使分区的调配尽可能与上一次保持一致，防止适度重调配
自定义调配，实现PartitionAssignor接口