后端学习 |
您所在的位置：网站首页 › kafka失败处理机制 › 后端学习 |
后端学习
|
一、前言 设想一个场景，生产者同时往多个不同分区写入数据，写着写着生产者突然宕机了，随后重启重新发送数据，对于之前消息接收成功的分区，生产者id重启发生改变，Kafka的幂等性失效，这部分消息接收成功的数据就会发生重复。为解决这种问题，Kafka在0.11版本后引入了事务支持，事务保证Kafka在Exactly Once语义的基础上，生产和消费可以跨分区和会话。通过事务机制，KAFKA 可以实现对多个 topic 的多个 partition 的原子性的写入，要么全部成功，要么全部失败。 二、生产者事务1.概述为了实现跨分区跨跨会话的事务，需要引入一个全局唯一的Transaction ID，并将生产者获得的id和Transaction ID绑定。这样当生产者重启后可以通过正在进行的Transaction ID获取原来的id。 为了管理Transaction，Kafka引入了一个新的组件Transaction Coordinator。生产者就是通过这个组件交换获得Transaction ID对应的任务状态。Transaction Coordinator还负责将事务所有写入Kafka的一个内部Topic（Transaction log），这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而进行进行。 2.Transaction Coordinatortransaction coordinator（事务协调者）是运行在每个 kafka broker 上的一个模块，是 kafka broker 进程承载的新功能之一。transaction coordinator负责分配PID和管理事务以及读写Transaction log。 3.Transaction logtransaction log 是 kafka 的一个内部 topic（类似大家熟悉的 __consumer_offsets ，是一个内部 topic）。transaction log 有多个分区，每个分区都有一个 leader，该 leade对应哪个 kafka broker，哪个 broker 上的 transaction coordinator 就负责对这些分区的写操作。transaction log 存储事务的最新状态和其相关元数据信息。 4.流程 生产者事务流程图生产者向任意kafka服务器发起请求获取相应事务协调者的地址。生产者通过指定的TID向事务协调者请求PID，若TID存在返回PID，不存在新建一个PID。每次请求TID，TID会加上一个Epoch值，防止旧的生产者因为宕机重启后重试事务，造成事务重复。生产者将消息存储的分区信息发给事务协调者，事务协调者将分区信息持久化。生产者向对应分区发送消息。生产者发起提交（commit）或者回滚请求（abort），事务协调者持久化该请求，标记为准备状态。事务协调者向分区发送提交或者回滚请求，分区执行完成后返回结果。事务协调者将处理结果持久化。5.LSOLSO与之前介绍的HW类似，用于防止消费者消费还未提交的事务，用户可以设置消费者的事务隔离级别控制能否消费未提交事务。设置为“read_uncommitted”将不受LSO影响，可以消费未提交事务；设置未“read_committed”将受到LSO影响，不能够消费未提交事务。  6.示例producer.beginTransaction();
try{
producer.send(new ProducerRecord("first","transaction test0"));
producer.send(new ProducerRecord("first","transaction test1"));
producer.commitTransaction();
}catch (Exception e){
producer.abortTransaction();
}三、消费者事务对于消费者来说，事务的保证就会相对较弱，尤其是无法保证提交的信息被精确消费。这是由于消费者可以通过offset访问任意信息，而且不同的Segment File生命周期不同，同一事务的消息可能会出现重启后被删除的情况。比如说有一条消息2天过期，消费者消费时正处于过期边缘，而后过期且消费者宕机重启，再次访问时消息就没有了。消费者事务一般而言与生产者事务配合使用，比如消费和生产都需要操作，且无论哪方宕机都会影响数据的一致性，这时就需要使用消费者事务与生产者事务配合。无论哪方宕机事务失败，都会全部失败，保证了数据的一致性。 附录其他学习内容后端学习内容 |
【本文地址】
今日新闻 |
推荐新闻 |