libprocess库，这是一个c++的actor模型

Actor模型

https://www.jianshu.com/p/d803e2a7de8e

目前家用PC四核已经非常常见，服务器更是达到32核64线程。为了高效的利用多核CPU，应该在代码层面就考虑并发性。经过十几年痛苦的开发经历，事实告诉我们线程并不是获取并发性的好方法，而往往会带来难以查找的问题。

为了防止过度分配，原生的方式是将检查和递减两步操作放到一个原子操作中，将两步操作锁定到一个操作中，就能够消除过度分配的可能性。

那为什么会有Actor模型呢？

因为传统并发模式中，共享内存是倾向于强一致性弱隔离性的，例如悲观锁同步的方式就是使用强一致性的方式控制并发，而Actor模型天然是强隔离性且弱一致性的，所以Actor模型在并发中有良好的性能，而且易于控制和管理。

Actor模型的设计是消息驱动和非阻塞的，吞吐量自然也被考虑在内。

Actor模型适用于对一致性需求不是很高且对性能需求较高的场景

为什么Actor模型是一种处理并发问题的解决方案呢？

处理并发问题一贯的思路是如何保证共享数据的一致性和正确性。

一般而言，有两种策略用来在并发线程中进行通信：共享数据、消息传递

使用共享数据的并发编程面临的最大问题是数据条件竞争data race，处理各种锁的问题是让人十分头疼的。和共享数据方式相比，消息传递机制最大的优势在于不会产生数据竞争状态。而实现消息传递有两种常见类型：基于channel的消息传递、基于Actor的消息传递。

为什么要保持共享数据的正确性呢？

无非是因为程序是多线程的，多个线程对同一个数据操作时若不加入同步条件，势必造成数据污染。

那么为什么不能使用单线程去处理请求呢？

大部分人认为单线程处理相比多线程而言，系统的性能将大打折扣。Actor模型的出现解决了这些问题。

Actor模型为并发而生，是为解决高并发的一种编程思路。使用并发编程时需要特别关注锁与内存原子性等一系列的线程问题，Actor模型内部的状态由自身维护，也就是说Actor内部数据只能由它自己通过消息传递来进行状态修改，所以使用Actor模型可以很好地避免这些问题。

Actor为什么一定程度上可以解决这些问题呢？

因为Actor模型下提供了一种可靠的任务调度系统，也就是在原生的线程或协程的级别上做了更高层次的封装，这会给编程模式带来巨大的好处：由于抽象了任务调度系统所以系统的线程调度可控，易于统一处理，稳定性和可维护性更高。另外开发者只需要关心每个Actor的逻辑即可从而避免了锁的滥用。

Actor就没有缺点吗？

当然不是，比如当所有逻辑都跑在Actor中的时候，很难掌握Actor的粒度，稍有不慎就可能造成系统中Actor个数爆炸的情况。另外，当必须共享数据或状态时很难避免使用锁，由于Actor可能会堵塞自己但Actor不应该堵塞它运行的线程，此时也许可选择使用Redis做数据共享。

Actor模型

Actor模型是1973年提出的一个分布式并发编程模式，在Erlang语言中得到广泛支持和应用。

在Actor模型中，Actor参与者是一个并发原语，简单来说，一个参与者就是一个工人，与进程或线程一样能够工作或处理任务。

可以将Actor想象成面向对象编程语言中的对象实例，不同的是Actor的状态不能直接读取和修改，方法也不能直接调用。Actor只能通过消息传递的方式与外界通信。每个参与者存在一个代表本身的地址，但只能向该地址发送消息。

在计算机科学领域，Actor是一个并行计算的数学模型，最初是为了由大量独立的微处理器组成的高并行计算机所开发的。

Actor模型的理念非常简单：万物皆Actor

Actor模型将Actor当作通用