1
)顺序写磁盘
Kafka
的
producer
生产数据,要写入到
log
文件中,写的过程是一直追加到文件末端,
为顺序写。官网有数据表明,同样的磁盘,顺序写能到
600M/s
,而随机写只有
100K/s
。这
与磁盘的机械机构有关,顺序写之所以快,是因为其省去了大量磁头寻址的时间。
2
)零复制技术
![](https://i-blog.csdnimg.cn/blog_migrate/60bf73ce231f696a63e03c18a543c310.png)
5 Zookeeper 在 Kafka 中的作用
Kafka
集群中有一个
broker
会被选举为
Controller
,负责
管理集群
broker
的上下线
,所
有
topic
的
分区副本分配
和
leader
选举
等工作。
Controller
的管理工作都是依赖于
Zookeeper
的。
以下为
partition
的
leader
选举过程:
![](https://i-blog.csdnimg.cn/blog_migrate/f9273335f7544c1ee43aa336d3820090.png)
6 Kafka 事务
Kafka
从
0.11
版本开始引入了事务支持。事务可以保证
Kafka
在
Exactly Once
语义的基
础上,生产和消费可以跨分区和会话,要么全部成功,要么全部失败。
6.1 Producer
事务
为了实现跨分区跨会话的事务,需要引入一个全局唯一的
Transaction ID
,并将
Producer
获得的
PID
和
Transaction ID
绑定。这样当
Producer
重启后就可以通过正在进行的
Transaction
ID
获得原来的
PID
。
为了管理
Transaction
,
Kafka
引入了一个新的组件
Transaction Coordinator
。
Producer
就
是通过和
Transaction Coordinator
交互获得
Transaction ID
对应的任务状态。
Transaction
Coordinator
还负责将事务所有写入
Kafka
的一个内部
Topic
,这样即使整个服务重启,由于
事务状态得到保存,进行中的事务状态可以得到恢复,从而继续进行。
6.2 Consumer
事务
上述事务机制主要是从
Producer
方面考虑,对于
Consumer
而言,事务的保证就会相对
较弱,尤其时无法保证
Commit
的信息被精确消费。这是由于
Consumer
可以通过
offset
访
问任意信息,而且不同的
Segment File
生命周期不同,同一事务的消息可能会出现重启后被
删除的情况。