Akka模型
2023-05-18 13:47:15 0 举报AI智能生成
Akka是一个开发库和运行环境，可以用于 构建高并发、分布式、可容错、事件驱动的基于JVM的应用。 使构建高并发的分布式应用更加容易。Akka是把Actor Model模型进行了封装。可以理解为,异步,非阻塞的一个消息传递
作者其他创作
大纲/内容
1.Akka是什么？
Akka是一个构建在JVM上，基于Actor模型的的并发框架，为构建伸缩性强，有弹性的响应式并发应用提高更好的平台。Akka的核心就是Actor，Actor模型通俗举例：假定现实中的两个人，他们只知道对方的地址，他们想要交流，给对方传递信息，但是又没有手机，电话，网络之类的其他途径，所以他们之间只能用信件传递消息，很像现实中的的邮政系统，你要寄一封信，只需根据地址把信投寄到相应的信箱中，具体它是如何帮你处理送达的，你就不需要了解了，你也有可能收到收信人的回复，这相当于消息反馈。上述例子中的信件就相当于Actor中的消息，Actor与Actor之间只能通过消息通信。当然Actor模型比这要复杂的多，这里主要是简洁的阐述一下Actor模型的概念。
Akka是一个开发库和运行环境，可以用于 构建高并发、分布式、可容错、事件驱动的基于JVM的应用。 使构建高并发的分布式应用更加容易。Akka是把Actor Model模型进行了封装。可以理解为,异步,非阻塞的一个消息传递
2.Akka中Actors模型
1、对并发模型进行了更高的抽象
2、异步、非阻塞、高性能的事件驱动编程模型
3、轻量级事件处理（1GB内存可容纳百万级别个Actor）
2、异步、非阻塞、高性能的事件驱动编程模型
3、轻量级事件处理（1GB内存可容纳百万级别个Actor）
3.为什么Actor模型是一种处理并发问题的解决方案？
处理并发问题就是如何保证共享数据的一致性和正确性，为什么会有保持共享数据正确性这个问题呢？无非是我们的程序是多线程的，多个线程对同一个数据进行修改，若不加同步条件，势必会造成数据污染。那么我们是不是可以转换一下思维，用单线程去处理相应的请求，但是又有人会问了，若是用单线程处理，那系统的性能又如何保证。Actor模型的出现解决了这个问题。如右图：
Actor与Actor之前只能用消息进行通信，当某一个Actor给另外一个Actor发消息，消息是有顺序的，你只需要将消息投寄的相应的邮箱，至于对方Actor怎么处理你的消息你并不知道，当然你也可等待它的回复。
4.Akka特点
1）每个actor都对应一个mailbox；2）actor是串行处理消息的；3）actor中的消息是不可变的
5.Akka优势
1）简化并发编程，在面对并发编程的核心问题是解决共享数据一致性的问题，在传统实现过程中使用锁、同步代码块的方式来实现，代码逻辑复杂，不好掌握，同时因为锁的存在，程序性能下降的厉害。使用actor模型很好的解决此问题，actor基于消息的通讯模型，决定了不会出现共享数据的问题，另外actor中的消息是串行处理的，不会造成数据污染，大大降低了代码的复杂度；
2）提升程序性能：Actor是非常轻量级的，在程序中可以创建许多个Actor，而且Actor是异步的，那么如何利用它的这个特性呢，我们要做的就是把相应的并发事件尽可能的分割成一个个小的事件，让每个Actor去处理相应的小事件,充分去利用它异步的特点，来提升程序的性能。
2）提升程序性能：Actor是非常轻量级的，在程序中可以创建许多个Actor，而且Actor是异步的，那么如何利用它的这个特性呢，我们要做的就是把相应的并发事件尽可能的分割成一个个小的事件，让每个Actor去处理相应的小事件,充分去利用它异步的特点，来提升程序的性能。
6.Akka组件
1）ActorSystem
是Actor容器。Actor作为一种封装状态和行为的对象，总是需要一个系统去统一的组织和管理它们，因此需要ActorSystem，相当于actor容器。职责：管理调度任务、配置相关参数、日志能力主题
能力
管理调度任务：
a、Akka中Actor的组织是一种树形结构
b、每个Actor都有父级，有可能有子级当然也可能没有
c、父级Actor给其子级Actor分配资源，任务，并管理其的生命状态（监管和监控）
Actor系统往往有成千上万个Actor，使用树形机构来组织管理Actor是非常适合的。而且Akka天生就是分布式，你可以向一个远程的Actor发送消息，但你需要知道这个Actor的具体位置在哪，这时候你就会发现，树形结构对于确定一个Actor的路径来说是非常有利（比如Linux的文件存储）
a、Akka中Actor的组织是一种树形结构
b、每个Actor都有父级，有可能有子级当然也可能没有
c、父级Actor给其子级Actor分配资源，任务，并管理其的生命状态（监管和监控）
Actor系统往往有成千上万个Actor，使用树形机构来组织管理Actor是非常适合的。而且Akka天生就是分布式，你可以向一个远程的Actor发送消息，但你需要知道这个Actor的具体位置在哪，这时候你就会发现，树形结构对于确定一个Actor的路径来说是非常有利（比如Linux的文件存储）
配置相关参数：
一个完整的ActorSystem有很多需要配置的信息，比如，日志，调度器等信息。ActorSystem会根据指定的actor-system.conf配置文件内容去生成相应的Actor系统环境。
一个完整的ActorSystem有很多需要配置的信息，比如，日志，调度器等信息。ActorSystem会根据指定的actor-system.conf配置文件内容去生成相应的Actor系统环境。
日志能力：
在akka中，日志不应该只是记录程序运行状态和排除错误，Akka拥有高容错机制，这无疑需要完善的日志记录才能使Actor出错后能及时做出相应的恢复策略，比如Akka中的持久化。
在akka中，日志不应该只是记录程序运行状态和排除错误，Akka拥有高容错机制，这无疑需要完善的日志记录才能使Actor出错后能及时做出相应的恢复策略，比如Akka中的持久化。
2）ActorRef
ActorRef是actor的子类，每个actor对应唯一的一个actorRef代理，所有actor执行的动作，都需要通过actor代理来完成，包括发送消息、接收消息，向Actor发送消息其实是将消息发送到Actor对应的引用上，再由它将消息投寄到具体Actor的信箱中，所以ActorRef在整个Actor系统是一个非常重要的角色。
7.工作模式
ActorSystem 是管理 Actor生命周期的组件， Actor是负责进行通信的组件
每个 Actor 都有一个 MailBox，别的 Actor 发送给它的消息都首先储存在 MailBox 中，通过这种方式可以实现异步通信。
每个 Actor 是单线程的处理方式，不断的从 MailBox 拉取消息执行处理，所以对于 Actor 的消息处理，不适合调用会阻塞的处理方法。
Actor 可以改变他自身的状态，可以接收消息，也可以发送消息，还可以生成新的 Actor
每一个ActorSystem 和 Actor都在启动的时候会给定一个 name，如果要从ActorSystem中，获取一个 Actor，则通过以下的方式来进行 Actor的获取：akka.tcp://asname@bigdata02:9527/user/actorname
如果一个 Actor 要和另外一个 Actor进行通信，则必须先获取对方 Actor 的 ActorRef 对象，然后通过该对象发送消息即可。
通过 tell 发送异步消息，不接收响应，通过 ask 发送异步消息，得到 Future 返回，通过异步回到返回处理结果。
每个 Actor 都有一个 MailBox，别的 Actor 发送给它的消息都首先储存在 MailBox 中，通过这种方式可以实现异步通信。
每个 Actor 是单线程的处理方式，不断的从 MailBox 拉取消息执行处理，所以对于 Actor 的消息处理，不适合调用会阻塞的处理方法。
Actor 可以改变他自身的状态，可以接收消息，也可以发送消息，还可以生成新的 Actor
每一个ActorSystem 和 Actor都在启动的时候会给定一个 name，如果要从ActorSystem中，获取一个 Actor，则通过以下的方式来进行 Actor的获取：akka.tcp://asname@bigdata02:9527/user/actorname
如果一个 Actor 要和另外一个 Actor进行通信，则必须先获取对方 Actor 的 ActorRef 对象，然后通过该对象发送消息即可。
通过 tell 发送异步消息，不接收响应，通过 ask 发送异步消息，得到 Future 返回，通过异步回到返回处理结果。
开源产品案例
Thingsboard actor对象
1、App Actor - 负责管理租户演员。此actor的示例始终存在于内存中。租户 - 负责管理租户设备和规则链演员。此actor的实例始终存在于内存中。
2、Device Actor - 维护设备的状态:活动回话，订阅，挂起的RPC命令等。出于性能原因，将当前设备属性缓存在内存中。处理来自设备的第一条消息时，将创建一个actor。当设备在一段时间内没有消息时，actor停止。
3、规则链Actor - 处理传入的消息，将它们保存到队列中并将它们分派给规则节点actor。此actor的实例始终存在于内存中。
4、规则节点Actor - 处理传入消息，并将结果报告给规则链actor。此actor的实例始终存在于内存中。
5、设备会话管理器Actor - 负责管理设备会话actor。在具有相应会话ID的第一条消息上创建会话actor。关闭相应会话时关闭会话actor。
6、Session Actor - 表示设备和ThingsBoard服务器之间的通信会话。会话可以是同步的(HTTP,COAP)和异步的(MQTT,带有Observe选项的CoAP)。
7、RPC会话管理器Actor - 负责管理集群RPC会话actor。新服务器启动时创建会话actor。服务器关闭时关闭会话actor。
8、RPC Session Actor - 表示集群模式下2个ThingsBoard服务器之间的通信会话。使用基于gPRC的HTTP/2进行通信。
1、App Actor - 负责管理租户演员。此actor的示例始终存在于内存中。租户 - 负责管理租户设备和规则链演员。此actor的实例始终存在于内存中。
2、Device Actor - 维护设备的状态:活动回话，订阅，挂起的RPC命令等。出于性能原因，将当前设备属性缓存在内存中。处理来自设备的第一条消息时，将创建一个actor。当设备在一段时间内没有消息时，actor停止。
3、规则链Actor - 处理传入的消息，将它们保存到队列中并将它们分派给规则节点actor。此actor的实例始终存在于内存中。
4、规则节点Actor - 处理传入消息，并将结果报告给规则链actor。此actor的实例始终存在于内存中。
5、设备会话管理器Actor - 负责管理设备会话actor。在具有相应会话ID的第一条消息上创建会话actor。关闭相应会话时关闭会话actor。
6、Session Actor - 表示设备和ThingsBoard服务器之间的通信会话。会话可以是同步的(HTTP,COAP)和异步的(MQTT,带有Observe选项的CoAP)。
7、RPC会话管理器Actor - 负责管理集群RPC会话actor。新服务器启动时创建会话actor。服务器关闭时关闭会话actor。
8、RPC Session Actor - 表示集群模式下2个ThingsBoard服务器之间的通信会话。使用基于gPRC的HTTP/2进行通信。
0 条评论
下一页
