初探Kafka底层数据模型
2021-11-12 18:44:31 1 举报深入理解Kafka底层数据模型
作者其他创作
大纲/内容
Consumer
用户只要访问商品都会经过Nginx日志留痕
7
P3
9
0
10
Kafka中的持久化，就是由commit log文件完成的
11
8
举例说明Kafka强大的应用场景(淘宝的商品推荐)
P2
Kafka使用了round-robin 做了负载均衡策略
6
partition3
2
深入理解Kafka底层数据模型
对于保存大数据的Kafka来说，对每个Topic下面的消息进行分区存储，是极佳的选择
Nginx
flume
日志缓存层
消息生产者，用于向Kafka发送消息
3
C1
ES
业务逻辑层
需要有一个组件，将我们Nginx日志，定时或者实时记录下来(比如说定时任务)，用于发送给kafka
5
日志生产者
Topic
commit log文件(c3.log)
spark
Kafka分布式集群
2.一个partition在同一时刻只能有一个consumer在消费
1
Consumer Group
消息中间件处理节点，一个Kafka节点就是一个broker一个或者多个Broker可以组成一个Kafka集群
淘宝的高并发，一秒可能产能几百G或者上T的数据量，Kafka可以做到正常接收且不丢失
1.Kafka在集群模式下有更强的顺序保证
4
日志存储层
P0
领导者负责处理所有消息的读写，追随者负责复制领导者处理消息的结果
commit log文件(c1.log)
算法分析层
业务逻辑层拿到被算法解析过关键词的日志，根据关键词去数据层中查找商品，随后推送展示给用户
Kafka
......
Kafka Cluster
Broker2
Kafka的重要内存角色
partition2
C4
日志接入层
Producer
Old
3.consumer的数量不能比partition多，否则多出的consumer会进入空闲状态
commit log文件(c2.log)
Kafka根据topic对消息进行归类，发布到Kafka集群的每条消息都需要指定一个topic
Partition
New
partition1
C2
Broker
P1
publish-subscribe(发布订阅)
Broker1
commit log文件存储了每个消息的offset(局部唯一id)
Consumer Group A
算法分析完，将关键字再次封装进日志存储层，稍后发送给业务逻辑层
Consumer Group B
消息消费者，用于消费Kafka Topic中的消息
logstash
在集群模式下，针对每个partition，会有一个Broker是领导者，其余的Broker是追随者，如果领导者宕机，将由一个追随者顶替
每个Consumer属于一个特定的Consumer Group，一条消息可以被多个不同的 Consumer Group消费，但是一个Consumer Group中只能有一个Consumer能够消费该消息
storm
消费者消费到Kafka的消息，传给算法分析层，这里用于分析日志中的关键字
主题Topic和消息日志Log(分区概念图)
C3
物理上的概念(隔断/分区)，一个topic可以分为多个partition每个partition内部消息是有序的
Kafka收到消息，并且将庞大的数据量保存到topic中，随后让消费者消费
应用客户端展示层
Kafka对于传统消息模式提出的统一处理模式
Queue(队列)
.log
传统的消息传递模式
职业：暂无
0 条评论
下一页
