乐观锁并发提交冲突
乐观锁并发提交冲突的产生原因:多个修改作业(包括Insert、Update、Delete、MergeInto以及表服务操作)同时在LakeFormation上提交导致的并发提交冲突。例如:
上图中,Transaction1和Transaction2分别为两个DML事务,Transaction1基于元数据版本version1进行数据处理和提交,并将元数据版本更新至version2,而Transaction2在Transaction1提交前已经基于元数据版本version1开始了数据处理,在首次提交时,LakeFormation拒绝提交,因为此时元数据已经更新为version2,需要由Transaction2更新元数据后,再次提交。
在这种场景下,如果并发量非常大,或者某个事务做冲突检测的时间过久,则会陷入“提交冲突->更新元数据->检测冲突->再次提交”的死循环,导致业务冲突报错。
为解决上述问题,Iceberg引入四个参数。
参数名 |
说明 |
高并发场景下建议值 |
表服务场景下建议值 |
---|---|---|---|
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 |