在这个黑盒子中，保存了账户的余额200。

你想存款了，就发一个存款的消息过来，想取款就发一个取款的消息过来，发完消息就可以撤离了(异步操作)。

不管是有一个消息，还是有100个消息，统统放到黑盒子的一个队列中，然后让Account这个黑盒子一个个顺序处理， 对余额进行增加或减少。

外界无法看到余额，只能通过消息和这个黑盒子交互，黑盒子内部顺序处理，自然不用加锁。

这个黑盒子，就是Actor。

试一试用Actor方式来实现转账， 看看和之前有什么不同：

“转账 Actor” 收到转账50元的消息， 向账户A发送取出50元的消息， 向账户B发出存入50元的消息。

然后账户A 和 账户B 收到消息，进行处理。

非常清晰，根本不用锁， 每个Actor都是独立的个体，它们之间靠消息交互就行了。

可是，在转账过程中，如果有别的线程对账户A也做了操作，导致账户A余额不足，抛出了异常， 但是账户B继续存入50元，那这个转账其实就出错了!

这时候，我们想到了什么?对，就是事务的原子性：要么不做，要么全做。

所以需要让这些Actor支持事务，这可真是有点麻烦，因为Actor之间是独立的，消息的发送是异步的，现在转账却要求存入和取出两个操作需要同步进行，并且满足原子性。

世界上果然没有免费的午餐。

这里边要解决两个问题：

1. 账户A和账户B的Actor 需要互相等待，直到存入和取出的操作都完成，有任何一个没完成(如抛出异常)，就要回滚。

2. 由于消息发送都是异步的，在执行一个事务的时候，可能有其他消息放入消息队列，并且被处理，账户A和账户B的余额不断地被改变，需要处理这种不断变化的情况。