2019-07-30 kafka入门

Producer 生产者

Consumer 消费者

Server (broker) 实例 多个 实例构成了kafka集群

zookeeper 配置信息的保存的地方

Topic 主题 承载消息的 一种集合

partition 一个或者多个p组成一个Topic 里面存放的都是一种信息

replicas 备份 partition的备份数量;

offset 偏移量 简单的理解为消息在partition中存放的地址 是一个Long类型的

kafka对消息能不能进行随机读取?

因为offset是唯一的标识消息地址的 索引,所以kafka中不存在随机的读取;

kafka对消息日志的管理

kafka的broker 会按配置 比如两天保存 这条消息的的日志,无论这条消息是否被消费;对于consumer来说,它需要保存的是消息的offset,对于offset的控制和使用,由consumer来控制,每当消费者消费一条信息后,offset会向前推进一个,消息是依次被消费的;

生产者和消费者的信息是由zookeeper来维护不需要由broker来操心;

一个Topic 可以分成若干个partition,保证了多个consumer可以对其进行消费,北欧整了并发性能;

kafka的对于partition的备份

p1        p2        p3        p4    

s1        s2        s3        s4    (都是leader)

f11       f21      f31       f41        (剩下的都是follow 也是server 帮助备份的)

f21       f22     f32        f42

f31                             f43

一个leader下面有几个follow 有多有少吧,follow不进行消息的传递,知识起一个备份作用,并且以s4举例,如果s4挂掉了,那么就会从f41 f42 f43中 选一个当成leader;由此可见,leader承载了server的所有负载,有多少个partition就会有多少个leader,kafka会将partition均衡地分发到server 上去;

每个consumer都有唯一的一个分组group,每个group可以由一个或者多个consumer组成;

发送到Topic的消息 一种Topic消息只会被 一个group 中的一个consumer消费,也就是说每个group只能有一个consumer指向partition

每个group之间又是相互独立的 g1中c3消费了p2 ,g3中的c3同样也可以消费p2,但是g2中的c2消费了p1,那么g2中其他的c就不能再消费p1了;

随便找了三张图解释上面的


2019-07-30 kafka入门_第1张图片
每个g中只能有一个c去消费一种p

2019-07-30 kafka入门_第2张图片
一个c可以消费多个p

2019-07-30 kafka入门_第3张图片
p1可以被不同的g中的c消费

如上图,向test2发送消息1,2,3,4,5,6,7,8,9

消息被g3组的消费者均分,g4组的消费者在接收到了所有的消息

g3组:

C1接收到了:2,5,8

C2接收到了:3,6,9

C3接收到了:1,4,7

g4组:

C1接收到了:1,2,3,4,5,6,7,8,9

启动多个组,则会使同一个消息被消费多次

——————————————————————————————————————

kafka 能够保证p中消息的消费是顺序的,但是从Topic 的角度来看 消息的消费是无序的;

此外每个group中的c不能多于p,因为这样就会存在不工作的c,图一只是举例;

kafka的应用场景

普通的消息传递,不能保证事务,没有消息的反馈机制,也就是说c端消费不消费,s端都不知道;

 kafka可以作为"网站活性跟踪"的最佳工具;可以将网页/用户操作等信息发送到kafka中.并实时监控,或者离线统计分析等;

 kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统;

消息传输机制

 1) at most once: 最多一次,这个和JMS中"非持久化"消息类似.发送一次,无论成败,将不会重发;

 2) at least once: 消息至少发送一次,如果消息未能接受成功,可能会重发,直到接收成功;

follow和leader的关系

一个leader可以有或者没有follow 一个或者多个follow,消息被消费的日志也会被follow保存,每一次消息来和消费都会被leader和follow记录保存,只有负责p的leader和follow都commited好了,consumer才能开始消费这个p中的消息;follow要实时跟踪leader信息的变化,如果f落后太多,那么就会被删除;

日志的一点处理方式

p的信息会保存到zookeeper中,有一个默认值,就是1g超过了就会flush

你可能感兴趣的:(2019-07-30 kafka入门)