关键词：
写在开始
一般来说有两种策略用来在并发线程中进行通信：共享数据和消息传递。使用共享数据方式的并发编程面临的最大的一个问题就是数据条件竞争。处理各种锁的问题是让人十分头痛的一件事。
传统多数流行的语言并发是基于多线程之间的共享内存，使用同步方法防止写争夺，Actors使用消息模型，每个Actor在同一时间处理最多一个消息，可以发送消息给其他Actor，保证了单独写原则。从而巧妙避免了多线程写争夺。和共享数据方式相比，消息传递机制最大的优点就是不会产生数据竞争状态。实现消息传递有两种常见的类型：基于channel（golang为典型代表）的消息传递和基于Actor（erlang为代表）的消息传递。
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可以共享一个线程池，这就保证了在使用最少线程资源的情况下，最大量化业务代码。
数据存储redis第四章：高并发下实现分布式锁(代码片段)
直接上代码：大部分互联网公司实现分布式锁原理/***分布式锁底层实现原理*@return*/@GetMapping("distributedLock")publicObjectdistributedLock()StringlockKey="distributedLockKey";//给每个线程都设置一个唯一标识，避免出现程序执行的时间超过设置的... 查看详情
day783.网络通信优化之i/o模型：如何解决高并发下i/o瓶颈-java性能调优实战(代码片段)
网络通信优化之I/O模型：如何解决高并发下I/O瓶颈Hi，我是阿昌，今天学习记录的是关于网络通信优化之I/O模型：如何解决高并发下I/O瓶颈。提到JavaI/O，相信你一定不陌生。可能使用I/O操作读写文件，也可... 查看详情
actor模型(代码片段)
#Actor模型Actor的目的是为了解决分布式编程中的一系列问题。所有消息都是异步交付的，因此将消息发送方与接收方分开，正是由于这种分离，导致actor系统具有内在的并发性：可以不受限制地并行执行任何拥有输入消息的actor。... 查看详情
漫画：高并发下的hashmap(代码片段)
这一期我们来讲解高并发环境下，HashMap可能出现的致命问题。 HashMap的容量是有限的。当经过多次元素插入，使得HashMap达到一定饱和度时，Key映射位置发生冲突... 查看详情
高并发下的web异步处理方案(代码片段)
高并发下的web异步处理方案一、问题介绍平时web开发时（使用的servlet或者基于servlet封装的SpringMVC框架），业务处理基本都是同步处理，即业务处理与web容器接收线程为同一线程，每一次Http请求都由一个线... 查看详情
面试实战考核：设计一个高并发下的下单功能(代码片段)
功能需求：设计一个秒杀系统初始方案商品表设计：热销商品提供给用户秒杀，有初始库存。@EntitypublicclassSecKillGoodsimplementsSerializable@IdprivateStringid;/***剩余库存*/privateIntegerremainNum;/***秒杀商品名称*/privateStringgoodsName;秒杀订单表... 查看详情
分布式事务,高并发下分布式事务的解决方案
...据库本身保证的。今天，我将介绍一种比较复杂的事务：分布式事务。1、什么是分布式事务分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是... 查看详情
高并发下，hashmap会产生哪些问题？(代码片段)
HashMap在高并发环境下会产生的问题HashMap其实并不是线程安全的，在高并发的情况下，会产生并发引起的问题：比如：HashMap死循环，造成CPU100%负载触发fail-fast下面逐个分析下出现上述情况的原因：HashMap死循环的原因HashMap进行存... 查看详情
分布式高并发下全局id生成策略
数据在分片时，典型的是分库分表，就有一个全局ID生成的问题。单纯的生成全局ID并不是什么难题，但是生成的ID通常要满足分片的一些要求： 1不能有单点故障。 2以时间为序，或者ID里包含时间。这样一是可... 查看详情
深入理解分布式事务,高并发下分布式事务的解决方案
这两天正在研究微服务架构中分布式事务的处理方案,做一个小小的总结,作为备忘.如有错误,欢迎指正!概念澄清事务补偿机制:在事务链中的任何一个正向事务操作,都必须存在一个完全符合回滚规则的可逆事务.CAP理论:CAP(Consistency... 查看详情
高并发下秒杀商品，这9个细节得知道(代码片段)
大家好，我是bigsai，又跟大家见面了。前言高并发下如何设计秒杀系统？这是一个高频面试题。这个问题看似简单，但是里面的水很深，它考查的是高并发场景下，从前端到后端多方面的知识。秒杀一般出... 查看详情
高并发下如何避免产生重复数据？(代码片段)
前言最近测试给我提了一个bug，说我之前提供的一个批量复制商品的接口，产生了重复的商品数据。追查原因之后发现，这个事情没想象中简单，可以说一波多折。1.需求产品有个需求：用户选择一些品牌... 查看详情
高并发下如何避免产生重复数据？(代码片段)
前言最近测试给我提了一个bug，说我之前提供的一个批量复制商品的接口，产生了重复的商品数据。追查原因之后发现，这个事情没想象中简单，可以说一波多折。1.需求产品有个需求：用户选择一些品牌... 查看详情
高并发下秒杀商品，你必须知道的9个细节(代码片段)
前言高并发下如何设计秒杀系统？这是一个高频面试题。这个问题看似简单，但是里面的水很深，它考查的是高并发场景下，从前端到后端多方面的知识。秒杀一般出现在商城的促销活动中，指定了一定数量&#... 查看详情
高并发下秒杀商品，你必须知道的9个细节(代码片段)
大家好，我是苏三，又跟大家见面了。前言高并发下如何设计秒杀系统？这是一个高频面试题。这个问题看似简单，但是里面的水很深，它考查的是高并发场景下，从前端到后端多方面的知识。秒杀一般出... 查看详情
高并发下保证接口的幂等性的几种方式(代码片段)
高并发下保证接口的幂等性的几种方式--洱涷Zz场景不知道你有没有遇到过这些场景：有时我们在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样。我们在项目... 查看详情
高并发下保证接口的幂等性的几种方式(代码片段)
高并发下保证接口的幂等性的几种方式--洱涷Zz场景不知道你有没有遇到过这些场景：有时我们在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样。我们在项目... 查看详情
高并发下的批量处理与单个处理（利用jdk8新特性处理，提高性能）(代码片段)
1、技术选型：SpringBoot2、案例：实体类：packagecom.zhangwl.complicatedemo.pojo;importjava.sql.Timestamp;/***@ClassNameGoods*@Description*@Authorzhangwl*@Date2019/10/30:54*@Version1.0**/publicclassGoodsprivateStrin 查看详情