ElasticMQ 0.7.0: Long Polling, Non-Blocking Implementation Using Akka and Spray

ElasticMQ 0.7.0: Long Polling, Non-Blocking Implementation Using Akka and Spray

原文作者:Adam Warski
原文地址:https://dzone.com/articles/elasticmq-070-long-polling-non
译者微博:@从流域到海域
译者博客:blog.csdn.net/solo95
本文同样刊载于腾讯云+:https://cloud.tencent.com/developer/article/1018703

ElasticMQ 0.7.0:长轮询,使用Akka和Spray的非阻塞实现

ElasticMQ 0.7.0,一个附带基于actor的Scala以及兼容Amazon SQS插件的消息队列系统刚刚发布。

这是一次重大的重写(即版本升级),升级之后将在核心使用Akka actors 并在REST层使用Spray。到目前为止,只有核心和SQS模块被重写, 日志( journaling),SQL后端和副本(replication)模块的重写尚未完成。

主要的客户端改进是:

  • 支持长轮询,这是SQS前一段时间的补充
  • 更简单的独立服务器 - 只需下载一个jar包

使用长时间的轮询的过程中,当收到消息时,可以指定一个额外的的MessageWaitTime属性。如果队列中没有消息,,ElasticMQ将等待MessageWaitTime几秒钟直到消息到达,而不是用空响应完成请求。这有助于减少带宽的使用(不需要非常频繁地进行请求),进而提高系统整体性能(发送后立即收到消息)并降低SQS成本。

独立的服务器现在是一个单一的jar包。要运行本地内存SQS实现(例如,测试使用SQS的应用程序),只需要下载jar文件并运行:

java -jar elasticmq-server-0.7.0.jar

这将在http://localhost:9324启动服务器。当然,接口和端口都是可配置的,详情请参阅自述文件。像以前一样,您也可以使用任何基于JVM的语言来运行嵌入式服务器。

实现说明

出于好奇,下面是对ElasticMQ如何实现的简短描述,包括核心系统,REST层,Akka数据流使用和长轮询实现。所有的代码都可以在GitHub上找到。

如前所述,ElasticMQ现在使用Akka和Spray来实现,并且不包含任何阻塞调用。一切都是异步的。

核心

核心系统是基于角色的。有一个主角色(main actor)(QueueManagerActor),它知道系统中当前创建了哪些队列,并提供了创建和删除队列的可能性。

为了与actor沟通,使用了类型化问答模式。例如,要查找一个队列(一个队列也是一个actor),就会定义一个消息:

case class LookupQueue(queueName:String)extends Replyable [Option [ActorRef]]

用法如下所示:

import org.elasticmq.actor.reply._
val lookupFuture: Future[Option[ActorRef]] = queueManagerActor ? LookupQueue("q2")

如前所述,每个队列都是一个actor,并且已经封装了队列状态。我们可以使用简单的可变数据结构,而不需要任何线程同步,因为角色模型(actor model)为我们处理了这个问题。有一些消息可以发送给queue-actor,例如:

case class SendMessage(message: NewMessageData)   extends Replyable[MessageData]
case class ReceiveMessages(visibilityTimeout: VisibilityTimeout, count: Int, 
           waitForMessages: Option[Duration])     extends Replyable[List[MessageData]]
case class GetQueueStatistics(deliveryTime: Long) extends Replyable[QueueStatistics]
Rest层

SQS查询/ REST层是使用Spray来实现的,这是一个基于Akka的轻量级REST/HTTP工具包。

除了基于角色的非阻塞IO实现外,Spray还提供了强大的路由库spray-routing。它包含一些内置的指令,用于在请求方法(get / post等)上进行匹配,提取表单参数中的查询参数或匹配请求路径。但它也可以让你使用简单的指令组合来定义你自己的指令。一个典型的ElasticMQ route示例如下所示:

val listQueuesDirective = 
  action("ListQueues") {
    rootPath {
      anyParam("QueueNamePrefix"?) { prefixOption =>
        // logic
      }
    }
  }

action"Action"URL的body参数中匹配指定的action名称并接受/拒绝请求的地方,rootPath会匹配出空路径(…)。Spray有一个很好的教程,如果你有兴趣,我建议你看看这篇教程。

如何使用路由中的队列角色(queue actors)来完成HTTP请求?

关于Spray的RequestContext好处是,它所做的只是将一个实例传递给你的路由,不需要任何回复。完全放弃请求或使用某个value完成该请求仅仅取决于它的路由。该请求也可以在另一个线程中完成 - 或者,例如,在未来某个线程运行完成时。这正是ElasticMQ所做的。在这里使用mapflatMapfor-comprehensions(这是一个针对map/ flatMap更好的语法)是非常方便的,例如(省略了一些内容):

// Looking up the queue and deleting it are going to be called in sequence,
// but asynchronously, as ? returns a Future
for {
   queueActor <- queueManagerActor ? LookupQueue(queueName)
   _ <- queueActor ? DeleteMessage(DeliveryReceipt(receipt))
} {
   requestContext.complete(200, "message deleted")
}

有时,当流程更复杂时,ElasticMQ会使用Akka Dataflow,这需要启用continuations插件。还有一个类似的项目,使用宏,Scala Async,但这个仍处于早期开发阶段。

使用Akka Dataflow,您可以编写使用Future们的代码,就好像编写正常的序列化代码一样。CPS插件会将其转换为在需要时使用回调。这是一个来自CreateQueueDirectives的例子:

(序列化代码sequential code,也有翻译成顺序代码的,即按顺序执行的代码,过程中不存在多线程异步操作,译者注)

flow {
  val queueActorOption = (queueManagerActor ? LookupQueue(newQueueData.name)).apply()
  queueActorOption match {
    case None => {
      val createResult = (queueManagerActor ? CreateQueue(newQueueData)).apply()
      createResult match {
        case Left(e) => throw new SQSException("Queue already created: " + e.message)
        case Right(_) => newQueueData
      }
    }
    case Some(queueActor) => {
      (queueActor ? GetQueueData()).apply()
    }
  }
}

这里的重要部分是flow代码块,它界定了转换的范围,以及调用Future提取future内容的apply()。这看起来像完全正常的序列化代码,但是在执行时,因为第一次Future是第一次使用将会异步运行。

长轮询

由于所有的代码都是异步和非阻塞的,实现长轮询非常容易。请注意,从一个队列接收消息时,我们得到一个Future[List[MessageData]]。为了发出响应已完成这个future,HTTP请求也将会以适当的响应来完成。然而,这个future几乎可以立即完成(例如正常情况下),比如在10秒之后 - 代码所需的支持没有变化。唯一要做的就是延迟完成future,直到指定的时间过去或新的消息到达。

实现在QueueActorWaitForMessagesOps中。当接收到消息的请求到达时,队列中没有任何内容产生,而是立即回复(即向发送者actor发送空列表),我们将储存原始请求的引用和发送方actor在map中。使用Akka调度程序,我们还计划在指定的时间超过之后发回空列表并删除条目。

当新消息到达时,我们只需从map上等待一个请求,然后尝试去完成它。同样,所有同步和并发问题都由Akka和actor模型来处理。

请测试新版本,如果您有任何反馈,请让我们知晓!

Adam

posted @ 2018-01-11 14:07  从流域到海域  阅读(41)  评论(0编辑  收藏  举报