消息处理及分布式锁的使用

之前同事遇到的场景，特意跟踪了一下这个单点问题

场景

在处理存管银行的收放款文件时，因为存在一人还款给多人，多人放款给一人，多人债转给多人的局部单点问题，账户系统使用了分布式锁来作为解决方案，从而达到缓解大量数据库乐观锁异常（由于乐观锁是在事务提交时发生，此时报错返回已经消耗了CPU和内存资源）

代码（还款为例）

处理步骤

1、尝试获取锁
getVirtualLock方法在内部设置了重试机制，是为了提高效率。
因为tryLock方法在获取锁失败时会立即返回，程序会结束并稍后利用MQ的重试机制再次处理，这样会增加消息服务器的负担，并且在高并发情况下，有较大几率获取不到锁，16次的重试次数会很快消耗完，消息进入死性队列。
虽然这里hold住了此线程，但权衡利弊其效率还是大于直接返回失败，主要是局部热点账户的场景会出现（还款、放款、债转），且常态。
2、业务逻辑处理
3、释放锁
业务逻辑处理完释放锁
4、记录错误
将业务参数错误导致的失败记录记录在error表，因为此类错误会一直失败，无法自动处理成功
5、错误处理
当MQ失败数达到上限时，录入error表