网站推广项目,别人网站建设多少钱,网站兼容,可以推广的app有哪些写在开始一般来说有两种策略用来在并发线程中进行通信#xff1a;共享数据和消息传递。使用共享数据方式的并发编程面临的最大的一个问题就是数据条件竞争。处理各种锁的问题是让人十分头痛的一件事。传统多数流行的语言并发是基于多线程之间的共享内存#xff0c;使用同步方… 写在开始 一般来说有两种策略用来在并发线程中进行通信共享数据和消息传递。使用共享数据方式的并发编程面临的最大的一个问题就是数据条件竞争。处理各种锁的问题是让人十分头痛的一件事。 传统多数流行的语言并发是基于多线程之间的共享内存使用同步方法防止写争夺Actors使用消息模型每个Actor在同一时间处理最多一个消息可以发送消息给其他Actor保证了单独写原则。从而巧妙避免了多线程写争夺。和共享数据方式相比消息传递机制最大的优点就是不会产生数据竞争状态。实现消息传递有两种常见的类型基于channelgolang为典型代表的消息传递和基于Actorerlang为代表的消息传递。Actor简介Actor模型(Actor model)首先是由Carl Hewitt在1973定义 由Erlang OTP 推广其 消息传递更加符合面向对象的原始意图。Actor属于并发组件模型通过组件方式定义并发编程范式的高级阶段避免使用者直接接触多线程并发或线程池等基础概念。Actor模型数据行为消息。 Actor模型是一个通用的并发编程模型而非某个语言或框架所有几乎可以用在任何一门编程语言中其中最典型的是erlang在语言层面就提供了Actor模型的支持杀手锏应用RabbitMQ 就是基于erlang开发的更加面向对象 Actor类似面向对象编程OO中的对象每个Actor实例封装了自己相关的状态并且和其他Actor处于物理隔离状态。举个游戏玩家的例子每个玩家在Actor系统中是Player 这个Actor的一个实例每个player都有自己的属性比如Id昵称攻击力等体现到代码级别其实和我们OO的代码并无多大区别在系统内存级别也是出现了多个OO的实例 class PlayerActor { public int Id { get; set; } public string Name { get; set; } }无锁 在使用Java/C# 等语言进行并发编程时需要特别的关注锁和内存原子性等一系列线程问题而Actor模型内部的状态由它自己维护即它内部数据只能由它自己修改(通过消息传递来进行状态修改)所以使用Actors模型进行并发编程可以很好地避免这些问题。Actor内部是以单线程的模式来执行的类似于redis所以Actor完全可以实现分布式锁类似的应用。 异步 每个Actor都有一个专用的MailBox来接收消息这也是Actor实现异步的基础。当一个Actor实例向另外一个Actor发消息的时候并非直接调用Actor的方法而是把消息传递到对应的MailBox里就好像邮递员并不是把邮件直接送到收信人手里而是放进每家的邮箱这样邮递员就可以快速的进行下一项工作。所以在Actor系统里Actor发送一条消息是非常快的。这样的设计主要优势就是解耦了Actor数万个Actor并发的运行每个actor都以自己的步调运行且发送消息接收消息都不会被阻塞。隔离 每个Actor的实例都维护这自己的状态与其他Actor实例处于物理隔离状态并非像 多线程锁 模式那样基于共享数据。Actor通过消息的模式与其他Actor进行通信与OO式的消息传递方式不同Actor之间消息的传递是真正物理上的消息传递。天生分布式 每个Actor实例的位置透明无论Actor地址是在本地还是在远程机器上对于代码来说都是一样的。每个Actor的实例非常小最多几百字节所以单机几十万的Actor的实例很轻松。如果你写过golang代码就会发现其实Actor在重量级上很像Goroutine。由于位置透明性所以Actor系统可以随意的横向扩展来应对并发对于调用者来说调用的Actor的位置就在本地当然这也得益于Actor系统强大的路由系统。生命周期 每个Actor实例都有自己的生命周期就像C# java 中的GC机制一样对于需要淘汰的Actor系统会销毁然后释放内存等资源来保证系统的持续性。其实在Actor系统中Actor的销毁完全可以手动干预或者做到系统自动化销毁。容错 说到Actor的容错不得不说还是挺令人意外的。传统的编程方式都是在将来可能出现异常的地方去捕获异常来保证系统的稳定性这就是所谓的防御式编程。但是防御式编程也有自己的缺点类似于现实防御的一方永远不能100%的防御住所有将来可能出现代码缺陷的地方。比如在java代码中很多地方充斥着判断变量是否为nil这些就属于防御式编码最典型的案例。但是Actor模型的程序并不进行防御式编程而是遵循“任其崩溃”的哲学让Actor的管理者们来处理这些崩溃问题。比如一个Actor崩溃之后管理者可以选择创建新的实例或者记录日志。每个Actor的崩溃或者异常信息都可以反馈到管理者那里这就保证了Actor系统在管理每个Actor实例的灵活性。劣势天下无完美的语言框架/模型亦是如此。Actor作为分布式下并发模型的一种也有其劣势。01由于同一类型的Actor对象是分散在多个宿主之中所以取多个Actor的集合是个软肋。比如在电商系统中商品作为一类Actor查询一个商品的列表在多数情况下经过以下过程首先根据查询条件筛选出一系列商品id根据商品id分别取商品Actor列表很可能会产生一个商品搜索的服务无论是用es或者其他搜索引擎。如果量非常大的话有产生网络风暴的危险虽然几率非常小。在实时性要求不是太高的情况下其实也可以独立出来商品Actor的列表利用MQ接收商品信息修改的信号来处理数据一致性的问题。02在很多情况下基于Actor模型的分布式系统缓存很有可能是进程内缓存也就是说每个Actor其实都在进程内保存了自己的状态信息业内通常把这种服务成为有状态服务。但是每个Actor又有自己的生命周期会产生问题吗呵呵也许吧。想想一下还是拿商品作为例子 如果环境是非Actor并发模型商品的缓存可以利用LRU策略来淘汰非活跃的商品缓存来保证内存不会使用过量如果是基于Actor模型的进程内缓存呢每个actor其实就是缓存本身就不那么容易利用LRU策略来保证内存使用量了因为Actor的活跃状态对于你来说是未知的。03分布式事物问题其实这是所有分布式模型都面临的问题非由于Actor而存在。还是以商品Actor为例添加一个商品的时候商品Actor和统计商品的Actor很多情况下确实被设计为两类Actor服务需要保证事物的完整性数据的一致性。在很多的情况下可以牺牲实时一致性用最终一致性来保证。04每个Actor的mailBox有可能会出现堆积或者满的情况当这种情况发生新消息的处理方式是被抛弃还是等待呢所以当设计一个Actor系统的时候mailBox的设计需要注意。写在最后 升华一下1通过以上介绍既然Actor对于位置是透明的任何Actor对于其他Actor就好像在本地一样。基于这个特性我们可以做很多事情了以前传统的分布式系统A服务器如果想和B服务器通信要么RPC的调用http调用不太常用要么通过MQ系统。但是在Actor系统中服务器之间的通信都变的很优雅了虽然本质上也属于RPC调用但是对于编码者来说就好像在调用本地函数一样。其实现在比较时兴的是Streaming方式。2由于Actor系统的执行模型是单线程并且异步所以凡是有资源竞争的类似功能都非常适合Actor模型比如秒杀活动。3基于以上的介绍Actor模型在设计层面天生就支持了负载均衡而且对于水平扩容支持的非常好。当然Actor的分布式系统也是需要服务注册中心的。4虽然Actor是单线程执行模型并不意味着每个Actor都需要占用一个线程其实Actor上执行的任务就像Golang的goroutine一样完全可以是一个轻量级的东西而且一个宿主上所有的Actor可以共享一个线程池这就保证了在使用最少线程资源的情况下最大量化业务代码。●程序员过关斩将--论商品促销代码的优雅性●程序员过关斩将--你的面向接口编程一定对吗●程序员修神之路--高并发下为什么更喜欢进程内缓存●程序员修神之路--高并发优雅的做限流有福利●程序员过关斩将--快速迁移10亿级数据●程序员修神之路--分布式缓存的一条明路附代码●程序员修仙之路--把用户访问记录优化到极致互联网之路菜菜与君一同成长长按识别二维码关注仙女都在看据说点赞的都是美女帅哥
