kafka是做什么的（kafka是干嘛的）

本篇文章给大家谈谈kafka是做什么的，以及kafka是干嘛的对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Kafka还是RabbitMQ？
• 2、kafka和mqtt的区别是什么
• 3、Kafka用Zookeeper所做的那些事
• 4、卡夫卡什么意思

Kafka还是RabbitMQ？

现在的系统已经离不开消息队列，我们可以用他做异步，做解耦，做流处理，做可靠传输。市面上的消息队列也有很多，比如阿里云的oss，RocketMQ，ZeroMQ，RabbitMQ，Kafka等，甚至Java中的List也可以称为一个简单的消息队列，种类如此繁多，我们该如何选择呢？现在主流的消息队列可以分为两类，一类以kafka为代表，一类以RabbitMQ为代表，二者有很多相似的地方，也都有各自的优势。

那我们平时构建系统的时候，该选择哪种消息队列呢？这里我们将RbbitMQ与kafka做一下对比（因为他们都是spring默认集成的消息队列），以便于我们做出最优的选择。

RabbitMQ：关于rabbit的详细介绍这里不说，感兴趣的可以看我之前的文章，一句话rabbit作为传统意义上的消息队列，基于AMQP协议开发，倾向于做按各种规则的消息转发。

Kafka：关于kafka的详细介绍会在以后的文章里写，因为刚开始用，想深入了解后再写出来。kafka更倾向于一个流式管道的概念，消息从一处流向另一处，吞吐量比rabbit更高。

接下来通过俩张图来理解他俩的设计与区别。

首先来看rabbit，他通过broker来进行统一调配消息去向，生产者通过指定的规则将消息发送到broker，broker再按照规则发送给消费者进行消费，消费者方可以选择消费方式为pull或者是broker主动push，支持的消费模式也有多种，点对点，广播，正则匹配等。

Kafka主要为高吞吐量的订阅腊绝发布系统而设计，主要追求速度与持久化。kafka中的消息由键、值、时间戳组成，kafka不记录每个消息被谁使用，只通过偏移量记录哪些消息是未读的，kafka中可以指定消费组来实现订阅发布的功能。

了解了二者大体的区别以后，我们再来看具体的适用场景。

Kafka：

1.从A系统到B系统的消息没有复杂的传递规则，并且具有较高的吞吐量要求。

2.需要访问消息的历史记录的场景，因为kafak是持久化消息的，所以可以通过偏移量访问到那些已经被消费的消息（前提是磁盘空间足够，kafka没有将日志文件删除）

3.流处理的场景。处理源源不断的流式消息，比较典型的是日志的例子，将系统中源源不断生成的日志发送到kafka中。

rabbit：

1.需要对消息进册衫行更加细粒度的控制，包括一些可靠性方面的特性，比如死信队列。

2.需要多种消费模式（点对点，广播州局腔，订阅发布等）

3.消息需要通过复杂的路由到消费者。

最后是关于性能方面，众所周知，kafka的吞吐量优于rabbit，大约是100k/sec，而rabbit大约是20k/sec，但是这个不应该成为我们选择的主要原因，因为性能方面的瓶颈都是可以通过集群方案来解决的。

最后要说的是，没有最好的队列，只有最合适的队列。

参考：Understanding When to use RabbitMQ or Apache Kafka

[img]

kafka和mqtt的区别是什么

kafka是分布式消息队列或者叫分布式消息中间件，有时候会叫做一种MQ产品（Message Queue),同类型的有RabbitMQ，ActiveMQ等等。

MQTT是一种即时消息传输协议，Message Queuing Telemetry Transport，也就是一种即时信息传输的一种格式约定，与其类似的有XMPP等，是用来做IM的。

kafka是不支持MQTT协议的，如果非要把它们集成在一起，你要不自己分析，要不去Github上找找，说不定有人做过这样的项目。

两个M的意败谈思，是完全裤枯余不一样的，kafka的M是指各个服务器或各个进程间传输的消息，而MQTT的M，是指类似MSN，QQ那种IM中那种大家交流的那胡滚种消息。

Kafka用Zookeeper所做的那些事

Kafka是高可用的分布式消息系统，首先要解决的就是资源协调分配和多副本状态维护的问题。解决这些问题通常就是两种思路，一是依靠Zookeeper来协调，二是设定一个中心节点，让这个中心节点来协调。如果依靠Zookeeper来协调，会存在大量的竞争条件，对Zookeeper的访问压力增大，而且如果Zookeeper出现了问题（比如网络抖动），系统很容易出现紊乱。Kafka采用的是第二种思路，即选举一个中心节点来进行资源协调与多副本状态维护，这个中心节点被称作Controller（一个特殊的Broker），这个选举过程依靠Zookeeper来完成。

Broker启动时，会竞争创建临时"/controller"。如果创建成功，则成为Controller，并把Broker的id等信息写入这个节点。同时会全程监控"/controller"的数据变化，如果旧的Controller挂掉，则开启新一轮的竞争过程。

Kafka要进行资源协调，第一件需要知道的事情就是各个Broker的存活状态，这个问题利用Zookeeper可以很容易做到。

假设某个Broker，id为0，它启动时，会创建"/brokers/ids/0"临时节点，并把端口等信息写进去。Controller会监控汪睁"/brokers/ids"的节点变化，以实时感知各broker的状态，进行资源协调。

在Kafka这个多副本分区的消息系统里，创建一个topic，至少需要以下3个步骤：

Controller的存在，可以很容易完成上面的b和c步骤，但a步骤不行，如果Controller挂掉，则这些信息会不可用。Kafka把这些信息保存在Zookeeper中，依靠其高可用特性来保证这些信息的高可用。假设某个topic名字为mytopic，创建时，其分区信息保存在"/brokers/topics/mytopic"中。Controller全程监控"/brokers/topics"的孩子节点变动，实时感知这些信息，以完成后续步哗哪骤。

创建完成之后，后续往往会有分区调整和topic删除等需求。普通青年可能会觉得这两个问题很简单，给Controller发个相关请求就可以了。事实远非如此！

拿分区调整来说，假设某分区有三个副本，分别位于Broker-1、Broker-2和Broker-3，leader为1，现在扩容增加了Broker-4、Broker-5、Broker-6，为了平衡机器间压力，需要将副本1 2 3移到4 5 6，至少经历以下步骤：

以上每个步骤都有可能失败，如何才能保证这次调整顺利进行呢？

首先，我们不能直接修改该分区的副本信息为 4 5 6，原因很简单，需要等待4 5 6的追赶过程以便产生新leader。其次，操作未完全成功的命令需要保存下来，如果操作过程中，Controller挂掉，则新的Controller可以从头开始直至成功。

Kafka怎么做的呢？

当然，这里一次只能有一个调整命令，但一个调整命令可以同时调整多个topic的多个分区。

在这个过程中，Zookeeper的作用是： 持久化操作命令并实时通知操作者 ，是不是只有Zookeeper可以做这个事情呢，不是，但Zookeeper可以做得很好，保证命令高可用。

类似的操作还有topic删除，副本的leader变更等，都是沿用上面的套路。

Broker的集群中有全局配置信息，但如果想针对某个topic或者某个client进行配置呢，Kafka把这些信息保存在Zookeeper中，各个Broker实时监控以更新。

脑裂问题是指，在一个设有中心节点的系统中，出现了两个中心节点。两个中心同时传达命令，自然会造成系统的紊乱。

Kafka利用Zookeeper所做的第一件也是至关重要的一件事情是选举Controller，那么自然就有疑问，有没有可能产生两个Controller呢？

首先，Zookeeper也是有leader的，它有没有可能产生两乱陵码个leader呢？答案是不会。

quorum机制可以保证，不可能同时存在两个leader获得大多数支持。假设某个leader假死，其余的followers选举出了一个新的leader。这时，旧的leader复活并且仍然认为自己是leader，这个时候它向其他followers发出写请求也是会被拒绝的。因为每当新leader产生时，会生成一个epoch，这个epoch是递增的，followers如果确认了新的leader存在，知道其epoch，就会拒绝epoch小于现任leader epoch的所有请求。那有没有follower不知道新的leader存在呢，有可能，但肯定不是大多数，否则新leader无法产生。Zookeeper的写也遵循quorum机制，因此，得不到大多数支持的写是无效的，旧leader即使各种认为自己是leader，依然没有什么作用。

Kafka的Controller也采用了epoch，具体机制如下:

理论上来说，如果Controller的SessionExpired处理成功，则可以避免双leader，但假设SessionExpire处理意外失效的情况：旧Controller假死，新的Controller创建。旧Controller复活，SessionExpired处理 意外失效 ，仍然认为自己是leader。

这时虽然有两个leader，但没有关系，leader只会发信息给存活的broker（仍然与Zookeeper在Session内的），而这些存活的broker则肯定能感知到新leader的存在，旧leader的请求会被拒绝。

每个Broker有一个metaDataCache，缓存有topic和partition的基本信息，可以正常的生产和消费信息，但不能进行topic的创建、调整和删除等操作。

此外，Broker会不断重试连接。

待续

假设Broker数目为B，topic数目为T，所有topic总partition数目为P，Client数目为C，以下数值均为峰值：

卡夫卡什么意思

乌鸦在中国被认为是神竖并一种不吉祥之物,特别是纤游听到乌鸦的叫声,总会让人有不详之感,好像马上就要大难临头一样,而在日本乌鸦却被视为灵鸟,受人保护无人捕杀。阿拉伯人视乌鸦为占卜吉凶之鸟,而在捷克游迹语中的乌鸦便是卡夫卡。

——见村上春树《海边的卡夫卡》

另，卡夫卡，全名弗兰茨·卡夫卡，捷克著名作家。下面是对他的介绍

关于kafka是做什么的和kafka是干嘛的的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。