Kafka é um dos middlewares mais comumente usados para filas de mensagens MQ. Seus principais recursos são: desacoplamento, assíncrono, limitação de corrente/recorte de pico.
Tanto o Kafka quanto os sistemas de mensagens tradicionais (também chamados de middleware de mensagens) têm funções como desacoplamento de sistema, armazenamento redundante, redução de pico de tráfego, buffer, comunicação assíncrona, escalabilidade e capacidade de recuperação. Ao mesmo tempo, Kafka também fornece garantia de sequência de mensagens e funções de consumo retroativo que são difíceis de alcançar na maioria dos sistemas de mensagens.
2. Conceitos comuns de Kafka
2.1 Tópico e Partição
O tópico é um conceito lógico
e não está armazenado fisicamente. Usado principalmente para descrever um tipo de mensagem. Por exemplo, temos um sistema empresarial que enviará uma mensagem descrevendo o status do pedido do usuário, então todas as mensagens deste tipo são um Tópico . Por exemplo, este sistema empresarial também enviará uma mensagem descrevendo o saldo do membro, então este é um novo mensagem. Digite, ou seja, um novo Tópico .
Partição
é um conceito físico que realmente existe no dispositivo físico. Um tópico consiste em múltiplas partições. A partição existe para melhorar o desempenho e o rendimento das mensagens. A velocidade de processamento de mensagens de múltiplas partições e múltiplos processos é definitivamente muito mais rápida do que a de uma única partição.
2.2 Corretor e Partição
Como uma implementação distribuída, o Broker pode, na verdade, ser entendido simplesmente como um processo Kafka é um Broker.
Mencionamos antes que a partição existe fisicamente e sua localização física está no Broker. Ao mesmo tempo, para que o serviço tenha um certo grau de confiabilidade, cada partição possui várias cópias, e cada cópia existe em um Broker diferente.
O tópico que mencionamos antes é um conceito lógico e não tem existência física. Cada TopicA-x na figura é uma partição, e o número a seguir representa o número de réplicas em uma partição. Cada Broker possui Existem réplicas diferentes. O objetivo é que quando um Broker fica inativo, outras réplicas ainda existem para garantir a disponibilidade do sistema.
Além disso, uma das múltiplas partições de réplica será selecionada como líder e as outras como seguidoras. Quando nossos produtores enviam dados, eles os enviam diretamente para a partição líder e, em seguida, a partição seguidora irá para o líder para sincronizar os dados por si só.Quando os consumidores consomem dados, eles também consomem dados do líder.
As réplicas estão em corretores diferentes. Quando a réplica líder falha, uma nova réplica líder é reeleita da réplica seguidora para fornecer serviços externos. Kafka implementa failover automático por meio de um mecanismo de múltiplas réplicas e ainda pode garantir a disponibilidade do serviço quando um agente no cluster Kafka falha.
2.3 Produtores, consumidores e ZooKeeper
A função ou sistema que gera mensagens é chamado de produtor. Por exemplo, se um dos sistemas de negócios acima gerar mensagens relevantes sobre o status do pedido, então o sistema de negócios é o produtor.
Um consumidor é uma função ou sistema responsável por receber ou usar mensagens.
ZooKeeper é usado por Kafka para gerenciar metadados de cluster, eleger controladores e outras operações. O Produtor envia mensagens para o Broker, o Broker é responsável por armazenar as mensagens recebidas em disco e o Consumidor é responsável por assinar e consumir mensagens do Broker.
Quando cada Broker for iniciado, ele registrará informações com ZK. ZK selecionará o Broker registrado mais antigo como Controlador. Posteriormente, o Controlador interagirá com ZK para obter metadados (ou seja, as informações de todo o cluster Kafka, como aqueles Brokers , cada qual partição e outras informações existem em cada Broker), e então outros Brokers interagem com o Controlador e todos os Brokers podem perceber todas as informações de todo o cluster.
2.4 Grupo de Consumidores
Atualmente, a maioria das arquiteturas de sistemas de negócios são distribuídas, ou seja, um aplicativo implantará vários nós. Normalmente, uma mensagem deve ser consumida apenas por um dos nós, e não deve ser consumida por todos os consumidores ao mesmo tempo. Assim nasceu o conceito de grupo de consumidores.Em um grupo de consumidores, uma mensagem será consumida apenas por um consumidor do grupo de consumidores.
Em termos de uso, um aplicativo geralmente é configurado como um grupo de consumidores, ou diferentes grupos de consumidores podem ser configurados para diferentes ambientes em um aplicativo. Por exemplo,nós no ambiente de produção e nós no ambiente de pré-lançamento podem ser configurados com dois conjuntos de grupos de consumidores.Desta forma,quando novas alterações são implementadas no pré-lançamento,mesmo que esta alteração modifique a lógica relevante do ação de consumo, não afetará os dados de produção.
O modelo de consumidores e grupos de consumidores permite que o poder de consumo geral seja escalonável horizontalmente.Podemos aumentar (ou reduzir) o número de consumidores para aumentar (ou reduzir) o poder de consumo geral. Para um número fixo de partições, a adição cega de consumidores nem sempre melhorará a capacidade de consumo. Se houver muitos consumidores e o número de consumidores for maior que o número de partições, alguns consumidores não serão alocados. Referindo-se à figura abaixo (canto inferior direito), há um total de 8 consumidores e 7 partições.Então o consumidor final C7 não pode consumir nenhuma mensagem porque não tem nenhuma partição alocada.
2.5 ISR, HW, LEO
Kafka usa o mecanismo ISR para tentar garantir que as mensagens não serão perdidas.
Todas as réplicas em uma partição são chamadas de AR (réplicas atribuídas) e todas as réplicas (incluindo a réplica líder) que mantêm um certo grau de sincronização com a réplica líder constituem ISR (réplicas sincronizadas) . Como mencionamos acima, a cópia do seguidor é responsável apenas pela sincronização das mensagens. Em muitos casos, as mensagens na cópia do seguidor ficarão atrasadas em relação à cópia do líder. Aqueles que mantêm a consistência dos dados com a cópia do líder em tempo hábil podem se tornar membros do ISR. As réplicas que estão muito atrasadas na sincronização com a réplica líder (excluindo a réplica líder) formam OSR (réplicas fora de sincronia) .Pode-se observar que AR =ISR+OSR . Em circunstâncias normais, todas as cópias seguidoras devem manter um certo grau de sincronização com a cópia líder, ou seja, AR=ISR e o conjunto OSR está vazio.
A cópia líder monitorará todas as cópias seguidoras. Quando os dados forem consistentes com a cópia líder, eles serão adicionados ao membro do ISR. Quando forem muito diferentes da cópia líder ou estiverem inativos, serão expulsos do ISR. Ele também alcançará a cópia do líder. Junte-se novamente ao ISR.
Quando a cópia do líder está inativa ou indisponível, apenas os membros do ISR podem ter a oportunidade de serem selecionados como a nova cópia do líder. Isso garante que o novo líder seja consistente com os dados do líder que foi desativado. No entanto, se a cópia estiver inativa. o OSR for selecionado como líder, como resultado, alguns dados não sincronizados serão perdidos.
Na situação acima, a réplica P1 foi eleita líder primeiro, e apenas a réplica P2 sincronizou os dados de P1, e o deslocamento é 110. Então o ISR neste momento só tem P1 e P2, e o OSR tem P3 e P4 . Quando P3 sincroniza dados para 110, eles também serão adicionados ao ISR pelo líder. Se o líder cair neste momento, um novo líder será selecionado do ISR e P0 será expulso do ISR.
那么leader是如何感知到其他副本是否与自己数据一致呢？
靠的就是HW与LEO机制。
LEO 是 Log End Offset 的缩写，它标识当前日志文件中下一条待写入消息的 offset，LEO 的大小相当于当前日志分区中最后一条消息的 offset 值加 1。分区 ISR 集合中的每个副本都会维护自身的 LEO，而 ISR 集合中最小的 LEO 即为分区的 HW，HW 是 High Watermark 的缩写，俗称高水位，它标识了一个特定的消息偏移量(offset)，消费者只能拉取到这个 offset 之前的消息。
上图中，因为所有副本消息都是一致的，所以所有LEO都是3，HW也为3，当有新的消息产生时，即leader副本新插入了3/4两条消息，此时leader的LEO为5，两个follower的此时未同步消息，所以LEO仍未3，HW选择最小的LEO是3.
当follower1同步完成leader的数据后，LEO未5，但follower2未同步，所以此时HW仍未3。此后follower2同步完成后，其LEO为5，所有副本的LEO都未5，此时HW选择最小的为5。
通过这种机制，leader副本就能知道哪些副本是满足ISR条件的（该副本LEO是否等于leader副本LEO）。
3.1 注册信息
Kafka强依赖与ZooKeeper以维护整个集群的信息，因此在启动前应该先启动ZooKeeper。
在ZK启动完成之后，所有的Broker(即所有的Kafka进程)都会向ZK注册信息，然后争取/controller的监听权，获取到监听权的Broker称为Controller，此后由Controller与ZK进行信息交换，所有的Broker与Controller进行消息交换。进而保持整个Kafka集群的信息一致性。
3.2 创建主题
在所有的Broker注册完毕后，需要注册主题（Topic）以继续后续流程。
其中某个客户端接收到创建Topic请求后，会将请求中的分区方案(有几个分区、几个副本等)告诉ZK，ZK再将信息同步至Controller，此后所有的Broker与Controller交换完元数据，至此所有的Broker都已经知道该Topic的分区方案了，然后按照该分区方案创建自己的分区或副本即可。
以上就是某一个broker下面的某一个主题的分布情况
3.3 生产者发送数据
在创建完想要的Topic之后，生产者就可以开始发送数据。
3.3.1 封装ProducerRecord
首先生产者会将信息封装成ProducerRecord
private final String topic;private final Integer partition;private final Headers headers;private final K key;private final V value;private final Long timestamp;
其中主要包好了要发送的Topic名称，要发送至那个分区，以及要发送的数据和key。
其他的都比较好理解，key的作用是如果key存在的话，就会对key进行hash，然后根据不同的结果发送至不同的分区，这样当有相同的key时，所有相同的key都会发送到同一个分区，我们之前也提到，所有的新消息都会被添加到分区的尾部，进而保证了数据的顺序性。
例如我们有个关于会员的业务系统，其中生产者会产生关于某个会员积分的信息，消费者拿到这个消息之后会实际对积分进行操作。假如某个会员先获得了100积分，然后又消费了50积分。因此生产者会发送两个MQ消息，但是假如没有使用key的功能，这两个消息被发送到了不同的分区，因为每个分区的消费水平不一样（例如获得积分的逻辑耗时比较长而某个分区又都是获得积分的MQ），就有可能造成消费50积分的MQ会先被消费者收到。
而假如此时会员积分为0的情况下再去消费50积分明显是不合理且逻辑错误的，会造成业务系统异常。因此在生产者发送MQ时如果消息有顺序性要求则一定要将key赋值，具体的可以是某些有唯一性标识例如此处可以是会员ID。
3.3.2 序列化数据、获取元数据、确定分区
首先生产侧客户端的序列化器会将要发送的ProducerRecord对象序列化成字节数组 ，然后发送到消费端后消费端的反序列化器会将字节数组再转换成对应的消费对象。常用的序列化器有String、Doule、Long等等。
其次也可以自定义序列化器与反序列化器，例如可以将将字节数组进行加密后再进行传输，以此保证数据的安全性。
数据都准备完成之后就可以开始获取broker元数据，例如host等，以方便后续确定要发送的位置。
-
如果ProducerRecord中指定了要发往那个分区，则选择用户使用的分区
-
如果没有指定分区，则查看ProducerRecord中key是否为空，如果不为空则对key进行计算以获取使用那个分区
-
如果key也为
空，则按照轮询的方式发送至不同的分区
3.3.3 写入缓冲区、分批分送消息
生产者发送的MQ并不会直接通过网络发送至broker，而是会先保存在生产者的缓冲区。
然后由生产者的Sender线程分批次将数据发送出去，分批次发送的原因是可以节省一定的网络消耗与提升速度，因为一次发送一万条与一万次发送一条肯定效率不太一样。
分批次发送主要有两个参数，批次量与等待时间。两个参数主要是解决两个问题，一个是防止一次发送的消息量过大，比如一次可能发送几十mb的数据。另一个解决的问题是防止长时间没有足够消息产生而导致的消息一直不发送。因此当上述两个条件任意满足其一就会触发这一批次的发送。
Kafka的网络模型用的是加强版的reactor网络模型
首先客户端发送请求全部会先发送给一个Acceptor，broker里面会存在3个线程（默认是3个），这3个线程都是叫做processor，Acceptor不会对客户端的请求做任何的处理，直接封装成一个个socketChannel发送给这些processor形成一个队列，发送的方式是轮询，就是先给第一个processor发送，然后再给第二个，第三个，然后又回到第一个。消费者线程去消费这些socketChannel时，会获取一个个request请求，这些request请求中就会伴随着数据。
线程池里面默认有8个线程，这些线程是用来处理request的，解析请求，如果request是写请求，就写到磁盘里。读的话返回结果。processor会从response中读取响应数据，然后再返回给客户端。这就是Kafka的网络三层架构。
所以如果我们需要对kafka进行增强调优，增加processor并增加线程池里面的处理线程，就可以达到效果。request和response那一块部分其实就是起到了一个缓存的效果，是考虑到processor们生成请求太快，线程数不够不能及时处理的问题。
3.4 消费者消费数据
-
-
3.4.1 信息注册
首先消费者组内所有消费者都会向集群寻找自己的Coordinator（以消费者组id做均衡）。找到Coordinator后，所有的Consumer都会向Coordinator发起join group加入消费者组的请求，Coordinator会选择一个最早发起请求的Consumer作为leader Consumer，其他的Consumer作为follower。
leader会根据要消费的Topic及分区情况制定一个消费方案，告知给Coordinator，Coordinator再将此消费方案告知给各个follower。
自此，所有的Consumer都已经知道自己要消费那个分区了。
3.4.2 消费信息
1）拉取消息
常用的消息队列的消费消息一般有两种，推送或者拉取，Kafka在此处用的是拉取模式。
try { while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(100)); for (ConsumerRecord<String, String> record : records) { int updateCount = 1; if (map.containsKey(record.value())) { updateCount = (int) map.get(record.value() + 1); } map.put(record.value(), updateCount); } }}finally { consumer.close();}
2）反序列化与消费消息
在上面的代码中，我们拿到的就是ConsumerRecord对象，但是实际上这个是消费者客户端帮我们做的反序列化的操作，将字节数组(byte[])反序列化成了对象。参考3.3.2我们也可以自定义反序列化器。
3）提交消息位移
例如当消息队列中有100条消息，消费者第一次消费了20条消息，那么第二次消费的位置肯定是要从第21条消息开始消费，而记录第21条消息的信息称之为offset，offset为已经消费位置+1.
在之前版本的客户端，offset数据被存在zk中，每次都需要请求zk获取数据，而zk并不适合作为高并发的请求。因此在现在的版本中，kafka通过建立一个Topic来记录所有消费者消费的offset，这个Topic是__consumer_offsets。每一个消费者在消费数据之前（即pol()方法中），都会把上一次消费数据中最大的offset提交到该Topic中，即此时是作为生产者的身份投递信息。
kafka中有几种offset提交模式，默认的是自动提交：
enable.auto.commit设置为true时，每隔 auto.commit.interval.ms时间会自动提交已经已经拉取到的消息中最大的offset。
但是默认的自动提交也会带来重复消费与消息丢失的问题：
-
重复消费。例如从offset为21开始拉取数据，拉取到了40，但是当消费者处理到第30条数据的时候系统宕机了，那么此时已经提交的offset仍为21，当节点重新连接时，仍会从21消费，那么此时21-30的数据就会被重新消费。还有一种情况是再均衡时，例如有新节点加入也会引发类似的问题。
-
public static void main(String[] args) { while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(3000)); records.forEach((ConsumerRecord<String, String> record) -> { System.out.println("revice: key ===" + record.key() + " value ====" + record.value() + " topic ===" + record.topic()); }); try { consumer.commitSync(); } catch (CommitFailedException e) { e.printStackTrace(); } }}
手动同步提交可以在任何时候提交offset，例如可以每消费一条进行一次提交。提交失败之后会抛出异常，可以在异常中做出补偿机制，例如事务回滚等操作。
但是因为手动同步提交是阻塞性质的，所以不建议太高的频率进行提交。
@Testpublic void asynCommit1(){ while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(3000)); records.forEach((ConsumerRecord<String, String> record) -> { System.out.println("revice: key ===" + record.key() + " value ====" + record.value() + " topic ===" + record.topic()); }); consumer.commitAsync(); }}
@Testpublic void asynCommit2(){ while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(3000)); records.forEach((ConsumerRecord<String, String> record) -> { System.out.println("revice: key ===" + record.key() + " value ====" + record.value() + " topic ===" + record.topic()); }); consumer.commitAsync(new OffsetCommitCallback(){ @Override public void onComplete(Map<TopicPartition, OffsetAndMetadata> offsets, Exception exception) { if (exception!=null){ System.out.println(String.format("提交失败:%s", offsets.toString())); } } }); }}
@Testpublic void asynCommit3(){ while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(3000)); records.forEach((ConsumerRecord<String, String> record) -> { System.out.println("revice: key ===" + record.key() + " value ====" + record.value() + " topic ===" + record.topic()); }); consumer.commitAsync((offsets, exception) ->{ if (exception!=null){ System.out.println(String.format("提交失败:%s", offsets.toString())); } }); }}
异步提交 commitAsync() 与同步提交 commitSync() 最大的区别在于异步提交不会进行重试，同步提交会一直进行自动重试，当然也可以通过再发生异常时继续提交的方式来完成此功能。
while (true) { ConsumerRecords records = consumer.poll(100); for (ConsumerRecord record : records) { log.trace("Kafka消费信息ConsumerRecord={}",record.toString()); } try { consumer.commitAsync(); } catch (CommitFailedException e) { log.error("commitAsync failed", e) } finally{ try { consumer.commitSync(); } catch (CommitFailedException e) { log.error("commitAsync failed", e) } finally{ consumer.close(); } }}
4.1 异常重试
我们系统之前遇到过消费者在消费消息时，短时间内连续报错。根据现象以为是系统出现问题，后续发现所有报错都是同一条消息，排查后发现是处理消息过程中存在未捕获的异常，导致消息重试，相同的问题引发了连续报错。
JMQ在消费过程中如果有未捕获的异常会认为消息消费失败，会首先在本地重试两次后放入重试队列中，进入重试队列的消息，会有过期逻辑，当超过重试时间或者超过最大重试次数后(默认3天过期)，消息将会被丢弃。因此在处理消息时需要考虑如果出现异常后的处理场景，选择是重试还是忽略还是记录数据后告警。
因此我们在消费消息的过程中，尤其是采用pull模式，一定要根据业务场景注意异常的捕获。否则小则影响本条消息，大则本批次后续所有消息都可能丢失。
ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(60L));for (ConsumerRecord<String, String> record : records) { try { } catch (Exception e) { log.error("Bdp监听任务执行失败, taskName:{}", taskName, e); }}
4.2 本地重试与服务端重试
系统还遇到过在JMQ服务端配置了消费失败重试的逻辑，例如重试多少次间隔多久，但是在消费失败之后，发现重试的逻辑并没有按照配置的逻辑走。联系运维帮忙排查后发现：
根据4.1我们知道消费失败后，会首先在本地重试，本地重试失败后会放入重试队列，则此时进入服务端重试，两套重试需要两套配置，本地的重试配置在本地的配置文件中。
<jmq:consumer id="apiConsumer" transport="jmq.apilog.transport"> <jmq:listener topic="${jmq.topic.apilog}" listener="apiLogMessageListener" retryDelay="1000" maxRetrys="3"/></jmq:consumer>
-end-
