之前系统中有这样一处代码：
在线上运行一段时间后，这个任务线程竟然莫名其妙地退出了，要不是后来添加了一些日志信息，以及thread-dump分析，根本不晓得这个任务早都没有了。原因就是handler方法里面抛出了unchecked异常NullPointerException，导致该任务直接退出了，while循环直接退出结束。后来用try…catch包裹了handler方法，才能让其幸存下来，并且异常也打印出来了。
我们用try-catch来获取异常信息，打印日志，查看bug代码，然后修复重新发布，一段时间后可能又会抛出另外一个什么unchecked异常后，又要重复这样。
目前的做法基本是这样的，但话说，如果这个任务线程很关键，是p0级的，是会导致飞机失联的（^o^），那根本不允许经过这些漫长的步骤来修复，然后重新发布运行。如果系统能够自动容错，自动处理这些异常和错误，而且仍然保持运行，那情况可能就不一样了，为此本文抛砖引玉，介绍一下actor编程模型。
二、 Actor编程模型
Actor思想是由 Carl Hewitt在1973年提出来的，Erlang/OTP的出现使得actor编程理论得到完美呈现，之后其他的actor系统和框架（如本文后面会提到的akka，scala等等）都是或多或少借鉴了Erlang的实现思想。
Actor的特点： concurrent,
distributed, and fault tolerant。
1. actor基本介绍
引言中提到的“容错”只是actor编程模型中的一个特征，另外还包括并发和分布式。
Ø actor
在面对复杂任务时，我们常常需要将其分解为一个个小的任务单元来将问题分而治之。在actor编程思想里面，有3个重点方面：a)任务单元是足够轻量级的，创建成本很小；b)任务单元通过异步消息进行通信，不共享内存；b)任务单元的调度执行是由底层框架来负责的，而不是映射为一个OS级的执行线程，因此可以一个系统中可以创建上百万的任务单元。
上面的任务单元被称为一个actor，这些特点为业务提供了很方便的并发和并行特性。首先，没有了“锁”的概念，不再需要在各种锁的并发竞争中挣扎，其次，actor是由底层框架进行调度，不是OS级线程的调度切换，使得系统上下文切换不会抓狂。
Ø 容错
Actor系统的容错是通过监控来保证的，actor可以创建一个新actor，创建actor的父actor需要负责其子actor的监控任务，一般创建一个新子actor的时候要定义一个监控策略（Supervisor
Strategy），该策略定义了怎么处理子actor抛出的错误，以及如何重启、恢复甚至结束子actor。整个actor系统会是一个稳健的监控树构成。
Joe Armstrong（Erlang作者）语录：
在构建可容错软件系统的过程中要解决的本质问题就是故障隔离。不同的程序员会编写不同的模块，有的模块正确，有的存在错误。我们不希望有错误的模块对没有错误的模块产生任何不利的影响。
因为消除大型软件系统中的这类软件错误仍然是一个未解的难题，所以我认为构建大型的可靠系统的唯一现实的方法就是把系统分解成许多独立的并行进程，并为监控和重启这些进程提供一些机制。
Ø 分布式
在actor系统中，actor之间的通信是通过消息传递来实现的，然而两个进行消息传递通信的actor可以位于同一个机器（或者运行节点，因为一个机器可以运行多个实例），也可以位于不同的机器（或节点）中。也就是说actor的位置对于业务程序来说是透明的，不需要关心底层通信细节，而且保证通信原语（即传递消息的方式）是一样。
三、 小结
编程的困难在于抽象（Joe Armstrong），Actor编程思想为我们构建大型的分布式系统提供了参考和借鉴，我们并不一定要用，但是可以学习参考一下，拓展视野，就好比产品经理不能仅会Axure，也要学习用户心理学是一样的道理。
四、 参考
1. http://en.wikipedia.org/wiki/Actor
2. Joe
Armstrong博士论文《面向软件错误构建可靠的分布式系统》
3. http://www.erlang.org/doc/design_principles/des_princ.html
4. http://doc.akka.io/docs/akka/2.3.0/general/actors.html
5. http://www.scala-lang.org/what-is-scala.html
本文摘自：http://www.xuebuyuan.com/2198538.html
410
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
