kobexzf的博客

整体在循环中：循环的跳出条件-拉取到消息了或时间(pollTimeout)到了返回的数量有限制-maxPollRecords，若当前客户端内存有数据但数量不足maxPollRecords，有多少返回多少，若超过maxPollRecords，返回maxPollRecords若当前无数据，或返回用户之前(为了流水线操作，提前发请求，下次用户poll就可以读到数据了)，构建fetch request并poll1 本质是多个请求，每个请求到不同node，每个node的请求含多个partition，通过minB

zk+controller：controller通过抢占zk节点选举topic/partition/replica/broker变动：一般先zk，controller监听zk，本地Partition/ReplicaStateMachine处理，元数据同步至其他broker+更新zkconsumer rebalance：每个broker都是group coordinator位点存储：0.9之前是zk，之后内置topic消费组位点存储在内置topic的partition为P，P的leader所在节点为.

kafka：消息/存储/流处理partition:offset(每message占1),分区内有序，分区数可考虑为 broker 的倍数segment：baseOffset+file+offset index(relative offset-position)+timestamp index(timestamp - relative offset,注意后面到来的message如果timestamp更小则不入timestamp index)offset查找message：找segment（skiplis

at least once 事务/发送方确认+mandatory或备份交换器+queue和message持久化+处理完手动ack，通过业务去重，如幂等，如全局idat most once 随意发送，随意消费exactly once 即可靠传输且不重复，rabbitmq实现不了，比如consumer ack或 publisher confirm接收应答时网络问题导致重发amqp:rabbitmq实现了amqp，channel，exchange等概念来自于amqp，connection建立，channe

消息队列使用场景：解耦/最终一致性/广播/错峰与流控(解决producer，consumer速度差异矛盾)可靠投递（最终一致性）：带来重复性问题和延迟，A机器加钱，B机器扣钱，A本地事务保证加钱和消息一起落地，A可反复重发保证消息broker落地，broker保证消息consumer（B）落地，达到分布式事物业务解耦：A接口调用B，B消息调用A，避免循环依赖，你不再依赖多个下游了，只需要发消息...

客户端同步服务端异步。 Future<Result> future = request(server);//server立刻返回future synchronized(future){ while(!future.isDone()){ future.wait();//server处理结束后会notify这个future，并修改isdone标志 ...

exchange 和queue多对多关系，每个exchage和queue的绑定对应了bindingkey（direct，topic）每个message带routingkeyexchange类型direct bindingkey和routingkey完全相同，才扔进队列topic 通配：* 一个单词，# 没有或多个单词fanout 没有bindingkey，扔进exchange就扔...