Actor 模型到底怎么样？

Actor 和 CSP 可以极大的降低开发人员的心智负担

基于 actor 模型的分布式系统，不知道 云风 的 skynet （ lua 语言的）算不算，我就听说过一下，没有详细了解过

关于并发这事情，现在的 golang 甚至已经是政治正确的选择，各大厂商都在拼命往上面转，不过我觉得技术无一完美，多了解多实践最重要

当模型就是陈年渣渣了。论文？先补 Lambda: The Ultimate XXXXX 系列刷新三观。

刚好之前看过一本书 《反应式设计模式》里面非常详细说了 actor 模型和一系列生态。

要了解 actor，最好的途径是看 erlang

erlang 的成功案例就不必多说了吧

- actor 的性能到底性能
actor 模型的重点不是并发也不是性能，虽然现实中这些方面做得也不差

- 是否适合搭建一个微服务框架
actor 天生是分布式，可能甚至不需要“微服务”

- 能进行大规模应用吗 有没有什么
能，有，但是对只看了新闻的人意义有限

@momocraft 看来问对人了

- actor 天生是分布式，可能甚至不需要“微服务”
那如何做跨团队协作分工呢？

- 能，有，但是对只看了新闻的人意义有限
开源界有标杆吗？

- actor 模型的重点
不是并发，不是性能，那是什么咧？

@mywaiting 我发现技术限制越来越像电影。
无疑，大厂（电影团队）能产出很多优秀的技术（电影），但是，还是有很多小厂（小电影团队），能产出非常优秀的作品啊

go，flutter 都是 google 节奏带的。

比线程性能高，比协程更简单

Apache spark 就是 akka actor 的啊

elixir erlang 啥的

当你学完了 akka cluster 之后， 会有种想法撸一个分布式计算框架， 听人说过 spark 的出现打死了一电线杆的 akka 工程师

@widewing 2.0 后就是用 netty 了

actor 没有特别好的语言 /框架，erlang 生态太差了

csp 的话 go 很实用，干活快

csp 已 goroutine 这种形式， 工程实用性做的很极致了。 干活快才是真的好， 搞一个特别学院派纯血统的 ， 最后用起来很多人无法理解也没什么球用

Actor 的模型为什么会被吹起来，你可以找英文维基的 History of the Actor Model 这个词条，下面有一梭子论文可以吃。

然后你可能逐渐会发现，他们讲的和你看到的东西差不多是两码事。这是因为一开始作为 model，纯粹要的就是 model of computation，而不是体系结构研究里的 model of computer，所以性能之类的预设情形下是不管的，要关心的就是“表达能力”。

就 model 本身来看，并发实际上是很被强调的，卖点之一就是 concurrent computation modeling。只是 actor model 并不只是要做基于其它 model 上扩充的理论，而是要完整地替代先前的理论，所以当然不只是并发，只不过把顺序的计算当作并发的特例而已。就发展过程的特色来看，还有就是强调指称语义(denotational semantics) ，不过这个你用不上。

注意这里的并发和一般开发者理解的概念有不小距离。理论上，并发是指表达计算作用(computational effect) 的程序的非确定性组合(nondeterministic composition) ，要解决的是如何应对本质上不可预测发生的现象（例如，接受用户的输入作为一种计算上的副作用）的抽象问题。而实际开发者理解的并发经常和多任务混淆，认为并发关心的是某个计算任务在“何时”“是否同时”“如何发挥计算资源”这样的具体实现下的具体性质，还经常和并行（确定性的计算渐进行为）混淆。这种偏差导致真正意义上的 model 本身的性质并不容易直接被利用。

顺便，上面有人提到的线程是抢占式多任务的主要实现方式，强调某些计算资源的独占性。协程是协作式多任务的一种实现。这些和并发其实没啥直接关系……硬说的话，任务调度策略本身还能扯上点关系。要回到模型，在 actor model 里扯 threading，显然就很不 pure 了。其实也有其它扩充既有设计实现多任务的替代方法（而且理论上显而易见更优越只是不足以使工业界广泛接受），只不过听起来没那么主流知道的人稍微少点而已。比如抢占式多任务用 engine （ timed-lambda ），协作式多任务可以直接用 continuation。

至于你现在看到的具体框架的实现吹的 model，已经是跟 OOP 互相扯皮了……要知道 OOP 根本就几个的像样的 model （比较著名的也就是 Luca Cardelli 的 sigma calculus，相当地脱离实际而且睁眼说瞎话吹简单），理论上对比根本没什么意义……苦口婆心连 thread of execution 都上了地 red herring 黑了半天 OOP，站得住脚的合理理由就是它黑的 class-based OOP 在这方面确实过于弱鸡这点罢了，但实际上 OOP 在这个问题上几乎弱鸡到是个其它不建议共享可变状态的阵营的都能干翻（比如纯 FP ），并没有体现出非 actor model 才能上位这点。（而且更讽刺的是，Alan Kay 等强调的“正版” OOP 实际上用的也就是 message passing。）

所以选择 actor model 很大程度还是 political 的问题了。

Flink, spark 都是基于 akka, 千锤百炼

@FrankHB 你这又是在哪复制粘贴过来的内容，牛头不对马嘴，不知所云

Actor 的心智模型易于证明，符合思维模式。

@glues 我从我 stickynotes 复制的，回的标题的问题，有什么问题？你对 LZ 的标题有什么意见找 LZ，不要随便 at 回复得牛头不对马嘴。

顺便，上面有人提到的线程是抢占式多任务的主要实现方式
----

请问上面有哪个人提到你所说的这个？

actor -> Erlang
CSP -> Go

两者抽象对并发抽象程度不同，actor 是要明确发送者和接受者实体的，CSP 只关注通道。