介绍
我们都知道kafka是一个分布式流处理平台. 在大数据领域有着很广泛的应用。而它究竟有哪些特性能够支撑起海量的数据呢,带着这个疑问我将在后续的文章中来和大家一起探讨
消息类型
点对点(p2p)
就拿微信聊天来讲,
点对点类型类似于小明和老王之间私聊一样,「小明」说话的内容是只有「老王」才能收到的,其他人是接受不到该消息的
发布/订阅(pup/sub)
同样我们还是拿微信聊天举例,假设此时小明在群里发布了一条消息。
发布/订阅类型中的「订阅者」就好比群中的张三,李四,老王。
「发布者」就好比群中的小明,这时「发布者」小明在群聊中发布的消息自然也就会被所有「订阅者」所接受到
术语介绍
topic
kafka中pub/sub消息类型能够得以实现的主要原因是依赖了topic机制,在日常应用中,我们会把不同的业务消息命名成不同的topic。比如用户信息变更:user_update,订单消息:order 等,然后我们就可以让下游的相关业务服务来消费不同的topic(Consumer Group)
Producer/Consumer
-
Producer
消息的生产方。一个服务既可以是生产方也可以是消费方,不过最好不要这么干,建议微服务的职责尽量单一和明确,生产方将消息方式至Kafka。
所以对于Kafka来说,Producer是Client -
Consumer
消息的消费方。从Kafka中消费消息,所以对于Kafka来说,Consumer也是Client
Broker
一个完整的Kafka集群通常由多个Broker实例组成,这些Broker实例来接收客户端请求(Producer生产消息,Consumer消费消息)。这些Broker实例可以同时部署在同一个节点中,但上图我放在了不同了节点当中。这么做的原因其实也很好理解(鸡蛋不能放在一个篮子里),想必Kafka设计Broker的初衷也在于此吧,所以在生产环境中强烈建议Broker要多节点部署
Replication
Replication是Kafka高可用的一种实现手段(好像现在很多分布式应用都这么叫),Replication将数据分成多个副本从而分布在不同的节点中。这些副本有两个角色:Leader和Follower。正如上图所述,Leader直接对接客户端(Producer 和 Consumer),而Follower则会不断的从Leader中获取最新消息并存储
Partition
分区机制也是Kafka实现高可用的一种手段。上述的副本机制只是解决了数据冗余备份问题,它能够保证数据不丢失,但是做不到水平伸缩。Kafka为了解决这个问题从而在Kafka中引入了分区机制,一个Topic可以有多个分区,Producer只能向其中的一个分区写入消息。每个分区中有且仅有一个Leader以及多个Follower,分区中的消息用Offset来标记消息的位移。
以上描述可以有点抽象,下面去来给你举一个实际的业务场景吧:
假设现在有一个用户更新的场景,需要将更新消息传递至各下游的服务。这个时候你创建了user_update的topic,并给这个Topic设置了3个分区,那么这个topic的分区编号为0,1,2。你的业务作为Producer的话,你的消息每一次只会被发送至其中一个分区中。假设我们现在往全新的分区1中写入了5条消息,那么这5条消息的offset是:0,1,2,3,4
总结
上述文章中我们把Kafka中比较重要的几个概念全部做了说明,希望能够帮助你梳理下Kafka整体结构。
- 我们讲到了Topic,一个Topic可以有多个分区,每个分区中有用多个副本
- 我们有讲到了分区,每个分区中有且仅有一个Leader以及多个Follower,Producer只会将消息写入Topic的一个分区
- 最后我们又稍微提了下Offset,它是用来标记消息的位移的
写作不易,如果有帮到你,随手点个赞喽