JMS消息服务介绍和使用场景
什么是JMS
JMS : Java Message Service(Java消息服务),Java平台中关于面向消息中间件的接口. 重点在于接口,接口就意味着与JDBC类似,仅仅有声明,没有实现,具体的实现交给厂商. 接口本身是一种与厂商无关的API.
使用场景
每一种技术都有其产生的原因和解决的问题,消息服务的使用场景如下:
- 核心应用:
- 解耦: 订单 --> 物流 (降低工程间的强依赖程度)
- 异步: 用户注册 --> 发送邮件,初始化信息 (耗时长非必须的业务抽离,放在空闲的时候处理)
- 流量削峰: 秒杀,日志处理 (针对突发情况的大访问量场景)
- 跨平台, 多语言
- 分布式事务, 最终一致性 (引入和分布式和微服务之后,事务的处理和数据的一致是比较难保证的一个方面)
- RPC调用上下游对接,数据源变动通知下属
消息中间件常见概念与编程模型
常见概念
- JMS提供者: 连接面向消息中间件的,也就是JMS的接口实现, RocketMQ, ActiveMQ等. 简单的来说就是JMS接口的实现厂商提供的实现, 中间件本身.
- Broker服务器: 接收生产消息,提供给消费者消费的程序
- JMS生产者(Message Producer): 生产消息的服务
- JMS消费者(Message Consumer): 消费消息的服务
- JMS消息: 数据对象, 传递的内容
- JMS队列: 存储待消费信息的区域(可以简单的理解为数据结构中的队列,可以保证顺序,存储消息的介质)
- JMS主题(Topic): 一种支持发送消息给多个订阅者的机制(中转,不同的生产者发送消息到主题,经过服务器分发到不同的订阅者)
- JMS消息通常的两种类型: 点对点(Point-to-Point), 发布/订阅(Publish/Subscribe). 区别在于前者是多个消费者但只有一个消费者可以消费消息,后者是多个消费者都可以同时消费一个消息.
一个消息对应一个主题,一个主题下由多个queue. 要注意的是topic是一个逻辑管理单位,queue是物理管理单位
我是这么理解的: Producer发送Message到Broker,Topic在Broker内, Queue在Topic内, Message经过Broker发送给Consumer
基础编程模型
- MQ中需要用到的一些类
- ConnectionFactory: 连接工厂, JMS使用它来创建连接
- Connection: JMS客户端到JMS Provider的连接
- Session: 一个发送或接收消息的线程
- Destination: 消息的目的地; 消息发送给谁(Broker)
- MessageConsumer / MessageProducer: 消息消费者 / 消息生产者
主流消息队列与选型
对比
- ActiveMQ: http://activemq.apache.org/
- 支持多种语言的客户端和协议,基于JMS Provider的实现,容易上手. 但是吞吐量不高,多队列的时候性能会下降,存在消息丢失情况.
- Kafka: http://kafka.apache.org/
- 由Scala和Java编写,可以处理大规模的网站中的所有动作流数据(网页浏览,搜索等),保证数据尽量不丢失,适用于大数据领域(电商等). 但是不支持批量个广播消息,运维难度大,文档少,需要掌握Scala
- RabbitMQ: http://www.rabbitmq.com/
- 开源的AMQP实现,服务端用Erlang语言编写,支持多种客户端,在易用性,扩展性和高可用性等方面表现不错. 但是使用Erlang语言开发,阅读和修改源码难度大.(当然公司如果大部分人熟悉Erlang语言的话例外)
- RocketMQ: http://rocketmq.apache.org/
- 阿里开源的一款消息中间件,纯java开发,具有高吞吐量,高可用性,是和大规模分布式系统应用的特点,性能强劲(零拷贝技术),支持海量堆积,支持指定次数和时间间隔的失败消息重发,支持consumer端tag过滤,延迟消息等,是和电商,金融等领域. 但是也正是因为太强大了,所以不是很容易上手.
还有更多的了解参考: http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/ 和 https://www.jianshu.com/p/453c6e7ff81c