Kafka は、 MQ メッセージ キューで最も一般的に使用されるミドルウェアの 1 つで、主な機能はデカップリング、非同期、電流制限/ピーク クリッピングです。
Kafka と従来のメッセージング システム (メッセージ ミドルウェアとも呼ばれる) はどちらも、システムの切り離し、冗長ストレージ、トラフィックのピークカット、バッファリング、非同期通信、スケーラビリティ、回復可能性などの機能を備えています。同時に、Kafka は、ほとんどのメッセージング システムでは実現が難しいメッセージ シーケンスの保証と遡及的な消費機能も提供します。
2.1 トピックとパーティション
トピックは論理的な概念であり
、物理的に保存されません。主にメッセージの種類を説明するために使用されます。たとえば、ユーザーの注文ステータスを説明するメッセージを送信するビジネス システムがあるとします。このタイプのメッセージはすべてTopic です。たとえば、このビジネス システムは、メンバーの残高を説明するメッセージも送信します。この場合、これは新しいトピックです。メッセージを入力します。つまり、新しいトピックを入力します。
パーティションは
、物理デバイス上に実際に存在する物理概念です。トピックは複数のパーティションで構成されます。メッセージのパフォーマンスとスループットを向上させるためにパーティションが存在します。複数のパーティションと複数のプロセスのメッセージ処理速度は、単一パーティションの場合よりも明らかに高速です。
2.2 ブローカーとパーティション
分散実装である Broker は、実際には Kafka プロセスが Broker であると単純に理解できます。
パーティションは物理的に存在し、その物理的な場所はブローカー内にあると前述しました。同時に、サービスにある程度の信頼性を持たせるために、各パーティションには複数のコピーがあり、各コピーは異なるブローカーに存在します。
先ほど説明したトピックは論理的な概念であり、物理的な存在はありません。図の各トピックA～x はパーティションであり、次の数字はパーティション内のレプリカの数を表します。各ブローカーには異なるレプリカがあります。その目的はブローカーがダウンしても、システムの可用性を確保するために他のレプリカがまだ存在します。
さらに、複数のレプリカ パーティションのうち 1 つがリーダーとして選択され、他のパーティションはフォロワーとして選択されます。プロデューサーがデータを送信するとき、リーダー パーティションに直接送信し、その後、フォロワー パーティションがリーダーに移動してデータを自動的に同期します。コンシューマーがデータを消費するとき、リーダーからのデータも消費します。
レプリカは異なるブローカーにあり、リーダー レプリカに障害が発生すると、外部サービスを提供するためにフォロワー レプリカから新しいリーダー レプリカが再選択されます。Kafka はマルチレプリカ メカニズムを通じて自動フェイルオーバーを実装しており、Kafka クラスター内のブローカーに障害が発生した場合でもサービスの可用性を確保できます。
2.3 生産者、消費者、および ZooKeeper
メッセージを生成する役割またはシステムはプロデューサーと呼ばれます。たとえば、上記のビジネス システムの 1 つが注文ステータスに関する関連メッセージを生成する場合、そのビジネス システムはプロデューサーです。
コンシューマは、メッセージの受信または使用を担当する役割またはシステムです。
ZooKeeper は、クラスターのメタデータの管理、コントローラーの選択、およびその他の操作のために Kafka によって使用されます。プロデューサーはメッセージをブローカーに送信し、ブローカーは受信したメッセージをディスクに保存する責任を負い、コンシューマーはブローカーからのメッセージをサブスクライブして消費する責任を負います。
各ブローカーが起動すると、ZK に情報が登録されます。ZK は、最も早く登録されたブローカーをコントローラーとして選択します。その後、コントローラーは ZK と対話してメタデータ (つまり、これらのブローカーなどの Kafka クラスター全体の情報) を取得します。 、各ブローカーに存在する各パーティションとその他の情報）、その後、他のブローカーがコントローラーと対話し、すべてのブローカーがクラスター全体のすべての情報を認識できるようになります。
2.4 消費者グループ
現在、ほとんどのビジネス システム アーキテクチャは分散型です。つまり、アプリケーションは複数のノードを展開します。通常、メッセージはノードの 1 つによってのみ消費されるべきであり、すべてのコンシューマによって同時に消費されるべきではありません。そこで、コンシューマ グループという概念が生まれ、コンシューマ グループでは、メッセージはコンシューマ グループ内の 1 人のコンシューマのみによって消費されます。
使用法に関しては、通常、1 つのアプリケーションがコンシューマー グループとして構成されますが、アプリケーション内の異なる環境に対して異なるコンシューマー グループを構成することもできます。たとえば、運用環境のノードとプレリリース環境のノードを 2 セットのコンシューマ グループで構成できます。このようにして、新しい変更がプレリリースでデプロイされると、この変更によって関連するロジックが変更される場合でも、消費アクションなので、生産データには影響しません。
消費者と消費者グループのモデルでは、全体の消費電力を水平方向にスケーラブルにすることができ、消費者の数を増やす（または減らす）ことで全体の消費電力を増やす（または減らす）ことができます。パーティションの数が固定されている場合、コンシューマをやみくもに追加しても消費容量が必ずしも向上するとは限りません。コンシューマが多すぎてコンシューマの数がパーティションの数よりも大きい場合、一部のコンシューマは割り当てられません。以下の図 (右下) を参照すると、合計 8 つのコンシューマと 7 つのパーティションがあり、最後のコンシューマ C7 にはパーティションが割り当てられていないため、メッセージを消費できません。
2.5 ISR、HW、LEO
Kafka は、ISR メカニズムを使用して、メッセージが失われないように努めます。
パーティション内のすべてのレプリカはAR (Assigned Replica)と呼ばれ 、リーダーレプリカと一定の同期を保つすべてのレプリカ (リーダーレプリカを含む) はISR (In-Sync Replica)を構成します。上で述べたように、フォロワー コピーはメッセージの同期のみを担当します。多くの場合、フォロワー コピー内のメッセージはリーダー コピーよりも遅れます。リーダー コピーとのデータの一貫性をタイムリーに維持する人が ISR メンバーになることができます。リーダー レプリカとの同期が遅すぎるレプリカ (リーダー レプリカを除く) はOSR (Out-of-Sync Replica)を形成し、 AR =ISR+OSR であることがわかります。通常の状況では、すべてのフォロワー コピーはリーダー コピーとのある程度の同期を維持する必要があります。つまり、AR=ISR であり、OSR セットは空です。
リーダー コピーはすべてのフォロワー コピーを監視します。データがリーダー コピーと一致する場合、ISR メンバーに追加されます。リーダー コピーとの差異が大きすぎる場合、またはダウンしている場合、ISR から追い出されます。リーダー コピーにも追いつきます。ISR に再参加します。
リーダー コピーがダウンしているか使用できない場合、ISR メンバーのみが新しいリーダー コピーとして選択される機会を得ることができます。これにより、新しいリーダーがダウンしたリーダーのデータと一貫性を持つことが保証されます。 OSR がリーダーとして選択されると、その結果、一部の非同期データが失われます。
上記の状況では、P1 レプリカが最初にリーダーに選出され、P2 レプリカのみが P1 のデータを同期しており、オフセットは 110 です。このときの ISR には P1 と P2 のみがあり、OSR には P3 と P4 があります。 。P3 がデータを 110 に同期すると、リーダーによって ISR にも追加されますが、この時点でリーダーがダウンすると、ISR から新しいリーダーが選択され、P0 は 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-
