Akka模型

 Akka是一个构建在JVM上，基于Actor模型的的并发框架，为构建伸缩性强，有弹性的响应式并发应用提高更好的平台。Akka的核心就是Actor，Actor模型通俗举例：假定现实中的两个人，他们只知道对方的地址，他们想要交流，给对方传递信息，但是又没有手机，电话，网络之类的其他途径，所以他们之间只能用信件传递消息，很像现实中的的邮政系统，你要寄一封信，只需根据地址把信投寄到相应的信箱中，具体它是如何帮你处理送达的，你就不需要了解了，你也有可能收到收信人的回复，这相当于消息反馈。上述例子中的信件就相当于Actor中的消息，Actor与Actor之间只能通过消息通信。当然Actor模型比这要复杂的多，这里主要是简洁的阐述一下Actor模型的概念。

Akka是一个开发库和运行环境，可以用于 构建高并发、分布式、可容错、事件驱动的基于JVM的应用。 使构建高并发的分布式应用更加容易。Akka是把Actor Model模型进行了封装。可以理解为,异步,非阻塞的一个消息传递

1、对并发模型进行了更高的抽象<br>2、异步、非阻塞、高性能的事件驱动编程模型<br>3、轻量级事件处理（1GB内存可容纳百万级别个Actor）<br>

处理并发问题就是如何保证共享数据的一致性和正确性，为什么会有保持共享数据正确性这个问题呢？无非是我们的程序是多线程的，多个线程对同一个数据进行修改，若不加同步条件，势必会造成数据污染。那么我们是不是可以转换一下思维，用单线程去处理相应的请求，但是又有人会问了，若是用单线程处理，那系统的性能又如何保证。Actor模型的出现解决了这个问题。如右图：

Actor与Actor之前只能用消息进行通信，当某一个Actor给另外一个Actor发消息，消息是有顺序的，你只需要将消息投寄的相应的邮箱，至于对方Actor怎么处理你的消息你并不知道，当然你也可等待它的回复。

1）每个actor都对应一个mailbox；2）actor是串行处理消息的；3）actor中的消息是不可变的

1）简化并发编程，在面对并发编程的核心问题是解决共享数据一致性的问题，在传统实现过程中使用锁、同步代码块的方式来实现，代码逻辑复杂，不好掌握，同时因为锁的存在，程序性能下降的厉害。使用actor模型很好的解决此问题，actor基于消息的通讯模型，决定了不会出现共享数据的问题，另外actor中的消息是串行处理的，不会造成数据污染，大大降低了代码的复杂度；<br>2）提升程序性能：Actor是非常轻量级的，在程序中可以创建许多个Actor，而且Actor是异步的，那么如何利用它的这个特性呢，我们要做的就是把相应的并发事件尽可能的分割成一个个小的事件，让每个Actor去处理相应的小事件,充分去利用它异步的特点，来提升程序的性能。

1）ActorSystem

2）ActorRef

ActorSystem&nbsp;是管理&nbsp;Actor生命周期的组件，&nbsp;Actor是负责进行通信的组件<br>每个&nbsp;Actor&nbsp;都有一个&nbsp;MailBox，别的&nbsp;Actor&nbsp;发送给它的消息都首先储存在&nbsp;MailBox&nbsp;中，通过这种方式可以实现异步通信。<br>每个&nbsp;Actor&nbsp;是单线程的处理方式，不断的从&nbsp;MailBox&nbsp;拉取消息执行处理，所以对于&nbsp;Actor&nbsp;的消息处理，不适合调用会阻塞的处理方法。<br>Actor&nbsp;可以改变他自身的状态，可以接收消息，也可以发送消息，还可以生成新的&nbsp;Actor<br>每一个ActorSystem&nbsp;和&nbsp;Actor都在启动的时候会给定一个&nbsp;name，如果要从ActorSystem中，获取一个&nbsp;Actor，则通过以下的方式来进行&nbsp;Actor的获取：akka.tcp://asname@bigdata02:9527/user/actorname<br>如果一个&nbsp;Actor&nbsp;要和另外一个&nbsp;Actor进行通信，则必须先获取对方&nbsp;Actor&nbsp;的&nbsp;ActorRef&nbsp;对象，然后通过该对象发送消息即可。<br>通过&nbsp;tell&nbsp;发送异步消息，不接收响应，通过&nbsp;ask&nbsp;发送异步消息，得到&nbsp;Future&nbsp;返回，通过异步回到返回处理结果。<br><br>

Thingsboard&nbsp;actor对象<br>1、App&nbsp;Actor&nbsp;-&nbsp;负责管理租户演员。此actor的示例始终存在于内存中。租户 -&nbsp;负责管理租户设备和规则链演员。此actor的实例始终存在于内存中。<br>2、Device&nbsp;Actor&nbsp;-&nbsp;维护设备的状态:活动回话，订阅，挂起的RPC命令等。出于性能原因，将当前设备属性缓存在内存中。处理来自设备的第一条消息时，将创建一个actor。当设备在一段时间内没有消息时，actor停止。<br>3、规则链Actor&nbsp;-&nbsp;处理传入的消息，将它们保存到队列中并将它们分派给规则节点actor。此actor的实例始终存在于内存中。<br>4、规则节点Actor&nbsp;-&nbsp;处理传入消息，并将结果报告给规则链actor。此actor的实例始终存在于内存中。<br>5、设备会话管理器Actor&nbsp;-&nbsp;负责管理设备会话actor。在具有相应会话ID的第一条消息上创建会话actor。关闭相应会话时关闭会话actor。<br>6、Session&nbsp;Actor&nbsp;-&nbsp;表示设备和ThingsBoard服务器之间的通信会话。会话可以是同步的(HTTP,COAP)和异步的(MQTT,带有Observe选项的CoAP)。<br>7、RPC会话管理器Actor&nbsp;-&nbsp;负责管理集群RPC会话actor。新服务器启动时创建会话actor。服务器关闭时关闭会话actor。<br>8、RPC&nbsp;Session&nbsp;Actor&nbsp;-&nbsp;表示集群模式下2个ThingsBoard服务器之间的通信会话。使用基于gPRC的HTTP/2进行通信。