多线程并发总结六 Actor Model和Event Driven

Actor Model也能有效的解决多线程的问题，跟CSP类似，他也是可以让变量由某一个Actor专门负责，而Actor是只会被一个线程执行的，所以也不会有多线程的问题。

Actor模型中的Actor类似CSP中的Process。CSP中的Process通讯相当于Actor中的信箱。

只是两者的定位并不一样，CSP主要用来解决某一个进程中的多线程问题，而Actor模型是一个分布式系统的逻辑架构模型。

简单介绍一下Actor模型。

• Actor可以存在于同一个进程里面，也可以存在于不同的进程里面。
• Actor和Actor之间通过把Message发送到对方Actor的信箱的方式来通信。
• Actor有上下级之间的关系，上级对其下级的Actor负责。
• Actor可以创建其他的Actor。
• Actor有状态，并且会根据状态决定如何应激之后的Message

例如一个管理Actor会留意资源的使用情况，如果发现资源使用率比较高，它就会负责创建更加多的Worker Actor来满足负载。但是如果发现有一个Worker Actor因为一些问题出了错，它会负责把这个Worker Actor进行重置。

Actor模型做的比较出名是爱立信的Erlang，当年爱立信利用Actor Model来实现它们的通信交换机，实现了高并发效率和高的无故障率（达到99.99999%）。

通信是真的很适合Actor模型的使用的，首先通信设施就是一层一层的监控，然后通信设备需要可以灵活的接入和拆除，根据不同的负责需要有动态的资源分配能力，通讯的双方甚至多方本身就是有状态的。这些林林种种都跟Actor模型不谋而合。

所以现在墙外的那款通讯软件Whatsapp其核心也是用Erlang来写的。如果觉得Erlang太过底层不能支持很多现代语言的特性，Elixir也是一个不错的选择，Elixir跟Erlang的关系就有点像TypeScript和Javascript一样，是一个对原语言的加强。

除了用来做通讯，我觉得网游的核心也很适合使用Actor Model，因为我们可以把玩家用户抽象看作Actor。

Akka是Actor模型在Java中的实现。

我们可以这样理解，Actor Model一定是Event Driven的，因为Actor之间是依靠Message来做信息交互的。

但是如果我们不需要有状态的Actor呢？典型的场景就是企业级的信息系统。信息都是持久化在数据库的。系统需要的弹性使用Event Driven已经可以很好的提供，那么我们可以使用相对Actor Model轻量级一些的框架，比如Java中的Vert.X框架。

Vert.X提供了一个Event总线，然后可以让不同的线程执行不同的逻辑来相应Event总线中的事件。

在这样的框架下，我们也有对应的一些方法来解决多线程的问题。

比如我们可以规定共享变量相关的逻辑只能由一个线程来执行，又或者共享的信息摆到Event里面由一个线程来消费。

所以既然多线程问题那么复杂，我们可以通过系统框架的层面来减低甚至避免多线程的问题。