标签：level 分区 broker kafka high api 使用 原理
分布式消息队列 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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。