Flink+Pulsar、Kafka问题分析及方案 -- 事务阻塞
Pulsar、Kafka的事务设计
Pulsar跟Kafka在设计事务功能时，在消费者读取消息的顺序方面，都采用了类似的设计。
比如说，先创建txn1，然后创建txn2，这两个事务生产消息到同一个topic/partition里，但是txn2比txn1先完成了，这个时候该不该让txn2生产的消息给consumer读取到？
Kafka设计文档中介绍如下：
Discussion on Transaction Ordering. In this design, we are assuming that the consumer delivers messages in offset order to preserve the behavior that Kafka users currently expect. A different way is to deliver messages in “transaction order”: as the consumer fetches commit markers, it enables the corresponding messages to be consumed.
Kafka采用的是offset order，就是说按照消息持久化的顺序来分发给consumer，而不是事务完成的顺序。
即txn2比txn1先完成了，也不会让txn2的消息立刻让consumer读取到，必须等到txn1完成才行。这种事务之间可能会有阻塞的行为，是用户必须要知晓的。
另外，这种阻塞的现象仅限于在同一个topic/partition，多个topic/partition之间的事务不会互相阻塞。
Pulsar也采用了类似的设计。
They are dispatched in published order instead of committed order. Since the consumer can only read messages before maxReadPosition, it increases end-to-end latency.
deep-dive-into-transaction-buffer-apache-pulsar
可以使用下面的测试代码进行验证：
public class TransactionTest {
private static final String topicName = "persistent://test/tb1/testTxn1";
static PulsarAdmin admin;
static PulsarClient client;
static ProducerBuilder<byte[]> producerBuilder;
static ConsumerBuilder<byte[]> consumerBuilder;
@BeforeClass
public static void initialize() throws PulsarClientException {
admin = PulsarAdmin.builder()
.serviceHttpUrl("http://164.90.77.83:8081")
.build();
client = PulsarClient.builder()
.serviceUrl("pulsar://164.90.77.83:6650")
.enableTransaction(true)
.build();
producerBuilder = client.newProducer()
.sendTimeout(0,TimeUnit.SECONDS)
.topic(topicName);
consumerBuilder = client.newConsumer()
.topic(topicName);
}
@AfterClass
public static void end() throws PulsarClientException {
admin.close();
client.close();
}
/**
* 使用两个事务txn1, txn2, txn2完成后查看是否能读取数据。
* 结论：
* 1. txn2由于在txn1后面创建，所以尽管txn2完成了，但是txn1没完成，就会阻塞txn2，txn2的数据不会被读取到。
* 2. txn1完成后，txn1、txn2的数据都能读取到，而且数据的顺序跟数据的produce顺序是相同的。（注意：不是跟事务的创建顺序相同）
*/
@Test
public void task() throws Exception{
admin.topics().resetCursor(topicName + "-partition-0", "my-subscription", MessageId.latest);
Consumer<byte[]> consumer=consumerBuilder.clone()
.subscriptionName("my-subscription")
.subscribe();
Producer<byte[]> producer=producerBuilder.clone()
.create();
Transaction transaction1 = client.newTransaction().build().join();
Transaction transaction2 = client.newTransaction().build().join();
producer.newMessage(transaction1).value("transaction1 test".getBytes()).send();
producer.newMessage(transaction2).value("transaction2 test".getBytes()).send();
Message<byte[]> message;
// commit txn2, but not commit txn1
transaction2.commit().join();
message = consumer.receive(8, TimeUnit.SECONDS);
assert message == null;
// commit txn1
transaction1.commit().join();
message = consumer.receive(8, TimeUnit.SECONDS);
assert message != null;
assert new String(message.getData()).equals("transaction1 test");
consumer.acknowledge(message);
message = consumer.receive(8, TimeUnit.SECONDS);
assert message != null;
assert new String(message.getData()).equals("transaction2 test");
consumer.acknowledge(message);
}
}
下面是Kafka的测试代码：
public class KafkaProducerTransactionalUnitTest {
private static final String TOPIC_NAME = "test_topic";
private static final String KAFKA_ADDRESS = ":9092";
private static final String CLIENT_ID = "test_client_id";
private static final int TRANSACTION_TIMEOUT_IN_MS = 3000;
private static KafkaProducer<String, String> kafkaProducer;
@BeforeAll
public static void init() {
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, KAFKA_ADDRESS);
props.put(ProducerConfig.CLIENT_ID_CONFIG, CLIENT_ID);
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "kafka_producer_id");
props.put(ProducerConfig.TRANSACTION_TIMEOUT_CONFIG, TRANSACTION_TIMEOUT_IN_MS);
kafkaProducer = new KafkaProducer<>(props);
kafkaProducer.initTransactions();
}
@AfterAll
public static void cleanup() {
kafkaProducer.close();
}
/**
* start two producer with different transactionalId, produce messages to the same topic.
* producer1 start txn1 -> producer2 start txn2 -> producer2 commit txn2 -> consumer consume messages.
* check if consumer can consume messages in txn2.
* result: txn1 will block the messages in txn2.
*/
@Test
public void testTwoProducerStuck() {
// Set up producer2 properties
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, KAFKA_ADDRESS);
props.put(ProducerConfig.CLIENT_ID_CONFIG, CLIENT_ID);
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "kafka_producer2_id");
props.put(ProducerConfig.TRANSACTION_TIMEOUT_CONFIG, 30000);
KafkaProducer<String, String> kafkaProducer2 = new KafkaProducer<>(props);
kafkaProducer2.initTransactions();
// set up consumer
Properties consumerProps = new Properties();
consumerProps.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, KAFKA_ADDRESS);
consumerProps.put(ConsumerConfig.ISOLATION_LEVEL_CONFIG, "read_committed");
consumerProps.put(ConsumerConfig.GROUP_ID_CONFIG, "test_transaction");
consumerProps.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "latest");
consumerProps.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
consumerProps.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(consumerProps);
consumer.subscribe(Collections.singletonList(TOPIC_NAME));
try {
// start txn1
kafkaProducer.beginTransaction();
String message = "Hello, Kafka";
ProducerRecord<String, String> record = new ProducerRecord<>(TOPIC_NAME, message);
kafkaProducer.send(record);
// kafkaProducer.commitTransaction();
// start txn2 and commit
kafkaProducer2.beginTransaction();
message = "Hello, Kafka2";
record = new ProducerRecord<>(TOPIC_NAME, message);
kafkaProducer2.send(record);
kafkaProducer2.commitTransaction();
// consume messages and check
ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(5));
assert records.isEmpty();
// commit txn1
kafkaProducer.commitTransaction();
// consume messages and check
records = consumer.poll(Duration.ofSeconds(5));
for (ConsumerRecord<String, String> record1 : records) {
System.out.printf("offset = %d, value = %s%n", record1.offset(), record1.value());
}
assert !records.isEmpty();
} catch (Exception ex) {
System.out.println(ex);
Assertions.fail("Failed to produce message with transaction");
} finally {
kafkaProducer2.close();
}
}
}
问题分析及方案
问题
Pulsar、Kafka这么设计的原因当然还是为了流式场景，因此，当我们尝试在其他场景中使用Kafka、Pulsar，那么这种设计就可能造成不少的麻烦。
就Flink而言，问题主要在于残留某些OPEN的事务没完结，导致后续的事务数据无法读取到。
有下面一些情形：
-
case1：
Flink可能有不从Checkpoint/Savepoint启动的场景：- 比如说用户创建一个topic，进行一些测试工作，这个时候会残留一些事务没结束掉。测试完成后准备用于线上生产，这个时候就会不从Checkpoint/Savepoint启动，而如果该topic还残留了OPEN的事务，就会导致线上生产的事务数据都无法读取到。
- 还有可能前面启动过任务，但是从来没成功打过checkpoint，这也会残留OPEN的事务。
-
case2：
Flink从Checkpoint/Savepoint启动时，对于前面没完结的事务都会存储在Checkpoint/Savepoint里，启动时会调用recoverAndCommit/recoverAndAbort方法来处理掉，一般这是没啥问题的。但是如果Flink任务成功执行了initializeState方法，即成功创建了新事务，但是在成功执行snapshotState前就失败挂掉了，则这个新创建的事务也是无法记录到Checkpoint/Savepoint里的，因此也会导致遗漏某些事务没有被完结。这种case也是很常见的。
简单分析
- Kafka因为使用的事务ID号都是固定的，因此使用固定的事务ID号去abort残留的事务即可。
- Pulsar事务ID号是不断变化的，不从checkpoint/snapshot启动就无法得知事务ID号，也就无法执行abort操作。
因为Pulsar事务commit操作幂等性的PR引入了一个clientName的配置，每个客户端使用的clientName都是固定的，因此我们可以增加一个接口，abort掉clientName对应的所有事务。
细节分析
Kafka方案
参考FlinkKafkaProducer 源码分析的 Abort残留的事务小节。
Pulsar方案
Pulsar由于是根据clientName去abort事务，而且一个subtask只有一个clientName，即
prefix + “-” + subtaskIndex （同一个job的多个并发子任务的prefix值都是相同的）
因此直接根据这一个clientName去abort即可。
所有并发子任务的clientName范围为[0 , parallelism)。
针对前面两个case进行处理：
-
case1：从checkpoint/savepoint中恢复
只需要abort掉当前ClientName对应的事务即可，即下面第一个红框部分代码。
-
case2：不从checkpoint/savepoint中恢复
跟kafka一样，可能会发生重启任务后并发度增大的情况，假设前面启动时的并发度为P1，当前启动的并发度为P2，因此前面的任务执行使用的ClientName范围为[0,P1 )，我们需要把这些ClientName对应的事务都abort一次，但是P1是不可知的。- 如果P2大于P1，即增加并发度，则
[0,P2 )肯定包含[0,P1 )，此时对[0,P2 )遍历abort一次即可。 - 如果P1大于P2，即降低并发度，则
[0,P2 )是[0,P1 )的子集，此时无法猜测要abort多少事务ID。
我们采用跟Kafka一样的策略：设定一个参数safeScaleDownFactor，即Flink任务减低并发度的比例不能超过这个，默认值为5。
比如说，第一次启动Flink任务的并发度为10，则第二次启动Flink任务的并发度至少为10/5=2。
通过这种方式，我们得知P1、P2的关系：P2*5>=P1
即[0,P2 * 5 )肯定包含[0,P1 )。
因此，我们对[0,P2 * 5 )范围内的ClientName都abort一次即可。
[0,P2 * 5 )范围内的ClientName还会平均分摊到当前P1个子任务去abort，各个子任务之间不会互相干扰，操作的ClientName都是不重叠的。
- 如果P2大于P1，即增加并发度，则