更新时间:2025-08-25 GMT+08:00

乐观锁并发提交冲突

乐观锁并发提交冲突的产生原因:多个修改作业(包括Insert、Update、Delete、MergeInto以及表服务操作)同时在LakeFormation上提交导致的并发提交冲突。例如:

上图中,Transaction1和Transaction2分别为两个DML事务,Transaction1基于元数据版本version1进行数据处理和提交,并将元数据版本更新至version2,而Transaction2在Transaction1提交前已经基于元数据版本version1开始了数据处理,在首次提交时,LakeFormation拒绝提交,因为此时元数据已经更新为version2,需要由Transaction2更新元数据后,再次提交。

在这种场景下,如果并发量非常大,或者某个事务做冲突检测的时间过久,则会陷入“提交冲突->更新元数据->检测冲突->再次提交”的死循环,导致业务冲突报错。

为解决上述问题,Iceberg引入四个参数。

表1 参数说明

参数名

说明

高并发场景下建议值

表服务场景下建议值

commit.retry.num-retries

最大重试次数

10

4

commit.retry.min-wait-ms

提交失败后,最小提交等待时间

100

1000

commit.retry.max-wait-ms

提交失败后,最大提交等待时间

10000

60000

commit.retry.total-timeout-ms

提交过程最长执行时间。

1800000

1800000