实践遇到的一个新的交易场景：

　　多对一转账！

　　原交易系统定制了一些一对一、一对二、一对三的转账接口且固定账户类型的接口，不够通用。

　　为了避免新增一类业务开发一套转账事件的尴尬局面，秉承着DRY（不要重复写代码）原则决定写一套支持多对多转账的接口。

　　既然是在转账，那就一定绕不开经典的账户ABA问题。最简单有效的方案就是加锁。但上面提到了，我们这可是一个n对n转账的接口哦！

　　大家遇到这种场景怎么做呢？

　　这个接口设计来是要承载之后所有场景的交易的，因此，接口安全性、一定会有高并发场景，锁的性能就要尽可能高。

　　此处主要锁的问题，安全性方面，因为是内部service服务，不直接暴露到公网，且接口使用的交易类型是需要申请的，因此安全性方面暂过的去。

　　设计锁，首先了解这个场景，因为是通用接口，因此场景是不固定的，且会有多个账户，都需要。