本文介绍akka的基本使用方法,由于属于基础功能,想不出一个很高大上的名称,此处就以基础模式命名.下文会介绍actor的使用方法,及其优劣点. class SimpleActor(name:String) extends Actor { private def doWork(message:SayHello):Unit = { println(s"$name 收到 ${message.from.path.name} 的消息 [$message] ,工作进行中... 当前线程号 ${Thread.…

While模式严格来说是while循环在Akka中的合理实现.while是开发过程中经常用到的语句之一,也是绝大部分编程语言都支持的语法.但while语句是一个循环,如果循环条件没有达到会一直执行while语句体的代码,且会阻塞while语句外的代码.如果在Akka中简单的使用while语句会极大的限制当前actor的功能. object GeneralWhile { def main(args: Array[String]): Unit = { var i=0 val maxLine = 10…

链式调用在很多框架和系统中经常存在,算不得上是我自己总结的设计模式,此处只是简单介绍在Akka中的两种实现方式.我在这边博客中简化了链式调用的场景,简化后也更符合Akka的设计哲学. trait Chained{ def receive:Receive = Actor.emptyBehavior } trait IntReceiveChained1 extends Chained{ override def receive:Receive = super.receive orElse { cas…

上一节我们介绍了Akka使用的基本模式,简单点来说就是,发消息给actor,处理结束后返回消息.但这种模式有个缺陷,就是一旦某个消息处理的比较慢,就会阻塞后面所有消息的处理.那么有没有方法规避这种阻塞呢,这就是本章要讲的Backend模式. 关于Backend模式,我们可以类比java中的线程池来理解,简单点来说就是把耗时或者阻塞的操作放到后台去执行.java中可能会将耗时的操作放到后台线程去执行,这样主线程不会阻塞.同样在Akka中我们也有类似的处理方式,只不过最简单的形式是用future来实…

所谓的Aggregate模式,其实就是聚合模式,跟masterWorker模式有点类似,但其出发点不同.masterWorker模式是指master向worker发送命令,worker完成某种业务逻辑.而聚合模式则刚好相反,由各个worker完成某种业务逻辑后,把结果汇总发给某个actor,这个actor不一定是masterActor. class AggregateMasterActor extends Actor{ override def receive: Receive = { case…

慎用ask应该是Akka设计的一个准则,很多时候我们应该禁用ask.之所以单独把ask拎出来作为一篇博文,主要是akka的初学者往往对ask的使用比较疑惑. "Using ask will send a message to the receiving Actor as with tell, and the receiving actor must reply with sender() ! reply in order to complete the returned Future with…

在之前的akka设计模式系列-消息模型中,我们介绍了akka的消息设计方案,但随着实践的深入,发现了一些问题,这里重新梳理一下设计方法,避免之前的错误.不当的观点给大家带来误解. 命令和事件 我们仍然把akka中的消息分为命令和事件两大类,但二者的具体含义和实现有一点变化.“命令,是指一个actor给另外一个actor发送指令做相关的业务逻辑:事件,则是actor对某个命令的响应结果,或者对其他事件的响应结果”.之前是这样定义的,但在具体的实践过程中发现了一些问题. 比如,命令如何归类?是根据命…

由于本人爱好Scala,顺便也就爱好Akka,但目前网上对Akka的介绍大多都是概念上或技术方向上的介绍,基本没有Akka设计模式或者Actor模型设计模式的资料.这对于Akka的普及非常不利,因为即使大家知道了Akka的基本功能和框架,也很难用它来正确的设计一个系统. 鉴于上述情况,我准备将使用Akka开发系统中总结的设计模式或者最佳实践分享出来,供大家参考. 考虑到读者对Akka的认知程度不同,这个博客系列大致会分几个部分:Actor模型.Akka基本概念.Akka基本组件介绍.Akka基本…

外观模式 通过在必需的逻辑和方法的集合前创建简单的外观接口,外观设计模式隐藏了调用对象的复杂性. 外观设计模式和建造者模式非常相似,建造者模式一般是简化对象的调用的复杂性,外观模式一般是简化含有很多逻辑步骤和方法调用的复杂性. 应用场景 设计一个User类,里面有getUser获取用户信息接口 在使用getUser这个接口的时候,需要设置用户的用户名和用户年龄 所 以在正常情况下,调用getUser接口,需要先实例化User类,然后设置用户信息,最后才调用getUser方法,这个过程是复杂的,如…

看了好几处关于builder模式的书和博客,总感觉不是很清楚,感觉不少书上的说的也不是很准确.最后还是看回圣经<设计模式>.看了好久终于感觉明白了一点了. 意图: builder模式提出的目的就是为了解决将一个复杂对象的构建和它的表示分离,使得同样的构建过程可以创建不的表示的问题. 我们来看一个例子: 假设我们要画一些人,例如游戏里面的各类人.一般情况下,人有头,手,腿.但是在游戏里面,人可能没有手,也可能不止两只手.即所谓的三头六臂.如下: 那么,在这种情况下应该怎么去生产这些人? 一开始可…