m0_43406494的博客

跟kafka一样，可能会发生重启任务后并发度增大的情况，假设前面启动时的并发度为P1，当前启动的并发度为P2，因此前面的任务执行使用的ClientName范围为[0,P1 )，我们需要把这些ClientName对应的事务都abort一次，但是P1是不可知的。Flink从Checkpoint/Savepoint启动时，对于前面没完结的事务都会存储在Checkpoint/Savepoint里，启动时会调用recoverAndCommit/recoverAndAbort方法来处理掉，一般这是没啥问题的。

这里有一个问题需要解决的：由于不从checkpoint/savepoint中启动，因此我们无法得知之前启动时的并发度，假设前面启动时的并发度为P1，当前启动的并发度为P2，因此前面的任务执行使用的事务ID范围为[0,P1 * PoolSize)，我们需要把这些事务ID都abort一次，但是P1是不可知的。因此我们还需要补充abort那些不在快照里的事务ID，因为Kafka connector的事务ID都是固定的，都在池子里存储着，而Context里存储了事务ID池子，因此恢复userContext后，

因为成功写入__terminated_txn_state 在更新事务状态为ABORTED之前，因此写入的事务元数据是aborting，因此对于Preserver保存的事务数据，我们应当视aborting等同于aborted，因为aborting的事务最终只可能为aborted，而如果到了查询Preserver里的数据的逻辑，那此时肯定已经抛出TransactionNotFound错误，已经删除掉对应的事务元数据了，因此此时肯定是aborted了。至于其他成员数据量比较大，如分区信息，都不序列化。

pulsar的transactionID是由broker分配的，不用用户设置，也没法设置；而kafka这里是用户设置的。kafka的ProducerID是由broker分配的，用户没法设置；但是pulsar的ProducerName是可以由用户设置的。kafka会复用transactionID，transactionID一个时刻对应一个事务，这个事务完成后可以复用这个transactionID开启下一个事务，broker会使用一个Map维护每个transactionID的元数据。

倘若commit失败(比如网络故障等)，Flink应用就会挂掉，然后根据用户重启策略执行重启逻辑，之后再次重试commit。举个例子，Pravega是Dell/EMC的一个开源流式存储系统，Flink搭配它也可以实现端到端的exactly-once semantics。左侧为正常事务的提交(以客户端的视角)流程，右侧为checkpoint 略缩版流程, 那么现在需要将这两部分逻辑融合起来。在过去的几年间，Flink开发出了checkpointing机制，而它则是提供这种应用内仅一次处理的基石。

Pulsar 各个Shedder分析及新的Shedder -- AvgShedder

Pulsar bundle数目的选择