其他分享
首页 > 其他分享> > kafka原理与使用

kafka原理与使用

作者:互联网

分布式消息队列 kafka

1.典型应用:异步处理、系统耦合、流量削峰、日志处理

2.核心原理:kafka体系结构以及读写流程

3.具体操作:high level api 以及 low level api

 

分布式消息队列:

1.高可用性 

2.可靠性  持久化

3.可扩展性 高吞吐量

 

nginx

 

 

 

 

A服务和B服务进行交互的方式

1.socket        缺点:麻烦,制定协议

2.restful API  缺点:公开

3. rpc           缺点: 耦合性增加了

 

总结:

1.梳理流程

2.分析是否必要、是否紧急

3.非必要不紧急的任务用消息队列处理

 

 

核心原理:

1.抓住几个重点,实现类似系统的时候,知识迁移

 

 

存储:

broker kafka进程  也可以是节点  都有一个主broker controller

broker中有分区,叫做partition 分区  leader partition   (用来读写)

                                                    和 replica partition(备份,选举) 主从复制原则  也可以是不同的进程

 

选择主broker的原则:

zk 1.用来选举从broker当中选举出controller   2.存储集群信息

 

选举 分布式系统有哪几种方式 ?

1. zk etcd来进行选举

2.redis 哨兵模式

3.去中心化的选举

4.raft 选举 自己实现 

 

kafka有哪几种生产消费模式:

1.点对点模式

2.订阅发布模式

 

读写流程:

写:1.生产到哪一个分区?

2.怎么确保消息一定能够到达? (采用请求回应的模式  ack)

 

1.分区信息存储再哪里? zk

2. 提供策略: 自定义 kafka定义行为来写 ( low level api)    使用kafka的api  (high level api)

high level写方式:

 

 

1.随机写

2,hash的方式

3. 轮询的方式

 

high level定义ack的方式

1.ack = 0 不需要返回

2.ack = 1 需要返回,直接返回

3.ack = -1 各broker的分区同步完成后,返回

 

 

读流程;

1. 从哪里开始消费?(a. 从哪个分区消费    需要知道具体分区在哪个消费者消费?额外主题(0.9版本之后,存在kafka内部)

                                     b.消费者组如何消费  消费者组与partition对应的问题? 尽量保持消息有序执行 (一个分区只能对应一个消费者  一个消费者可以对应多个分区)整体时无序,单个有序)

2. 怎么确保消息一定被消费?

丢失:1.根本没存储在kafka  2.没执行消息 

 

对应关系是脆弱的 

high level api

1.订阅发布:

rebalance:修正对应关系,有以下几种方式

a. range 平均

b. 轮询

以上是有缺点的,一个节点挂掉之后,先暂停服务、然后rebalance,rebalance有代价

c.粘性的方式   没有发生rebalance的时候采用轮询的方式,发生rebalance的时候,尽量保证原来的对应关系,后面采用轮询的方式。

 

 

怎么保证消息一定消费?

1.提交策略 自动提交、手动提交 (high level采用自动提交,容易丢失)

2.事务  (重复消费、消息丢失,可能db修改成功,consumer宕机了,造成offset没有变化,会产生重复消费)将offet保存在数据库中

 

 

分布式延时队列 1. kafka 创建额外的主题  额外的定时进程, 过期后再放入另一个队列中,由消费者消费

 

标签:level,分区,broker,kafka,high,api,使用,原理
来源: https://www.cnblogs.com/cuijy1/p/16558243.html