高并发分布式事务解决之道-Actor模型(附Akka与Reactor比较)

----- Actor模型

(1) 事务机制来由
为什么大多数互联网软件都是数据喂机器，或函数式即可，比如twitter或facebook，因为他们没有事务要求，一般涉及到钱等重要交易都需要事务，也可以这么说，非结构化的数据一般都没有事务要求，结构化聚合的数据才有事务要求。

(2) 事务例子
用户甲的操作
1.开始事务
2.访问表A
3.访问表B
4.提交事务
乙用户在操作
1.开始事务
2.访问表B
3.访问表A
4.提交事务 
如果甲用户和乙用户的两个事务同时发生，甲事务锁住了表A未释放(因为整个事务未完成)，正在准备访问B表，而乙事务锁住了表B未释放(因为整个事务未完成)，正在准备访问A表，可是A表被甲事务锁住了，等甲事务释放，而甲事务真正等待乙事务释放B表，陷入了无限等待，也就是死锁Dead Lock。

(3) 高并发事务解决之道
悲观锁 - 数据库表锁或行锁
乐观锁 - 版本控制
同步锁 - 单线程
Actor模型 - 行为消息队列（适用跨节点、分布式、高并发）
* 同步锁是单一JVM内的，对于分布式系统多个 Tomcat容器多个JVM，Actor模型能更好地“锁”好资源。

(4) Actor模型
Actor模型内部的状态由自己的行为维护，外部线程不能直接调用对象的行为，必须通过消息才能激发行为，这样就保证Actor内部数据只有被自己修改。
一个Actor如何处理多个Actor的请求呢？它先建立一个消息