openmessaging架构原理解析

openmessaging 构建分布式消息传递的开放标准。口号响亮，厂商众多，openmessaging 一出生就有众多大佬（阿里云，滴滴，雅虎，亚马逊，谷歌等）的光环。而阿里捐献给Apache 的 RocketMQ 率先为Open Messaging提供了部分实现。本文根据 openmessaging 开源的一些资料来解析 openmessaging 技术原理。

上图是引用 openmessaging 官网的一张架构图。

openmessaging 最近发布了第一个alpha版本，Apache RocketMQ已经为OpenMessaging-0.1.0-alpha 提供了部分实现。

NAMESPACE 命名空间

命名空间喜欢cgroup命名空间，创建一个具有安全保证的隔离空间。每个命名空间都有自己的一组生产者，消费者，主题，队列等。openmessaging使用MessagingAccessPoint访问/读取/写入指定命名空间的资源。

PRODUCER 生产者

openmessaging定义了两种Producer：Producer和SequenceProducer。

• 生产者，提供各种发送方式来发送消息到指定的目的地，主题或队列。支持三种方式：同步，异步和单向。
• SequenceProducer，专注于速度，实现可以采用批处理方式，发送多个消息，然后一次提交。

CONSUMER 消费者

openmessaging定义了两种Consumer：PullConsumer，PushConsumer和StreamingConsumer。每个消费者只支持从Queue消费消息。

• PullConsumer从指定的队列中提取消息，支持随时通过确认提交消费结果。一个PullConsumer只能从一个固定队列中提取消息。
• PushConsumer从多个队列接收消息，这些消息从MOM服务器推送。PushConsumer可以使用单独的MessageListener附加到多个队列，并随时通过ReceivedMessageContext提交消费结果。
• StreamingConsumer是一种全新的消费类型，面向流的消费者，可轻松将消息系统与Streaming / BigData相关的平台集成在一起。StreamingConsumer支持消耗来自指定队列的消息，如迭代器。

TOPIC QUEUE AND ROUTING 主题队列和路由

这三个概念是紧密相连的，虽然主题和队列有不同的责任，但他们却很混乱。

• 主题，原始信息的载体，负责持有信息。主题中的消息分发和顺序未定义。

ROUTING 路由

主题中的信息是原始的，等待处理，始终无法唤起消费者的利益。总而言之，主题中的消息是以生产者为导向，而不是以消费者为导向。

因此，路由负责处理主题中的原始消息，并路由到队列。每个路由都有一个运营商管道，由一系列运营商组成。消息将从主题和队列流经操作员管道。

操作员用于处理路由中流动的消息。操作员，表达式运算符，重复数据删除器操作符，joiner操作符，过滤器操作符，rpc操作符等都有很多种类。

更重要的是？路由可以跨越网络，消息可以从网络分区路由到另一个分区。

QUEUE 队列

消息已经路由到队列，现在可以被消费者使用。值得注意的是，队列应分为分区，消息将通过MessageHeader＃SHARDING_KEY路由到指定的分区。

队列也直接从制片人接收消息，有时候，我们希望从生产者到消费者的最短路径，以实现性能。

TOPIC VS QUEUE 主题与队列

主题和队列都是邮件的载体。主题是面向生产者，而Queue则以消费者为导向。主题中的消息来自生产者，而队列中的消息来自主题或生产者。队列分为分区，而主题曲则未定义。在大多数情况下，队列是主题的一小部分。创建或销毁队列很容易，生产者无关紧要。

： » openmessaging架构原理解析