如果我已有java使用spring和servlet容器的Web应用程序。将Akka集成到其中的正确方法是什么?
java
spring
servlet
就像我将要拥有的Actor1并且Actor2彼此交流一样。开始使用这些参与者的切入点是什么?(例如:1.放到那里2.更改配置3.获取对actor的引用)
Actor1
Actor2
我找到了http://doc.akka.io/docs/akka/2.2-M3/general/configuration.html,但是他没有给我胶水。只想获取集成的真实示例。
有一些简单的集成示例吗?
编辑: 应用程序进行一些搜索,从外部获取一些数据,将信息存储到文件中。
应用程序很大。一些组件/对象可以离开自己的生命,这是出于直接客户的请求,它可以并行执行某些事情。就像某些具有可变状态的单例对象一样。
问题是我不知道可以在哪里申请演员,我正在调查中。但是我已经在这里和那里有很多同步块。
而且,我认为,已经有可能采取行动者的迹象。 (因为我不确定,也许我忘了 同步 一些,当然还没有集成测试)
关于配置,我只是不确定是否应该配置一些application.conf来让Actrors / Akka居住在这里( 因为文档本身对此进行了描述 )。
我所看到的:
@Component("someManager") public class SomeManager { List<Some> something; // mutable state, that why I use locks here. // methods: add(), delete(), update() }
我可以做到 SomeManagerActor
SomeManagerActor
SomeManager用于controller。因此,最好还具有控制器Actor?我想接收对(onReceive()方法)的反馈。
SomeManager
controller
onReceive
这有点可争议…这就是我需要一些 例子 的另一个原因。
我相信我可以通过摆脱所有工作synchronized/whait/notify,将职责移交给演员,使用消息作为与他们之间/之间进行交流的方式来改善应用程序。
synchronized/whait/notify
或像这样,可能是 写入属性文件的参与者 :
编辑:
例如,现在,我发现了:为了使Actor1向Actor2发送消息,我使用了一个技巧:
// somewhere in existing code public void initActors() { ActorSystem system = ActorSystem.create(example"); // initializing final ActorRef actor1 = system.actorOf(Props.create(Actor1.class), "actor1"); }
Actor1有一种方法preStart(),一旦我获得对它的引用,它便会立即启动(如上所述)。并向Actor2发送消息:
preStart()
@Override public void preStart() {
但是我不确定为什么初始化两个演员来完成他们的工作是好事。
回答我的问题。只是分享我的想法,我想到了什么。
如果我们已经有基于Servlets / Spring MVC的现有Web应用程序,那么似乎没有充分的理由切换到Actors/ AKKA(或者为了现有的系统引入actor引入现有系统),如果在我们的应用程序中:
Actors
AKKA
在这个简单的系统中拥有Actor有什么问题:
具有通过组件 而不是调用常规方法* (利用OPP的优点,实现接口,具有多个实现-但Actor通常)的 大量消息 ( 将消息 封装到actor或从actor封装的类)。 *final class
final class
将消息作为string,也不是一个好的解决方案-因为很难调试。
string
在这样的系统中(例如MVC站点),通常没有太多要同步的东西(已经很同步了stateless)。mutable shared data每个控制器/组件中都有0..2 。同步起来并不难(只需养成使所有常见和共享的东西都同步到类顶部的习惯(这样就可以识别/本地化状态)。有时,您只需要synchronized collection使用或使用Java Atomic包装器类型即可。
stateless
mutable shared data
synchronized collection
Atomic
但是,何时将Actor用于现有应用程序。 用例可能是这样的:
MasterActor
SiteSearchActor
PI
scalability
performance
但总的来说,我同意这个文章关于concurrency和parallelism。如果我有机会,使从头开始申请,我会用阿卡 没有的Servlet容器 和 有关消息的关怀不知何故 (指挥类)和 OOP 时需要使用它(有没有这么多OOP在一般的网络应用程序。我应该说但是,没有人能阻止保持某些业务逻辑OOP,参与者只是沟通的粘合剂)。例如,这比使用JMS更好/更简单。
concurrency
parallelism
OOP
但是就像我说的:
演员/ Akka擅长:
我现在唯一的问题是performance comparison。假设我们知道:
performance comparison
从性能的角度来看,在我们的MVC控制器/服务中在一个JVM中具有10000个线程并具有同步和锁定以共享可变数据可能是非常糟糕的。由于存在许多可能的锁,所以线程是并发的(彼此竞争的资源的竞争者或竞争者)。
如果我们对具有N个(角色,N远远 小于 1000)的AKKA / Servlet,具有相同的方案,则我们很可能会具有更好的性能(因为除了队列本身之外,没有人阻塞任何人,因此无需从一个线程切换到其他线程)到另一个)。
但是,即使对于基于Servlet(线程模型)应用程序的系统而言,它具有10000个客户端,但如果有100个客户端,它的性能可能会很好。而且,如果我们有一个连接池(肯定有),它的作用与Actor的队列(收件箱)相同,则安排客户端访问某些服务。它可以提高K倍的性能(其中K比没有池的情况要多得多- 让线程拼死地互相阻塞)。
问题是:
不将AKKA应用于现有的基于servlet的应用程序是否有充分的理由?
以此为理由:即使在服务器上具有旧系统, connection pool也可能将性能提高到一个不错的水平。而且此级别很可能足以将其不应用AKKA到现有的Servlet应用程序,例如尝试更改servlet模型(与AKKA之上的Controllers相比,这是很糟糕的)。
connection pool
这样思考是否有意义?
考虑到连接拉是一种INBOX(类似于AKKA),用于调度命令(连接)。
即使 Servlets模型不好 (处理来自连接池的连接创建的rest(active)线程中的锁)。
使用连接池可能就足够了,在将Akka与基于servlet的东西进行比较时会忘记它。我们仍然可以调整应用程序,更改连接池中的MAX- CONNECTION。通常,我们会尽力使应用程序变为无状态,因此,在大多数情况下,我们不会同步任何内容。
但是,当然,对于 整个* 应用程序只有 一个 连接池是很糟糕的。如果与Actor进行比较,则每个actor都有自己的连接池(邮箱),并且每个actor可能负责接受HTTP请求。该模型肯定更好。 *
PS在大多数情况下, Future足够好。如果您希望“安全”将状态存储在状态中(最好与“将来”有所不同),则参与者是很好的。
更新: 有些人认为使用Actors根本不是一个好主意。好的是-纯函数方法或scalaz已提供的功能(Haskell我猜也是这样)-但尚不适用于远程调用。
Haskell