前言：
新公司消息队列用选用卡夫卡，刚好之前没有用这个消息队列过借此机会学习一波。发现大公司都喜欢用这款消息队列。
消息队列中间件的使用并不复杂，但消息队列的选型一直是个难点。比如：
不同业务场景下该如何选型消息队列？
流消息系统和队列消息系统的 producer 有何区别？
Kafka、RocketMQ、RabbitMQ 各自的优劣在哪？
在实际场景中，性能强大的 Kafka 支持排序保证，非常适合提取消息；而RocketMQ、RabbitMQ 拥有完善的队列特性，可以弥补 Kafka 的不足。
很多公司经常会在 Kafka 和 RabbitMQ 或 RocketMQ 之间做选择，这是因为在实时流式架构中，消息用例可被分为两类：队列和流。两者都不能舍弃，系统复杂度自然大大提高。
除了老牌消息系统，新一代云原生消息系统 Apache Pulsar 支持流处理，同时它的共享订阅模式能将 topic 用作队列，向同一 topic 内的 consumer 提供多个虚拟队列并支持延迟发送消息。
冉冉升起的新星 Pulsar 支持三种订阅类型，很大程度上解决了现有开源消息系统的核心痛点：
排他性。只能有一个 Consumer，接收一个 Topic 所有的消息
共享性。可以同时存在多个 Consumer，每个 Consumer 处理 topic 中一部消息
Failover 特性。同一时刻只有一个有效的Consumer，其余的 Consumer 作为备用节点，在 Master Consumer 不可用后进行替代。
扯远了。。。。。。圆规正转
Kafk
在具体了解Kafka的细节前，我们先来看一下它的一些基本概念：
Kafka是运行在一个集群上，所以它可以拥有一个或多个服务节点；
Kafka集群将消息存储在特定的文件中，对外表现为Topics；
每条消息记录都包含一个key,消息内容以及时间戳；
从上面几点我们大致可以推测Kafka是一个分布式的消息存储系统，那么它就仅仅这么点功能吗，我们继续看下面。
Kafka为了拥有更强大的功能，提供了四大核心接口：
Producer API允许了应用可以向Kafka中的topics发布消息；
Consumer API允许了应用可以订阅Kafka中的topics,并消费消息；
Streams API允许应用可以作为消息流的处理者，比如可以从topicA中消费消息，处理的结果发布到topicB中；
Connector API提供Kafka与现有的应用或系统适配功能，比如与数据库连接器可以捕获表结构的变化；
它们与Kafka集群的关系可以用下图表示：
在了解了Kafka的一些基本概念后，我们具体来看看它的一些组成部分。
Topics
顾名思义Topics是一些主题的集合，更通俗的说Topic就像一个消息队列，生产者可以向其写入消息，消费者可以从中读取消息，一个Topic支持多个生产者或消费者同时订阅它，所以其扩展性很好。Topic又可以由一个或多个partition（分区）组成，比如下图：
其中每个partition中的消息是有序的，但相互之间的顺序就不能保证了，若Topic有多个partition，生产者的消息可以指定或者由系统根据算法分配到指定分区，若你需要所有消息都是有序的，那么你最好只用一个分区。另外partition支持消息位移读取，消息位移有消费者自身管理，比如下图：
由上图可以看出，不同消费者对同一分区的消息读取互不干扰，消费者可以通过设置消息位移（offset）来控制自己想要获取的数据，比如可以从头读取，最新数据读取，重读读取等功能。
offset
消息在日志中的位置，可以理解是消息在 partition 上的偏移量，也是代表该消息的唯一序号。
同时也是主从之间的需要同步的信息。
Distribution
上文说到过，Kafka是一个分布式的消息系统，所以当我们配置了多个Kafka Server节点后，它就拥有分布式的能力，比如容错等，partition会被分布在各个Server节点上，同时它们中间又有一个leader，它会处理所有的读写请求，其他followers会复制leader上的数据信息，一旦当leader因为某些故障而无法提供服务后，就会有一个follower被推举出来成为新的leader来处理这些请求。
Geo-Replication
异地备份是作为主流分布式系统的基础功能，用于集群中数据的备份和恢复，Kafka利用MirrorMaker来实现这个功能，用户只需简单的进行相应配置即可。
Producers
Producers作为消息的生产者，可以自己指定将消息发布到订阅Topic中的指定分区，策略可以自己指定，比如语义或者结构类似的消息发布在同一分区，当然也可以由系统循环发布在每一个分区上。
Consumers
Consumers是一群消费者的集合，可以称之为消费者组，是一种更高层次的的抽象，向Topic订阅消费消息的单位是Consumers，当然它其中也可以只有一个消费者（consumer）。下面是关于consumer的两条原则：
假如所有消费者都在同一个消费者组中，那么它们将协同消费订阅Topic的部分消息（根据分区与消费者的数量分配），保存负载平衡；
假如所有消费者都在不同的消费者组中，并且订阅了同个Topic，那么它们将可以消费Topic的所有消息；
下面是一个简单的例子，帮助大家理解：
consumer-groups
上图中有两个Server节点，有一个Topic被分为四个分区（P0-P4)分别被分配在两个节点上，另外还有两个消费者组（GA，GB），其中GA有两个消费者实例，GB有四个消费者实例。
从图中我们可以看出，首先订阅Topic的单位是消费者组，另外我们发现Topic中的消息根据一定规则将消息推送给具体消费者，主要原则如下：
若消费者数小于partition数，且消费者数为一个，那么它就消费所有消息；
若消费者数小于partition数，假设消费者数为N，partition数为M，那么每个消费者能消费的分区数为M/N或M/N+1；
若消费者数等于partition数，那么每个消费者都会均等分配到一个分区的消息；
若消费者数大于partition数，则将会出现部分消费者得不到消息分区，出现空闲的情况；
总的来说，Kafka会根据消费者组的情况均衡分配消息，比如有消息着实例宕机，亦或者有新的消费者加入等情况。
Guarantees
kafka作为一个高水准的系统，提供了以下的保证：
消息的添加是有序的，生产者越早向订阅的Topic发送的消息，会更早的被添加到Topic中，当然它们可能被分配到不同的分区；
消费者在消费Topic分区中的消息时是有序的；
对于有N个复制节点的Topic，系统可以最多容忍N-1个节点发生故障，而不丢失任何提交给该Topic的消息丢失；
Zookeeper
管理 kafka 集群，负责存储了集群 broker、topic、partition 等 meta 数据存储，同时也负责 broker 故障发现，partition leader 选举，负载均衡等功能。
服务治理
既然 Kafka 是分布式的发布/订阅系统，这样如果做的集群之间数据同步和一致性，kafka 是不是肯定不会丢消息呢？以及宕机的时候如果进行 Leader 选举呢？
数据同步
在 Kafka 中的 Partition 有一个 leader 与多个 follower，producer 往某个 Partition 中写入数据是，只会往 leader 中写入数据，然后数据才会被复制进其他的 Replica 中。而每一个 follower 可以理解成一个消费者，定期去 leader 去拉去消息。而只有数据同步了后，kafka 才会给生产者返回一个 ACK 告知消息已经存储落地了。
ISR
在 Kafka 中，为了保证性能，Kafka 不会采用强一致性的方式来同步主从的数据。而是维护了一个：in-sync Replica 的列表，Leader 不需要等待所有 Follower 都完成同步，只要在 ISR 中的 Follower 完成数据同步就可以发送 ack 给生产者即可认为消息同步完成。同时如果发现 ISR 里面某一个 follower 落后太多的话，就会把它剔除。
具体流程如下：
上述的做法并无法保证 kafka 一定不丢消息。 虽然 Kafka 通过多副本机制中最大限度保证消息不会丢失，但是如果数据已经写入系统 page cache 中但是还没来得及刷入磁盘，此时突然机器宕机或者掉电，那消息自然而然的就会丢失。
Kafka 故障恢复
实现一个小demo
参考文献：
https://scala.cool/2018/03/learning-kafka-1/
https://scala.cool/2018/03/learning-kafka-2/