RPC调用编程
RPC 全称 Remote Procedure Call——远程过程调用,它是一种经过网络从远程计算机程序上请求服务,而不须要了解底层网络技术的方式。json
RPC 调用分类 | |
---|---|
通信协议层面 | 基于 HTTP 协议的 RPC;基于二进制协议的 RPC;基于 TCP 协议的 RPC |
是否跨平台 | 单语言 RPC,如 RMI, Remoting;跨平台 RPC,如 google protobuffer, restful json,http XML。 |
调用过程 | 同步通讯RPC和异步通讯RPC |
消息队列安全
消息队列”是在消息的传输过程当中保存消息的容器。服务器
异步处理restful
有些业务不想也不须要当即处理消息。消息队列提供了异步处理机制,容许用户把一个消息放入队列,在须要的时候进行处理;例如用户注册的时候发送验证邮件能够经过异步处理的方式在另一个线程内完成发送邮件操做.网络
解耦运维
在应用开发过程当中随着需求的增长各个模块进行过分耦合,各模块之间造成相互调用的关系,咱们能够利用消息队列造成中间层进行解耦.异步
流量削峰编程语言
在应用某一时段会发生大流量的请求,例如双十一会形成大量请求数据库,数据库很快就会造成瓶颈.咱们可将数据请求持久化在消息队列中,进行逐步处理.
日志收集
在项目开发和运维的心中日志是一个很重要的部分,若是尽量全面而又有效的收集日志进行分析是一个势在必得的任务,咱们可使用消息队列来构建统一日志处理平台.
事务最终一致
在行业中使用消息队列来保证一个事务的最终一致性也是常见分布式事务的解决方案.
一个最基本的消息队列应该具备消息发送者,消息处理中心,消息消费者三个功能.
在MQ中消息队列主要有两种通信模型分别是PTP点对点和Pub/Sub发布订阅
消息协议是指用于实现消息队列功能时双方通讯的一个约定, 例如 如何区分客户端是生产消息仍是消费消息? 客户端向消息处理中心发送
"发送: I am a Javaer"
字符串,那么咱们根据xxx约定字符中包含发送
的表明生产消息,那么咱们就能够知道该客户端要发送消息内容是" I am a Javaer"
,常见的消息协议有AMQP,MQTT,STOMP,XMPP等
AMQP即Advanced Message Queuing Protocol,高级消息队列协议,是面向消息中间件设计的应用层协议的一个开放标准。 它的主要特色是面向消息、队列、路由(包括点对点和发布/订阅)]、可靠性和安全。
AMQP容许来自不一样供应商的消息生产者和消费者实现真正的互操做扩展,就如同SMTP、HTTP、FTP等协议采用的方式同样。而此前对于消息中间件的标准化努力则集中在API层面上(好比JMS),且没有提供互操做性的途径。不一样于JMS的仅仅定义API,AMQP是一个线路级的协议——它描述了经过网络传输的字节流的数据格式。所以,听从这个协议的任何语言编写的工具都可以操做AMQP消息。
AMQP模型图
Exchange即交换器,用来接收Producer发布的消息,并经过设定的路由规则将消息路由给服务器中的Queue。
Binding即绑定器,能够理解为路由规则。它的做用就是把Exchange和Queue按照路由规则绑定起来。
Binding Key即绑定关键字,Exchange视自身类型来决定Binding的路由行为。
Routing Key即消息的路由关键字,Exchange根据这个关键字决定如何路由某条消息。
MQTT 最初由 IBM 于上世纪 90 年代晚期发明和开发。它最初的用途是将石油管道上的传感器与卫星相连接。顾名思义,它是一种支持在各方之间异步通讯的消息协议。异步消息协议在空间和时间上将消息发送者与接收者分离,所以能够在不可靠的网络环境中进行扩展。虽然叫作消息队列遥测传输,但它与消息队列毫无关系,而是使用了一个发布和订阅的模型。在 2014 年底,它正式成为了一种 OASIS 开放标准,并且在一些流行的编程语言中受到支持(经过使用多种开源实现)。
MQTT模型图
STOMP,Streaming Text Orientated Message Protocol,是流文本定向消息协议,是一种为MOM(Message Oriented Middleware,面向消息的中间件)设计的简单文本协议。它提供了一个可互操做的链接格式,容许STOMP客户端与任意STOMP消息代理(Broker)进行交互。因为其设计简单,很容易开发客户端,所以在多种语言和多种平台上获得普遍应用。其中最流行的STOMP消息代理是Apache ActiveMQ。
ATOMP模型图
注意: JMS不是消息队列协议的一种,更不是消息队列产品!
注意: JMS不是消息队列协议的一种,更不是消息队列产品!
注意: JMS不是消息队列协议的一种,更不是消息队列产品!
关于JMS你须要了解一点有趣的历史.
消息队列(Message Queue)起源于一位来自 MIT 的硬件设计教育工做者 Vivek Ranadivé 设想了一种通用软件总线,就像主板上的总线那样,供其余应用程序接入。Vivek在1983年成立了 Teknekron,高盛等公司做为第一批用户再金融交易中采用了 Teknekron的软件,同时还诞生了第一代消息队列软件:Teknekron 的 The Information Bus(TIB)。
Teknekron 的 TIB 容许应用开发者创建一系列规则去描述消息内容,只要消息按照这些规则发布出去,任何消费者应用均可以订阅感兴趣的内容,信息的生产者和消费者彻底解耦,而且能够再传输过程当中灵活混合。这个特性引发了电信特别是新闻机构的注意。1994年路透社收购了 Teknekron 。
因为消息队列再金融交易中应用的反响,BIM 在1990年也开始研发本身的消息队列软件(BIM MQ),而且逐步演化成 WebSphere MQ 并统治着商业消息队列平台市场。同时微软开发了Microsoft Message Queue(MSMQ)。然而这些商业MQ问题在供应商壁垒,各个厂商的 MQ 之间没法互通。为了解决这个问题,Java Message Service(JMS)在2001年诞生了,试图经过提供公共 Java API的方式隐藏MQ各个供应商提供的实际接口,从而跨越壁垒和解决互通问题,可是因为使用单独的标准化接口来胶合众多不一样的接口使应用程序反而变得更加脆弱。
为了解决各个MQ在各个生产商之间的通信问题,Java Message Service(JMS)在2001年诞生了,试图经过提供公共 Java API的方式隐藏MQ各个供应商提供的实际接口.是Java面向消息中间件的一套规范的Java API接口.
在JMS诞生以前大多数产品都支持点对点和发布/订阅两种方式的通信模型.因此JMS就将这两种消息模型抽象成两类规范,由MQ厂商选择实现. 因此咱们可使用JMS的Java API在Java语言上操做具体的MQ产品.
下一章节咱们开始进入正式学习MQ消息通信具体相关产品了,定个小目标,写个简单的MQ