还在为状态的并发控制而痛苦吗？

 

还在因为数据库瓶颈而痛苦吗？

 

还在因为缓存的实时性控制而痛苦吗？

 

还在为了想分布式，但又不知道怎么下手而痛苦吗？

 

Actor适合你！！！

 

一、什么是Actor?

 

Actor提供了一个简单的方式来构建无锁分布式大规模的应用程序,而不需要学习和应用复杂的并发和分布式控制，先以电商场景为例进行简单介绍：

 

　　 商品库：商品库是电商的核心，商品库里包含成千上万个商品。

 

　　 历史问题：每个商品需要提供高并发访问，所以一般采用分布式缓存，但分布式缓存又引入状态同步（库存减少，价格变动)问题，这时候就需要如何精准快速的更新缓存。

　　 Actor解决问题：

　　1： 不在需要分布式缓存 

　　　　每个商品作为一个有状态的Actor存在集群当中，成千上万个商品会分散于整个集群中，我们不需要考虑某个商品存在于那个节点，我们只需要通过商品ID就能直接访问到集群内存中的商品状态，同时我们还无需考虑节点失效的问题，当节点失效后，Actor集群会自动把失效节点的商品Actor转移到其它节点，对访问者来说整个过程都是透明的。

 

　　2： 库存减少不再需要锁和队列。

　　　Actor是以单线程存在的，所有消息都是顺序到达的(作特殊标记可以让读消息并发到达，提高访问吞吐)，多个订单对库存的操作不会造成并发状态问题。

　　

　 　购物车：匿名用户和会员都有可能产生一个购物车，购物车的响应速度，直接影响了用户体验。

 

　　 历史问题：每次刷新页面，都需要读取用户的购物车信息，如果每次都从DB获取，将会存在很大问题，所以一半情况，每个购物车都会存在于缓存中，但也会引入缓存同步问题。另外购物车每次增减商品都会进行复杂的订单计算(满减，运费，折扣等等)，每次计算还需要考虑并发问题，同时计算完还需要及时更新缓存，整个流程复杂繁琐，控制麻烦。

 

　　 ctor解决问题：每个购物车作为一个有状态的Actor存在集群的缓存中，每次访问可以直接从缓存中读取到购物车数据。当用户增减商品的时候，直接在缓存中完成计算，并直接完成状态变更。

　　　　　　　　　　

总结：

 

Actor是分布式存在的内存状态及单线程计算单元，一个Id对应的Actor只会在集群种存在一个（有状态的 Actor在集群中一个Id只会存在一个实例，无状态的可配置为根据流量存在多个）,使用者只需要通过Id就能随时访问不需要关注该Actor在集群的什么位置。单线程计算单元又保证了消息的顺序到达,不存在Actor内部状态竞用问题。

 

　　这个特性让你可以很容易的开发一套高并发分布式的高拓展系统，而且不用关注并发和分布式控制。

 

 

Actor是永久存在的,一段时间没有消息,Actor会失活,从内存中释放,但只要有消息就会马上激活,但激活过程对访问者透明。

 

　　这个特性能很好的利用系统资源，而且提供了很友好的拓展，开发者可以在Actor失活时做一些自定义操作(例如保存状态),在激活时也可以做自定义操作(例如加载状态)

 

 

Actor和DDD,CQRS,Event Soucing设计模型有天然的融合性,基于Actor可以很好的进行以上实践.