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

简介: 性能  这也是一个比较大的问题,因为性能不一定是Akka本身的问题,还可能是你代码写的有问题。  优化的第一步就是找出性能的瓶颈,隔离出应用程序里面比较耗时的部分,然后尝试对其优化,减少需要耗费的时间成本。

性能

  这也是一个比较大的问题,因为性能不一定是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最佳实践的博客,希望大家捧场。

目录
相关文章
|
1月前
|
安全 大数据 Go
Go语言在分布式系统中的应用
【2月更文挑战第20天】Go语言,以其独特的语言特性和出色的性能,逐渐成为分布式系统开发领域的热门选择。本文将深入探讨Go语言在分布式系统中的应用,分析其优势及实际应用案例,旨在为开发人员提供有价值的参考与启示。
|
4月前
|
缓存 NoSQL 算法
认真学习分布式应用中的分布式锁
认真学习分布式应用中的分布式锁
43 0
|
4月前
|
消息中间件 Java 应用服务中间件
聊聊分布式高并发应用中的高可用性
聊聊分布式高并发应用中的高可用性
28 0
|
4月前
|
负载均衡 算法 NoSQL
聊聊分布式应用中负载均衡技术和Session一致性
聊聊分布式应用中负载均衡技术和Session一致性
40 0
|
4月前
|
缓存 NoSQL Java
聊聊分布式应用中的缓存方案(一)
聊聊分布式应用中的缓存方案(一)
37 0
|
3月前
|
存储 安全 JavaScript
【分布式技术专题】「授权认证体系」深度解析OAuth2.0协议的原理和流程框架实现指南(授权流程和模式)
在传统的客户端-服务器身份验证模式中,客户端请求服务器上访问受限的资源(受保护的资源)时,需要使用资源所有者的凭据在服务器上进行身份验证。资源所有者为了给第三方应用提供受限资源的访问权限,需要与第三方共享它的凭据。这就导致一些问题和局限:
373 2
【分布式技术专题】「授权认证体系」深度解析OAuth2.0协议的原理和流程框架实现指南(授权流程和模式)
|
2月前
|
Java 数据库连接 API
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
57 0
|
开发框架 Java 数据库连接
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)(下)
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
37 0
|
数据库 微服务
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)(上)
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
41 0
|
15天前
|
存储 分布式数据库
GaussDB分布式与单机模式的比较
【4月更文挑战第7天】GaussDB分布式与单机模式的比较
1612 5

热门文章

最新文章