本文已参与「新人创作礼」活动，一起开启掘金创作之路。
介绍
我们都知道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，它是用来标记消息的位移的
写作不易，如果有帮到你，随手点个赞喽