这篇文章给大家介绍怎么解析Kafka中的事务消息，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
为了解决重试导致的消息重复、乱序问题，kafka引入了幂等消息。幂等消息保证producer在一次会话内写入一个partition内的消息具有幂等性，可以通过重试来确保消息发布的Exactly Once语义。
实现逻辑很简单:
区分producer会话
producer每次启动后，首先向broker申请一个全局唯一的pid，用来标识本次会话。
消息检测
message_v2 增加了sequence number字段，producer每发一批消息，seq就加1。
broker在内存维护(pid,seq)映射，收到消息后检查seq，如果，
new_seq=old_seq+1: 正常消息；new_seq<=old_seq : 重复消息；new_seq>old_seq+1: 消息丢失；
producer重试
producer在收到明确的的消息丢失ack，或者超时后未收到ack，要进行重试。
考虑在stream处理的场景中，需要多个消息的原子写入语义，要么全部写入成功，要么全部失败，这就是kafka事务消息要解决的问题。
事务消息是由producer、事务协调器、broker、组协调器、consumer共同参与实现的，
为producer指定固定的TransactionalId，可以穿越producer的多次会话(producer重启/断线重连)中，持续标识producer的身份。
使用epoch标识producer的每一次"重生"，防止同一producer存在多个会话。
producer遵从幂等消息的行为，并在发送的recordbatch中增加事务id和epoch。
引入事务协调器，以两阶段提交的方式，实现消息的事务提交。
事务协调器使用一个特殊的topic：transaction，来做事务提交日志。
事务控制器通过RPC调研，协调 broker 和 consumer coordinator 实现事务的两阶段提交。
每一个broker都会启动一个事务协调器，使用hash(TransactionalId)确定producer对应的事务协调器，使得整个集群的负载均衡。
broker处理在事务协调器的commit/abort控制消息，把控制消息向正常消息一样写入topic(和正常消息交织在一起，用来确认事务提交的日志偏移)，并向前推进消息提交偏移hw。
如果在事务过程中，提交了消费偏移，组协调器在offset log中写入事务消费偏移。当事务提交时，在offset log中写入事务offset确认消息。
consumer过滤未提交消息和事务控制消息，使这些消息对用户不可见。
有两种实现方式:
consumer缓存方式
设置isolation.level=read_uncommitted，此时topic的所有消息对consumer都可见。
consumer缓存这些消息，直到收到事务控制消息。若事务commit，则对外发布这些消息；若事务abort，则丢弃这些消息。
broker过滤方式
设置isolation.level=read_committed，此时topic中未提交的消息对consumer不可见，只有在事务结束后，消息才对consumer可见。
broker给consumer的BatchRecord消息中，会包含以列表，指明哪些是"abort"事务，consumer丢弃abort事务的消息即可。
事务消息处理流程如图1所示，
图1 事务消息业务流程
流程说明：
事务协调器是分配pid和管理事务的核心，produer首先对任何一个broker发送FindCoordinatorRequest，发现自己的事务协调器。
紧接着，producer向事务协调器发送InitPidRequest，申请生成pid。
2a.当指定了transactional.id时，事务协调器为producer分区pid，并更新epoch，把(tid,pid)的映射关系写入事务日志。同时清理tid任何未完成的事务，丢弃未提交的消息。
启动事务是producer的本地操作，促使producer更新内部状态，不会和事务协调器发生关系。
事务协调器自动启动事务，始终处在一个接一个的事务处理状态机中。
对于每一个要在事务中写消息的topic分区，producer应当在第一次发消息前，向事务处理器注册分区。
4.1a.事务处理器把事务关联的分区写入事务日志。
在提交或终止事务时，事务协调器需要这些信息，控制事务涉及的所有分区leader完成事务提交或终止。
4.2a. producer向分区leader写消息，消息中包含tid,pid,epoch和seq。
4.3. 提交消费偏移 -- AddOffsetCommitsToTxnRequest
4.3a. producer向事务协调器发送消费偏移，事务协调器在事务日志中记录偏移信息，并把组协调器返回给producer。
4.4a. producer向组协调器发送TxnOffsetCommitRequest，组协调器把偏移信息写入偏移日志。但是，要一直等到事务提交后，这个偏移才生效，对外部可见。
收到提交或终止事务的请求时，事务处理器执行下面的操作：
1. 在事务日志中写入PREPARE_COMMIT或PREPARE_ABORT消息(5.1a)。
2. 通过WriteTxnMarkerRequest向事务中的所有broker发事务控制消息(5.2)。
3. 在事务之日中写入COMMITTED或ABORTED消息(5.3)。
这个消息由事务处理器发给事务中所涉及分区的leader。
当收到这个消息后，broker会在分区log中写入一个COMMIT或ABORT控制消息。同时，也会更新该分区的事务提交偏移hw。
如果事务中有提交消费偏移， broker也会把控制消息写入 __consumer-offsets log，并通知组协调器使事务中提交的消费偏移生效。
当所有的commit或abort消息写入数据日志，事务协调器在事务日志中写入事务日志，标志这事务结束。
至此，本事务的所有状态信息都可以被删除，可以开始一个新的事务。
在实现上，还有很多细节，比如，事务协调器会启动定时器，用来检测并终止开始后长时间不活动的事务，具体请参考下面列出的kafka社区技术文档。
我们要认识到，虽然kafka事务消息提供了多个消息原子写的保证，但它不保证原子读。
例如，
1）事务向topic_a和topic_b两个分区写入消息，在事务提交后的某个时刻，topic_a的全部副本失效。这时topic_b中的消息可以正常消费，但topic_a中的消息就丢失了。2）假如consumer只消费了topic_a，没有消费topic_b，这样也不能读到完整的事务消息。3）典型的kafka stream应用从多个topic消费，然后向一个或多个topic写。在一次故障后，kafka stream应用重新开始处理流数据，由于从多个topic读到的数据之间不存在稳定的顺序(即便只有一个topic，从多个分区读到的数据之间也没有稳定的顺序)，那么两次处理输出的结果就可能会不一样。
也就是说，虽然kafka log持久化了数据，也可以通过指定offset多次消费数据，但由于分区数据之间的无序性，导致每次处理输出的结果都是不同的。这使得kafka stream不能像hadoop批处理任务一样，可以随时重新执行，保证每次执行的结果相同。除非我们只从一个topic分区读数据。
关于怎么解析Kafka中的事务消息就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
