《Akka应用模式：分布式应用程序设计实践指南》读书笔记9

性能

　　这也是一个比较大的问题，因为性能不一定是Akka本身的问题，还可能是你代码写的有问题。

　　优化的第一步就是找出性能的瓶颈，隔离出应用程序里面比较耗时的部分，然后尝试对其优化，减少需要耗费的时间成本。其实有时候对性能进行度量往往比优化性能还重要，因为你在度量性能的时候，已经在思考哪些可能是性能瓶颈了，这过程中就会不由自主的对其进行了优化。性能测试往往是找出那些超出预期的性能问题。

隔离瓶颈

　　性能优化的第一步就是识别瓶颈，这是一个技术活。

优化Akka

　　只有在确定了是Akka的问题之后再动手优化Akka，但大部分情况优化的都是业务逻辑和代码逻辑，跟Akka本身关系不大。

减少或隔离阻塞型操作

　　个人感觉使用Akka就一定要遵守Actor模型的几个约束，其中一个很重要的约束就是每条消息处理一定要快，且最好是异步通信。这一点对于Akka新手来说，并不太好理解，或者理解的不够深刻。如果一个操作耗时不长，就没必要用Actor模型了，如果耗时太长，Actor又要求尽量要快，这不就是矛盾么？还要Akka干啥。其实这是我刚开始学Akka时候的疑问和不解。不过用下来才发现，如果你有一个目标：Actor消息处理一定要快。你就会无形中对一个操作尽可能的拆分，使其异步、短小，当然了带来的问题就是消息类型比较复杂。

　　使用Akka时，不可避免的用到JDBC或文件等IO操作，这类操作有可能很慢且都是阻塞性操作，但并不代表不能把他设计成异步、非阻塞的。比如有一个流程如下：1.写数据库；2.写入成功后执行后续操作。我们往往是同步、阻塞的操作，但其实可以用future或异步JDBC将其拆分成两步：写数据库、成功后执行操作。比如把写入消息发送给单独的actor，该actor收到写入消息，对其进行写入然后把结果异步的返回给原来的actor，原actor收到写入成功的消息后执行后续操作。虽然并不一定解决阻塞的问题，但把阻塞的问题进行了隔离，因为阻塞只有在数据库actor才会有。但原actor却可以处理更多的消息。由于写数据库相关的消息都被封装到单独的actor，那么我们可以采取批量的方法，把数据插入数据库，以提高插入的性能和吞吐量。如果还与原actor的业务逻辑混到一块，就很难优化了。

　　再进一步，还可以将插入数据库的actor放到单独的派发器，提高原actor的并发量。

缩短消息处理时间

　　这和你显然是一句废话。但确实一个优化的方向，如何缩短呢？还是那个“分而治之”的思想，具体的方法大家就各自参悟吧，^_^。

增加处理消息的actor

　　这其实也是一个好方法，无形中增加了并行数量。当然前提是各个actor没有争用资源，即使有争用也要对其进行解耦，减少争用时间和范围。Akka集群中增加actor数量，还可以充分利用各个节点的资源。当然了，这会增加系统的复杂性，不过使用Akka本身就是解决复杂系统的，简单的系统用Akka好像没啥必要。

派发器

　　派发器是优化Akka的关键组件。这一点需要对派发器有深入的理解，刚开始时候我并没有认识到这一点，导致系统性能不太好。关于派发器建议大家读一下官方的文档。

标准派发器

　　这是最常用、通用的派发器。默认是fork-join。还可以配置成thread-pool的形式。不过具体情况可以具体分析。但要认识到线程的让步都会执行一次上下文的切换，如果经常发生切换，对于系统来说是一个比较昂贵的开销。你看其他语言创建了自己的线程调度器就知道优化的必要了。

固定派发器

　　固定派发器不再为actor使用线程池，而是每个actor分配一个固定线程，这样就不会有上下文切换的问题了。这种只对actor比较少的系统有用。

平衡派发器

　　平衡派发器通过使用共享邮箱来执行这样的重分配操作。不常用，就不分析了。

calling-thread派发器

　　主要用于测试。它不会分配线程池，所有操作都在发送消息的同一个线程上执行。

何时使用单独的派发器

　　根据我的经验来看，前期不要考虑这个问题，先实现业务逻辑，等有性能问题的时候再考虑。但有一个却可以提前考虑，那就是与数据库相关的阻塞操作可以使用单独的派发器，这样不会影响原有actor的线程吞吐量。

提高并行性

　　提高并行性是对业务的优化，就是提前考虑算法能否用“分而治之”的思想进行拆分，然后并行处理。但并不是所有的算法都能拆分，这点就靠大家自行分析了。

结论

　　Akka是一个好的框架，它基本考虑了分布式 环境下遇到的所有方面的问题。Akka的很多高级特性都是基于最基础的Actor模型，可以使用它构建高并发、稳定的分布式系统，但有一点大家需要注意。Akka是一个分布式框架，系统的很多功能都需要自行设计，而且系统的稳定性和质量都取决于有没有合理的使用Actor模型。该书虽然描述了最重要的actor模式，但并不详细，很多章节都需要我们根据自己的实际场景来设计的。目前并没有关于Akka最佳实践的材料，即使有也都在各公司内部。所以我准备在未来的时间内写一点关于Akka最佳实践的博客，希望大家捧场。