Kafka相关（一）

Kafka是一个高性能的分布式发布订阅消息系统，其实activeMq，RabbitMq，kafka都比较类似。

其解决的问题：解耦、异步、削峰，以及对应的场景
小知识：mysql每秒处理2000个请求已经差不多了
activeMq，rabbitMq，rocketMq，kafka优缺点比较，从单机吞吐量、时效性、可用性、消息可靠性四个方面分析：

吞吐量：activeMq和rabbitMq是每秒万级，后两者是十万级
时效性：除了rabbitMq是微秒级的，其他的三个都是毫秒级的
可用性：都是高可用性，前两者是主从架构，后两者是分布式架构，其中kafka的数据多个副本存在不同的broker上，少量机器宕机不影响使用
消息可靠性：前两者有较低概率丢失数据，后两者通过参数配置，可以做到0丢失

kafka与传统mq之间的区别？
1、持久化的日志，无限保留。
2、分布式系统
3、支持实时的流式处理

发布订阅消息系统都需要面临三个问题，数据丢失、重复消费、顺序消费：

如何减少数据丢失？
Kafka0.8版本以前是没有副本机制的，相当于镜像集群模式，每一个节点都拥有了所有的数据，每一个节点宕机，其他的节点可以保证正常的使用。
但是0.8版本及之后，有了副本机制，kafka由多个broker组成，一个broker认为是一个节点，一个topic，由多个（partition）分区组成，数据分布在多个分区上，为了高可用性，每个分区都存在多个副本，不同的副本存在于不同的broker上，副本之间存在leader和follower，生产者是会和leader进行交互，follower从leader拉取数据，保证和leader的数据一致，这样一个broker宕机后，如果某个分区的的leader挂掉，由于其他broker上有副本存在，那个只需要重对应的副本选举出leader即可。
这里面需要注意，一个是保证分区均匀的分布在不同的broker上保证高可用性，第二个也需要保证同一个分区的副本存在于不同的broker上，不然也是会出现数据丢失的。
第二个是确认机制，有三种，分别是0,1，all三种，0：生产者发出消息后，不保证kafka已经收到消息，发出即不管。1：生产者发出消息后，kafka返回确认消息，此时算发送成功。All:生产者发出消息，kafka需要保证除了leader收到消息，且follower也全部同步过去后，才返回确认收到。kafka默认是1。

如何保证数据不重复消费？
数据的不重复消费，常规可以通过两种方式来实现，一种是数据库的主键来约束，避免重复插入，一种可以通过redis存下唯一标识来限制。

如何保证顺序消费消息？
kafka的不同的分区上是无法保证顺序的，所以要保证顺序消费消息，需要做到生产者保证消息每次都发到一个分区，有两种方式，一种是一个topic只创建一个分区，第二种是生产者发送消息时指定发送到哪个分区。
kafka如何保证单个分区有序的，是通过加锁保证有序。
有两种场景：
一种是broker leader给producer发送ack时，因为网络原因超时，此时生产者会进行重试，造成消息重复。
一种是先后两条消息发送，第一条消息发送失败，第二条消息发送成功，然后第一条消息重试后发送成功，造成乱序。
为了解决重试引入的数据重复和乱序问题，kafka引入了 Producer ID（PID）和Sequence Number。对于每一个PID，该生产者发送消息的每个<topic,partion> 都会对应一个单调递增的Sequence Number。
同样broker端也会为每一个<PID,Topic,Partition>维护一个序号，并且每条消息commit成功，都会将其序号递增。对于接收的每条消息，如果其序号比Broker维护的需要大一，则broker会接受，否则将其丢弃。如果消息序号比broker维护的序号差值比1大，则说明中间有数据尚未写入，此时数据为乱序，broker拒绝该消息，producer抛出InvalidSequenceNumber异常，表示非法的序列号。如果消息序号小于等于broker维护的序号，说明该消息已经被保存，即为重复消息，broker直接丢弃该消息，producer抛出DuplicateSequenceNumber。

出现消费者故障，出现活锁问题？
kafka消费者正常情况下是订阅一个topic并且可以poll消息，一个topic下的分区只能被一个消费者占有，消费定期向zookeeper发送心跳检测，证明自己活着。但是如果一个消费者占据了一个分区后，正常发送心跳，但是不poll消息，这种情况下就是活锁现象。
如何解决活锁？kafka可以配置一个活跃检测机制，配置参数是max.poll.interval.ms，如果客户端poll消息的时间间隔超过了设置的最大间隔，就会和当前客户端断开连接，让其他消费者过来消费。但是这样也会引入新的问题，如果消费者处理消息过慢，在一定时间内没有处理完消息，没有poll操作，此时会被断开连接，触发rebalance，所以为了保证消息正常消费，可以合理设置poll超时时长和每次拉取的数据条数spring.kafka.consumer.max-poll-records