本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
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则以消费者为导向。主题中的消息来自生产者，而队列中的消息来自主题或生产者。队列分为分区，而主题曲则未定义。在大多数情况下，队列是主题的一小部分。创建或销毁队列很容易，生产者无关紧要。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » openmessaging架构原理解析