三方接口补偿方案时针对重复失败数据入库的摘要处理如何处理哈希碰撞？

[leeqingshui]

业务系统与多个第三方系统进行对接时，需要调用外部系统接口进行数据的交换，如果在接口请求的过程中发生了网络抖动或其他问题，会导致接口调用失败； 对于此类问题，需要一个接口重新调用补偿机制，在发生网络抖动时可以进行自动或手动地补偿调用

搜寻资料时发下有人给过一个对应的方案，方案网址： https://cache.one/read/4640698

此解决方案是会对接口调用的数据进行记录，然后存到一个补偿表中，但上述方案的补偿表设计是否有问题？

其中定义了一个数据防重字段：unique_hash_code Unique_key Hash(class_name+method_name+method_param_values)

即根据方法类名加方法名及方法参数生成一个 hash 值，这个 hash 值会出现碰撞吧？

所以，针对于这个字段大佬你们是怎么设计的？增加字段再 hash 处理嘛？或者有啥其他更优的处理方案（ doge ）

[leeqingshui]

@zmal 嗯嗯，好哒~

[leeqingshui]

@msg7086 😂

[leeqingshui]

@lmshl 嗷，会考虑一部分逻辑使用这种实现~

[securityCoding]

老哥你都要补偿了，还反重有啥用，业务幂等就行

[wolfie]

@leeqingshui
根据 method 入参找文件，在将文件转 base64 作为请求参数。
我还是会出一个接口，作为补偿入口。因为反射不好管理。

这个是我写的基于 http 的补偿。
/t/882939

[leeqingshui]

@wolfie 嗯呢，我看到了，我这边也写了 80%，这周有空完善下，国庆我会把代码放出来，B 站再录个视频说明下~

[leeqingshui]

@wolfie 这块国庆抽时间弄了下~
视频地址：aHR0cHM6Ly9zcGFjZS5iaWxpYmlsaS5jb20vMjAzNTE2NzkzL3ZpZGVv
代码地址：aHR0cHM6Ly9naXRodWIuY29tL0Nocmlzc3NXb25nL2ludm9rZS1jb21wZW5zYXRpb24=

后面的优化下周会弄下~