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所做的。在这里使用map，flatMap和for-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