Kafka-事务

abc

消费者会将msg都拉取走，由程序自己处理事务成功的

这是最简单的形式：只有一个Producer生产数据

消息传递的等级：最多一次（at most once）：消息可能会丢失，但绝不会被重复发送。至少一次（at least once）：消息不会丢失，但有可能被重复发送。精确一次（exactly once）：消息不会丢失，也不会被重复发送。

msg

Txid+PID+id+epoch

producer 1

PID+id+1

生产发送数据

重试机制

Producer 1僵尸生产者

def

幂等+事务+僵尸producer的剔除递增 epoch来屏蔽僵尸生产者，同一事务下只能有一个producer存活

幂等设计方案

Txid+PID+id+1

Kafka

Txid+PID+id+1+epoch

PID+id

Kafka端也需要维护一种机制：TOPIC下要维护id如果写成功了要更新id，之后只接受比id大的值写入成功后会返回Offset，告诉生产端你是第几条数据

Topic 的 Partition 分区内部有序，外部无序；多个Producer对一个分区生产数据，结果无序；如果想要保证结果有序，用一个producer向一个Partition写入N -> 1 :        N个Producer向1个Partition写入无序性                 Producer之间无法协商顺序----------------------------------------------------------边界1 -> 1 :        1个Producer向1个Partition写入顺序性1 -> N:         1个Producer向N个Partition写入原子性结论：Kafka的事务是面向一个Producer的

双端侵入双端规定一种机制来处理之间的交互

两个Producer向一个topic生产数据幂等+事务加上Txid事务id，消息归属哪个事务

Txid+PID+id

Producer

Producer 2

Producer如何开启幂等性：    font color=\"#f44336\

id

Producer 1

mark

重试机制会导致数据在kafka中存储出现重复，因为kafka不关心数据的内容。如何保证消息的MSG幂等性呢？解决办法： 生产端增加一种机制      给相同内容的消息加上id，这样相同的内容id也是相同的，kafka端发现相同id后不再处理，保证了生产端的幂等性。

id+1

消息间有事务的水印/栅栏/围栏记录msg的事务提交状态

id=sequence number

参照第三方的机制也可以用id+state，更新state的状态状态机

事务的5大要素：Sequence Number：消息序号，                              全局唯一           防止重试的重复性，保证幂等PID：                         ProducerID，                        全局唯一           区分生产者，保证数据的完整性、幂等性、排他性                                                                                                               PID+SNum解决重试Retry的幂等和不同producer的排他性，保证数据完整  Txid：                        事务ID， 人为给出                   全局唯一           区分事务，约束跨producer，session生命周期的Epoch：                     事务内Producer的纪元ID，    全局唯一           防止僵尸生产者，只能一个producer存活                                                                                                                Txid+Epoch 保证某一时刻只能有一个最新的epoch的producer存活Mark：                      水印|栅栏，                                                      一个事务提交时才有的标志msg   记录事务的提交状态

Kafka的事务是在生产侧是一端的（非双端）Kafka的事务是面向一个Producer的

consumer

事务提交失败

事务提交成功

生产者：存储可靠性级别：ACK  -1、0、1通信可靠性，网络（P 区域）是不可靠的，重试机制：retry（网络波动导致的，不是Producer导致的）       重试会导致数据出现重复，但是可以保障数据的完整。================================需求：消息MSG(message)幂等，如何解决？解决方式：       首先设置 ACK：-1                      Retry：True         开启重试机制         之后按照右边所画之图的方式进行幂等处理。

日志 log记录失败的事务的metadata

两个Producer同时向一个Topic生产数据各自维护自己的id会出现id重复，导致其他的producer数据无法写入如何解决？

解决方式：加上个是的PID，来进行区分id

Partition