kafka从入门到崩溃

乍一看似乎觉得作者小题大做了，心里一想，纵横java届数十载，什么大风大浪没见过，这噱头，赤裸裸的鄙视！废话不说，先从奔溃的边缘开始

Kafka是什么呢？先给大家秀一波英语（官网）：

Kafka is used for building  real-time data  pipelines and streaming apps. It is horizontally scalable,  fault-tolerant,  wicked fast, and runs in production in thousands of companies.

中文意思是：Kafka用于构建实时数据管道和流式应用程序。它具有水平可扩展性，容错性，速度极快，并在数千家公司投入生产。

其实简单点说，消息中间件，MQ（Message Queue，消息队列）大家应该有所了解，现在是比较主流的消息中间件，可以横向扩展、高可靠，而且还变态快

大致的意思就是，这是一个实时数据处理系统，可以横向扩展、高可靠，而且还变态快，已经被很多公司使用。

消息中间件应用场景

消息中间件的作用主要有两点：

• 解耦生产者和消费者。
• 缓冲。

四种应用场景：

• 异步处理
• 应用解耦
• 流量削锋
• 消息通讯

想象一个场景，你的一个创建订单的操作，在订单创建完成之后，需要触发一系列其他的操作，比如进行用户订单数据的统计、给用户发送短信、给用户发送邮件等等，就像这样：

createOrder(...){
 ...
 statOrderData(...);
 sendSMS();
 sendEmail();
}

代码这样写似乎没什么问题，可是过了一段时间，你给系统引进了一个用户行为分析服务，它也需要在订单创建完成之后，进行一个分析用户行为的操作，而且随着系统的逐渐壮大，创建订单之后要触发的操作也就越来越多，代码也渐渐膨胀成这样：

createOrder(...){
 ...
 statOrderData(...);
 sendSMS();
 sendEmail();
 // new operation
 statUserBehavior(...);
 doXXX(...);
 doYYY(...);
 // more and more operations
 ...
}

导致代码越来越膨胀的症结在于，消息的生产和消费耦合在一起了。createOrder方法不仅仅要负责生产“订单已创建”这条消息，还要负责处理这条消息。

这就好比BBC的记者，在知道皇马拿到欧冠冠军之后，拿起手机，翻开皇马球迷通讯录，给球迷一个一个打电话，告诉他们，皇马夺冠了。

事实上，BBC的记者只需要在他们官网发布这条消息，然后球迷自行访问BBC，去上面获取这条新闻；又或者球迷订阅了BBC，那么订阅系统会主动把发布在官网的消息推送给球迷。

同样，createOrder也需要一个像BBC官网那样的载体，也就是消息中间件，在订单创建完成之后，把一条主题为“orderCreated”的消息，放到消息中间件去就ok了，不必关心需要把这条消息发给谁。这就完成了消息的生产。

至于需要在订单创建完成之后触发操作的服务，则只需要订阅主题为“orderCreated”的消息，在消息中间件出现新的“orderCreated”消息时，就会收到这条消息，然后进行相应的处理。

因此，通过使用消息中间件，上面的代码也就简化成了：

createOrder(...){
 ...
 sendOrderCreatedMessage(...);
}

以后如果在订单创建之后有新的操作需要执行，这串代码也不需要修改，只需要给对消息进行订阅即可。

另外，通过这样的解耦，消费者在消费数据时更加的灵活，不必每次消息一产生就要马上去处理（虽然通常消费者侧也会有线程池等缓冲机制），可以等自己有空了的时候，再过来消息中间件这里取数据进行处理。这就是消息中间件带来的缓冲作用。

Kafka一代 - 消息队列

从上面的描述，我们可以看出，消息中间件之所以可以解耦消息的生产和消费，主要是它提供了一个存放消息的地方——生产者把消息放进来，消费者在从中取出消息进行处理。

那么这个存放消息的地方，应该采用什么数据结构呢？

在绝大多数情况下，我们都希望先发送进来的消息，可以先被处理（FIFO），这符合大多数的业务逻辑，少数情况下我们会给消息设置优先级。不管怎样，对于消息中间件来说，一个先进先出的队列，是非常合适的数据结构：

 

那么要怎样保证消息可以被顺序消费呢？

消费者过来获取消息时，每次都把index=0的数据返回过去，然后再删除index=0的那条数据？

很明显不行，因为订阅了这条消息的消费者数量，可能是0，也可能是1，还可能大于1。如果每次消费完就删除了，那么其他订阅了这条消息的消费者就获取不到这条消息了。

事实上，Kafka会对数据进行持久化存储（至于存放多长时间，这是可以配置的），消费者端会记录一个offset，表明该消费者当前消费到哪条数据，所以下次消费者想继续消费，只需从offset+1的位置继续消费就好了。

消费者甚至可以通过调整offset的值，重新消费以前的数据。

那么这就是Kafka了吗？不，这只是一条非常普通的消息队列，我们姑且叫它为Kafka一代吧。

这个Kafka一代用一条消息队列实现了消息中间件，这样的简单实现存在不少问题：

• Topic鱼龙混杂。想象一下，一个只订阅了topic为“A”的消费者，却要在一条有ABCDEFG…等各种各样topic的队列里头去寻找topic为A的消息，这样性能岂不是很慢？
• 吞吐量低。我们把全部消息都放在一条队列了，请求一多，它肯定应付不过来。

由此就引申出了Kafka二代。

Kafka二代 - Partition

要解决Kafka一代的那两个问题，很简单——分布存储。

二代Kafka引入了Partition的概念，也就是采用多条队列， 每条队列里面的消息都是相同的topic：

 

Partition的设计解决了上面提到的两个问题：

• 纯Topic队列。一个队列只有一种topic，消费者再也不用担心会碰到不是自己想要的topic的消息了。
• 提高吞吐量。不同topic的消息交给不同队列去存储，再也不用以一敌十了。

一个队列只有一种topic，但是一种topic的消息却可以根据自定义的key值，分散到多条队列中。也就是说，上图的p1和p2，可以都是同一种topic的队列。不过这是属于比较高级的应用了，以后有机会再和大家讨论。

Kafka二代足够完美了吗？当然不是，我们虽然通过Partition提升了性能，但是我们忽略了一个很重要的问题——高可用。

万一机器挂掉了怎么办？单点系统总是不可靠的。我们必须考虑备用节点和数据备份的问题。

Kafka三代 - Broker集群

很明显，为了解决高可用问题，我们需要集群。

Kafka对集群的支持也是非常友好的。在Kafka中，集群里的每个实例叫做Broker，就像这样：

 

每个partition不再只有一个，而是有一个leader(红色)和多个replica(蓝色)，生产者根据消息的topic和key值，确定了消息要发往哪个partition之后（假设是p1），会找到partition对应的leader(也就是broker2里的p1)，然后将消息发给leader，leader负责消息的写入，并与其余的replica进行同步。

一旦某一个partition的leader挂掉了，那么只需提拔一个replica出来，让它成为leader就ok了，系统依旧可以正常运行。

通过Broker集群的设计，我们不仅解决了系统高可用的问题，还进一步提升了系统的吞吐量，因为replica同样可以为消费者提供数据查找的功能。

以上内容转自掘金--Java3y的文章 非常适合了解和入门kafka

原文链接：https://juejin.im/post/5cb025fb5188251b0351ef48

 

这是kafka一个大致的架构图，非常的简明，接下来为大家介绍一下

kafka核心组成：producer、consumer、Kafka Cluster、zookeeper

1、Producer：消息生产者， Producer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition;比如基于"round-robin"方式或者通过其他的一些算法等.

2、consumer Group：消费者组，一个partition中的消息只会被group中的一个consumer消费;每个group中consumer消息消费互相独立;我们可以认为一个group是一个"订阅"者,一个Topic中的每个partions,只会被一个"订阅者"中的一个consumer消费,不过一个consumer可以消费多个partitions中的消息.kafka只能保证一个partition中的消息被某个consumer消费时,消息是顺序的.事实上,从Topic角度来说,消息仍不是有序的.

3、Kafka Cluster:kafka集群,含有多个Broker,每个Broker由多个Partition组成，Partition中的Topic是相同的，内容保持相同，Partition中分为一个Leader(boss，可以理解为领导)，和多个follower，leader的选举算法的实现类似于微软的PacificA

4、Zookeeper:kafka使用ZooKeeper用于管理、协调代理。每个Kafka代理通过Zookeeper协调其他Kafka代理。