核心记账业务可用jdk7的PriorityBlockingQueue优先阻塞队列结合乐观锁实现
-- 1、优先级阻塞队列
当前核心记账业务是悲观锁实现，但考虑到高并发和死锁的问题，可以用PriorityBlockingQueue优先阻塞队列结合乐观锁实现，对于并发时出现锁无法update时可以重新进入队列并调整优先级进行记账处理。
新方案：乐观锁：PriorityBlockingQueue<T> 优先级队列串行化记账请求，乐观锁处理账户表相关的数据一致性问题，当数据不一致时将优先级调整再次进入记账队列。
PriorityBlockingQueue是无界队列，与缓存线程池一样，使用时要千万注意控制，不然很容易消耗系统所有资源导致崩溃。
老方案：悲观锁： 更改账户表余额update语句：update t_account set amount = amount - quantity where amount >= quantity and ID = 12345
1、记流水，2、加减单边主账户余额（悲观锁），3、更新流水（主账户记账成功），4、异步请求处理完成单边账，更新流水状态，更新会计流水
--- 2、热点账户
账务系统会因为复式记账法业务而在交易到达一定数量级后成为热点，所以从交易流水就应该和账务核心分开，交易流水和单式记账作为一个层次，然后再请求账务核心和会计核心。这样也就缓冲了热点，后面分开的会计引擎，且调单边账的功能不能少了。
个人账户=资产，余额方向和发生方向都应该是双方，在余额变动时通过操作层面来判断。也可以设计成一方且不可红字，也可以设计成双方共同反应，同时有借方余额和贷方余额，只是在余额更新的时候多加条件判断，防止红字。(◎﹏◎) 综合还是共同反应比较好，余额字段保留，不过需要作为被动触发计算的字段，不会实时更新。
猜测：1、针对需要调银行网关的交易，调用网关实现交易后直接insert成功的单边流水，如果失败则insert失败的流水。
2、针对不调银行网关直接用账户余额的交易，则用带锁的update实现余额变动，成功后需要插入成功状态的流水，不成功则插入失败的流水。
流水插入失败必要回滚余额变动的update语句。这样做还有一个前提就是已开户且激活的有效用户。
注意：在2中不再是insert流水再等业务处理完毕update流水。
