使用场景

离线的消息处理
一个日志信息处理，在kafka的下游，再对日志信息进行处理
metrics数据，程序状态的采集
用户行为，搜索点赞评论

如何使用Kafka

创建集群 - 新增Topic - 编写生存者逻辑 - 编写消费者逻辑

基本概念

Topic: 逻辑队列，不同 Topic 可以建立不同的 Topic

Cluster: 物理集群，每个集群中可以建立多个不同的 Topic

Producer: 生产者，负责将业务消息发送到 Topic 中

Consumer: 消费者，负责消费 Topic 中的消息

ConsumerGroup: 消费者组，不同组 Consumer 消费进度互不干涉

Topic内部，一个Topic内部有多个partition

Offset：消息在partition内的相对位置信息，可以理解为唯一ID，在partition内部严格递增

Replica：每个分片有多个Replica， Leader Replica将会从ISR（In-Sync Replicas）中选出

Replica-Leader负责写数据，Follower会负责读取Leader写的数据，当Follower与Leader差距过大会被踢出ISR

ISR能保证一个高可用

我们参考一下借用一下ppt里面的这张图

可以看到Topic1有两个Partition，分别为Partition1与Partition2 而每个Partition又有各自的Leader与Follower，分别存储在不同的Broker之中，这其中的一个数据复制就是Kafka高可用的关键下面又分为两个Consumer Group1 与2，他们可以分别去消费Partition，互相不会造成影响

Consumer去消费哪个Partition

low level

在Kafka中有两种方式，一种是根据业务需求，通过手动进行分配，哪一个Consumer消费Partition由业务进行选择这种方式被称之为low level

high level

自动分配Partition，由Coordinator来感知，当新加进来一个Consumer4的时候，会自动分配Partition给它

缺点

数据复制问题当程序重启时，要经过Leader切换，此时新的Leader一直在接受数据，而当重启的Broker要进行数据追赶，追赶完成后又要进行Leader的回切，这个过程在数据量大的时候将会是一个分钟级别的操作
负载不均衡 1.运维成本高 2.对于负载不均衡的场景，解决方案复杂 3.没有自己的缓存，完全依赖Page Cache

消息队列课程笔记 ｜ 青训营笔记