Kafka笔记

Producer：

Broker：

Topic：

Partition：

Replication：

Message：

Consumer Group：

Consumer：

1.Kafka将消息以topic为单位进行归纳

2.将向Kafka topic发送消息的程序称为Producers

3.将从Kafka topic订阅并消费消息的程序称为Consumers

4.Kafka是以集群形式运行的，可以由一个或者多个服务组成，每一个服务叫做broker

生产者采用push

消费者采用pull

采用pull也有一个缺点，就是当borker没有消息时，消费者会进入不断的轮询，为了避免这点，Kafka设置了个参数，让消费者阻塞，然后判断是否有新消息到达

ZK用来存放集群元数据、成员管理、Controller选举

存放集群元数据：分区所有数据都保存在ZK中，且以它保存的数据为权威，其他人都要和他对齐

成员管理：Broker节点的注册、注销、属性变更

Controller选举：选举集群Controller

每个主题中的每个消息都被赋予了唯一的ID数值，用于标识它在分区中的位置，

1.PageCache

2.顺序写

3.零拷贝

4.批量处理，合并小的请求，以流的形式进行交互

5.pull拉取模式

1：数据发送到Kafka之后，经过leader的成功确认，就算是发成功了，如果leader宕机了，容易丢数据

0：数据发出去就不管了，不去等待任何返回，这种数据传输效率最高，但是消息可靠性低

-1：Producer需要等待ISR中所有的follower都确认收到消息后，才算成功，可靠性最高。

当ISR中所有的Replica都像leader发ack时，leader才commit，这时候producer才认为这个消息发送成功了

消费者导致的：消费者刚接收到消息，服务器宕机了，解决办法：关闭offset自动提交

生产者导致的：消息发送出去，由于网络原因导致丢失，解决办法：等待所有follower的ack之后，才算发送成功  acks=all

Kafka导致的：Kafka的leader接到消息，正准备同步给follower，结果宕机了，follower中进行选举，这部分的消息就丢失了

解决办法：

1.给topic设置参数replication.factor，这个值大于1，要求每个partition必须有至少两个副本

2.在kafka服务端设置min.insync.replicas，这个值大于1，要求leader必须确保有一个follower和他保持联系，这样确保leader挂了，还有人上

3.producer设置acks=all 

4.producer设置retryies=MAX     无限重试

消息在Kafka中的顺序性：比如说创建了一个topic，有三个partition，生产者在写数据的时候，可以指定一个key，比如订单topic，我们可以指定订单的id作为key，那么相同订单的mq就进入了同一个partition，而这个partition中的数据一定是有序的

消费者处理消费时顺序性：每个topic的一个partition，只能被同组内部一个consumer消费，如果是单线程的话消费没有问题，但是大量mq处理的情况下，如果还是单线程就太慢了，所以要开启多线程，但开启多线程如何保证消息的有序性呢，这里要开启N个内存Queue，然后具有相同key的消息都会被放在同一个内存Queue中，然后开启N个线程，每个线程对应一个内存Queue，这样就能保证消息的有序性了

ISR：副本同步列表，有两个维度（延迟时间和延迟条数），任意一个超过阈值，都会被剔除出ISR，然后加入到OSR

OSR：副本不同步列表，新加入的follower也会进入OSR

AR：所以副本  ISR + OSR

只有leader副本可以对外提供读写服务，响应client端的请求，follower采用pull的形式，被动的同步leader副本中的数据

加分项：强调follower副本也能对外提供读服务。自Kafka2.4版本之后，follower副本也能对外提供有限的读服务

有四种选举策略，但其大致思想都一致，即从AR中挑选首个在ISR中的副本，作为新的leader

在Kafka中，生产者和消费者都是和leader进行交互的，模式就是主读主写

Kafka为什么不支持读写分离：

1.数据一致性：数据写到leader上，follower从leader拉取数据，这个时间段，leader和follower的数据是不一致的

2.延时问题：网络 -》主节点内存 -》主节点磁盘 -》网络 -》从节点内存 -》从节点磁盘   非常耗时！

redis：网络 -》主节点内存 -》网络 -》从节点内存     没有磁盘的加入，所以速度会快一点

顺序读写、分段命令、二分查找

HW：高水位，指消费者只能消费到这个offset之前的数据

LEO：标识当前日志文件中下一条待写入消息的offset

HW去解决这个问题

1.节点必须维护和zk的连接，通过心跳机制检查每个节点的连接

2.如果节点是个follower，他必须能够及时同步leader的写数据，延时不能太久

 B