Download presentation
Presentation is loading. Please wait.
1
开源MQ技术介绍 Kimmking 2013-6
2
Agenda 消息系统、协议与技术 常见开源消息中间件 MQ选型与未来发展展望 消息系统及其结构 STOMP/JMS/AMQP/MQTT
EIP与SEDA 常见开源消息中间件 ZeroMQ Fqueue ActiveMQ与Apollo Kafka与MetaQ RabbitMQ MQ选型与未来发展展望
3
消息系统、协议与技术
4
Messaging 耦合 -> 松耦合 同步 -> 异步化 直接请求 -> 缓冲压力 MOM A系统 B系统 A系统
Oneway send receive MOM A系统 B系统 A系统 send receive B系统 Request Response receive send 一个问题:什么是消息? 两个额外的话题: 1、RPC方式的发展:文本化、二进制化,各自的特点。 RPC(dcom/corba/rmi/.net remoting/werbservice /soap/hessian/potocol buffer/thrift…) 2、中间阶段的消息系统形态:基于内存、文件或数据库的消息传递。 耦合 -> 松耦合 同步 -> 异步化 直接请求 -> 缓冲压力
5
RPC部署结构 A系统 B系统 C系统 网状结构,各系统紧耦合,系统间强依赖,相互影响,不利于管理和扩展 D系统 E系统 F系统
6
Messaging部署结构 A系统 B系统 MQ F系统 C系统 E系统 D系统 Queue Queue Queue
7
Messaging系统结构 MQ A系统 B系统 安全层 管理层 客户端应用层:发送和接收消息的API接口
Exchange Queue Dispatch Storage 安全层 客户端应用层:发送和接收消息的API接口 管理层 消息模型层:消息、连接、会话、事务等等 消息处理层:消息交互逻辑定义、持久化 网络传输层:序列化协议、传输协议、可靠机制
8
MQ消息中间件特性 系统的稳定性与健壮性 Stability & Robustness 消息的可靠性 Reliability 事务性
长期稳定运行 高并发下运行 消息的可靠性 Reliability 发送的可靠性 接收的可靠性 事务性 本地事务 分布式事务 QoS&DLQ 可靠性指的是:1、物理可靠性:发送后,同步持久化,消息数据宕机重启不丢失。 2、业务可靠性:接收时,消息被可靠的处理了,如果没处理完成时出错,可以重发保证消息在业务。 几种QoS策略:最多一次,有且仅有一次。 过期或多次重发失败, 过期和失败的消息进入DLQ
9
MQ消息中间件特性 性能 Performance Broker性能 Client性能 基于内存队列 基于内存+异步/同步持久化到磁盘
基于内存+顺序/随机读写磁盘 基于内存+持久化到关系数据库 Client性能 异步/同步发送、接收 确认机制 事务性会话 消息积压 Broker Producer memory Consumer Disk 性能: 易用性、效率和可靠性、复杂性和折中方案。 高效的queue: 1、如果只考虑性能、不考虑可靠性,基于内存,比如使用memcached或redis做一个队列,现成的有zeroMQ 2、如果考虑可靠性,则需要持久化到硬盘(数据库或日志文件),磁盘比内存降低几个数量级。 基于FIFO的文件log记录,比如qunar的Fqueue 考虑最大化吞吐量的MQ,异步、内存映射磁盘文件,操作系统flush磁盘,比如kafka、metaq 考虑事务和可靠性的,基于磁盘或数据库,比如ActiveMQ、notify
10
MQ消息中间件特性 高可用性HA Cluster&Sharding Failover Replication 负载均衡LoadBalance
Slave 高可用性HA Cluster&Sharding 负载均衡LoadBalance 主从Master-Slave 分片Partition Failover 自动 手动 Replication 同步复制 异步复制 Master Slave Slave Replication Replication MQ的高可用同样带来部署和管理上的复杂性。 Replication Client Master Slave Client Master Master
11
MQ消息中间件特性 扩展性 Scalability 可管理性 Manageability 支持多种协议和规范 支持多种接入和传输方式
支持自定义消息策略 支持自定义插件机制 可管理性 Manageability Broker与Queue的管理 Client与Connection的管理 Cluster与Sharding的管理 JMX或REST方式的管理API接口 1、可集成性 某些MQ支持嵌入方式集成到应用系统或其他中间件 2、策略管理 QoS策略的管理、各种消息处理策略的管理
12
JMS(Java消息服务) 关注于应用层的API协议(类似JDBC) Message结构与Queue概念 Messaging行为
Body\Header\Property, messages types Queue\Topic\TemporaryQueue\TemporaryTopic Connection\Session\Producer\Consumer\DurableSubscription Messaging行为 PTP&Pub-Sub 持久化 事务机制 确认机制 临时队列 JMS规范: 应用中使用标准的JMS协议实现的消息客户端代码可以用于不同的MQ(需要更换不同的JMS实现)。 JMS不是为了解决异构系统而定义的,好在它发展成熟以后,基本上所以的jms server的实现(各种MQ)都解决了异构问题。 JMS2.0规范简化了一些操作,比如Context代替Connection+Session,Message链式操作等等。 其他的一些概念: QueueView Requestor MessageListener
13
Spring-JMS JMSTemplate提供了便利的发送方法,不用再关注异常和资源释放。
CachingConnectionFactory提供了从生产者/消费者到Session,再到Connection的Cache策略,这些资源都能被重复使用。 提供了Message与Objec的转换方式。 推荐使用JmsTemplate发送消息, Message Listener Container接收消息。
14
STOMP(简单文本消息协议) Simple (or Streaming) Text Orientated Messaging Protocol 简单、基于Frame、文本的命令式操作协议 类似HTTP/SMTP/FTP等协议 易用、跨平台、MQ无关性 shell下使用telnet或nc命令与MQ交互 STMOP操作演示 性能较低 ActiveMQ的STOMP支持 协议封装与转换 三种版本的STOMP协议 STOMP 1.0 STOMP 1.1 STOMP 1.2
15
AMQP Advanced Message Queuing Protocol
来自于JPMorgan,源于满足金融系统的消息通讯业务需求: 线路级协议、实现客户端与不同MQ间的互操作 五个基本部分: 数据类型与编码 消息传输交互 消息定义与行为 事务 安全性 AMQP除了ActiveMQ、RabbitMQ等外,还有OpenAMQ、Apache Qpid等等 AMQP1.0最终版规范: ActiveMQ实现了AMQP1.0得益于Qpid的子项目Proton。 Spring AMQP 是基于 Spring 框架的AMQP消息解决方案,提供模板化的发送和接收消息的抽象层,提供基于消息驱动的 POJO。同时有 Java 和 .NET 的版本。
16
MQTT MQ Telemetry Transport
基于TCP的简单二进制通讯协议。 协议各部分的定义精确到bit,最小消息为2bytes。 不同于一般MQ的长连接,协议规定了keep alive timer参数和ping指令。 QoS level决定了交互次数。 为物联网(Internet Of Things)准备的消息协议。 官方首页: 协议规范: MQ 遥测传输 (MQTT) 是轻量级基于代理的发布/订阅的消息传输协议,设计思想是开放、简单、轻量、易于实现。这些特点使它适用于受限环境。例如,但不仅限于此: 网络代价昂贵,带宽低、不可靠。 在嵌入设备中运行,处理器和内存资源有限。 该协议的特点有: 使用发布/订阅消息模式,提供一对多的消息发布,解除应用程序耦合。 对负载内容屏蔽的消息传输。 使用 TCP/IP 提供网络连接。 有三种消息发布服务质量: “至多一次”,消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况,环境传感器数据,丢失一次读记录无所谓,因为不久后还会有第二次发送。 “至少一次”,确保消息到达,但消息重复可能会发生。 “只有一次”,确保消息到达一次。这一级别可用于如下情况,在计费系统中,消息重复或丢失会导致不正确的结果。 小型传输,开销很小(固定长度的头部是 2 字节),协议交换最小化,以降低网络流量。 使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。
17
EIP与SEDA <Enterprise Integration Patterns>
Staged Event-Driven Architecture EIP和SEDA同样是ESB的基础。
18
常见开源消息中间件
19
ZeroMQ 项目地址 http://www.zeromq.org/ 基于C++开发,性能非常高的内存MQ内核
本身就是一个并发框架做的socket库 在集群环境下比TCP更快 支持各种常见平台,但是需要额外的绑定包装 基本不支持持久化 任何程序都可以变成MQ broker(zero brokers) 各种语言的例子 官方文档 ØMQ(Zeromq) 是一个更为高效的传输层 the subscriber will always miss the first messages that the publisher sends. This is because as the subscriber connects to the publisher (something that takes a small but non-zero time), the publisher may already be sending messages out. 在这种模式下很可能发布者刚启动时发布的数据出现丢失,原因是用zmq发送速度太快,在订阅者尚未与发布者建立联系时,已经开始了数据发布(内部局域网没这么夸张的)。官网给了两个解决方案;1,发布者sleep一会再发送数据(这个被标注成愚蠢的);2,使用proxy。 Java下使用ZeroMQ C#下使用ZeroMQ
20
Fqueue (Fast Queue) 支持memcached协议(分布式和高可用机制) 基于磁盘持久化存储(顺序处理的日志文件)
高性能(20-30万写入QPS)、低内存使用 配置和使用简单 项目地址 在不需要强顺序的场景下,支持多机负载均衡。
21
ActiveMQ 高可靠的、事务性的消息队列 当前应用最广泛的开源消息中间件 项目开始与2005年CodeHaus
2006年成为Apache项目 Java代码44万行,xml代码3.9万行(5.7.0) 24个Committers 核心人员均为商业公司FuseSource职员 支持多种接入协议和消息协议 activemq-parent-5.7.0]$ find . -type f -iname "*.java" -exec cat {} \; | grep -v '^$' | wc -l 441040 activemq-parent-5.7.0]$ find . -type f -iname "*.xml" -exec cat {} \; | grep -v '^$' | wc -l 39029 activemq-parent-5.7.0]$ find . -type f -iname "*.*" -exec cat {} \; | grep -v '^$' | wc -l 淘宝的Notify是跟ActiveMQ类似,有几个特点: 仅支持Topic 不保证消息顺序,不保证不重复投递,不支持消息优先级 支持消费者分区 支持补偿性的发送端分布式事务 性能测试:
22
ActiveMQ-Failover与Reconnect
Java和C++客户端支持无缝地failover 京东的netcomm同学把failover这块的自动重连、心跳检测代码抽出来,变成一个可靠网络通讯的基础框架,项目代码见:
23
ActiveMQ-High Availability
状态复制 Pure Master-Slave 基于共享锁 JDBC Master-Slave(表的排它锁) Shared File System Master-Slave(文件的写锁)
24
Pure Master-Slave 不共享存储 全复制(所有消息、所有应答、所有事务)
从服务器(备份服务器)默认不启动对外服务组件,只同步备份主服务器的所有数据。 5.8.0版本中已废弃 可配置从服务器在主服务器挂机后启动服务充当主服务器。
25
JDBC Master-Slave 可靠性好,但性能一般。 推荐使用如果原系统已经存在企业数据库。 从服务器个数没有限制。 配置简单。
从服务器一直待机状态, 除非竞争到DB锁
26
Shared Storage Master-Slave
推荐使用如果现存SAN 从服务器(Slave)个数无限制 配置简单 注意确认文件锁是否正常及超时时间,NFS v4
27
Security File based JAAS plugin (Certificates, LDAP) Destination Level
Secure channels (SSL) Authentication File based JAAS plugin (Certificates, LDAP) Authorization Destination Level Message Level
28
Apollo http://activemq.apache.org/apollo/
Apache ActiveMQ的改进版本,使用Scala开发 主要特点: Reactor Based Thread Model 基于hawtdispatch(thread pooling/NIO event framework) Scala 2.9 Implementation Protocol Agnostic(不支持JMS) STOMP、AMQP、MQTT、OpenWire REST Based Management Message Swapping 压缩内存消息,交互到磁盘 Hawtdispatch首页: ActiveMQ5.5.1、apollo1.0、hornetq Final、rabbitmq-2.7.0四种MQ基于STOMP协议的性能比较:
29
Kafka与MetaQ Kafka (基于Scala) MetaQ(Java重新实现并改进)
O(1)、顺序读写的持久化,高吞吐量是主要设计目标 producer、broker、consumer都是分布式的 Partition Messages 基于ZooKeeper,轻量级broker Pull,消费记录在Consumer端 Consumer 分组 支持并行加载数据到Hadoop 异步复制和异步复制 MetaQ(Java重新实现并改进) 支持本地和分布式事务 文本的监控协议设计 Kafka是linkedIn设计的MQ。 meta在淘宝和支付宝、京东商城都得到了广泛应用,现在每天支付宝每天经由meta路由的消息达到120亿,淘宝也有每天也有上亿的消息量。 Meta适合的应用: 日志传输,高吞吐量的日志传输本来就是kafka的强项 消息广播功能,如广播缓存配置失效。 数据的顺序同步功能,如mysql binlog复制 分布式环境下(broker,producer,consumer都为集群)的消息路由,对顺序和可靠性有极高要求的场景。 作为一般MQ来使用的其他功能 MetaQ项目: kafka的java化版本jafka:
30
RabbitMQ http://www.rabbitmq.com/ 基于Erlang开发 持久化方式为异步flush到磁盘 工具和插件丰富
RabbitMQ-HA active/passive pair of nodes Master-Slave的Queue镜像复制 RabbitMQ支持AMQP1.0的插件 RabbitMQ的HA:
31
使用场景与选型 事务可靠性场景(ActiveMQ) 吞吐量优先场景(MetaQ) 系统性设计场景 应用开源MQ最大的挑战是可管理性方面的问题
重要业务数据的异步处理 数据的增量远程同步 吞吐量优先场景(MetaQ) 一般性的通知 日志的传输和收集 系统性设计场景 系统间RPC依赖解耦和 耗时同步操作转异步 应用开源MQ最大的挑战是可管理性方面的问题 选型:可靠优先、吞吐量优先 跨语言,
32
消息中间件的未来 可扩展性 Scalability 可管理性 Manageability 更细粒度的专用性MQ
大规模弹性的MQ cluster网络 更可靠高效的replication与failover 更细粒度和透明的sharding 可管理性 Manageability 监控 流控 … 更细粒度的专用性MQ 与其他技术领域更紧密的衔接与融合 一家之言
33
Q&A Any Question?
34
Thanks!
Similar presentations