高并发解决方案之Actor——第一节

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

 

还在由于数据库瓶颈而痛苦吗？

 

还在由于缓存的实时性控制而痛苦吗？

 

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

 

Actor适合你！！！

 

1、什么是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能够很好的进行以上实践.