activemq

Synopsis The Replicated LevelDB Store uses Apache ZooKeeper to pick a master from a set of broker nodes configured to replicate a LevelDB Store. Then synchronizes all slave LevelDB Stores with the master keeps them up to date by replicating all updates from the master. The Replicated LevelDB Store uses the same data files as a LevelDB Store, so you can switch a broker configuration between replicated and non replicated whenever you want. Version Compatibility Available as of ActiveMQ 5.9.0. How it works. It uses Apache ZooKeeper to coordinate which node in the cluster becomes the master. The

　　　　　　　　　　　　　　　　 activeMQ入门案例 叨叨一波，很久没写博客了，最近比较慢，时间抽不出来，这个借口说的很尴尬...我知道作为一名合格的码农就必须养成每天一博客的习惯.希望友友们别像我这样懒,闲话不多时进入今天的主题，理论就不多说了，直接上案例. 1.activemq 是Apache旗下的一个开源的中间件，所以我们先去官网下载解压包,官网地址 : http://activemq.apache.org/activemq-5153-release.html 备注:linux 下载框中的解压包，window就下载箭头指向的. 2.下载后解压，解压后进入到bin目录下，可以看到两个文件夹(win32/win64)是32进32，否则相反 3.进入到对应目录能看到3个后缀为.bat 的可以执行文件，第一个cmd 方式运行，红框中就是activemq启动的端口号，不能关闭窗口，不然服务结束,接着我们测试打开浏览器输入192.168.2.70:8161 3.第二种方式点击第二个.bat 文件则是在本机服务里面启动，就跟mysql服务启动一直，就不再上图. 4.浏览器打开的页面如下，如果没有这个页面证明avtivemq启动错误 5.点击红框会弹出登录信息，初始化账号密码默认为admin admin 进入后就能看到管理页面不在上图 6. 接下来展示下activemq的消息队列案例

微服务分布式企业框架 Springmvc+mybatis+shiro+Dubbo+ZooKeeper+Redis+KafKa - 知乎 https://zhuanlan.zhihu.com/p/28978979 roncoo-pay: 龙果支付系统（roncoo-pay）是国内首款开源的互联网支付系统，拥有独立的账户体系、用户体系、支付接入体系、支付交易体系、对账清结算体系。目标是打造一款集成主流支付方式且轻量易用的支付收款系统，满足互联网业务系统打通支付通道实现支付收款和业务资金管理等功能。 https://gitee.com/roncoocom/roncoo-pay Exrick/xmall: 基于SOA架构的分布式电商购物商城 前后端分离 前台商城:Vue全家桶 后台管理系统:Dubbo/SSM/Elasticsearch/Redis/MySQL/ActiveMQ/Shiro/Zookeeper等 https://github.com/Exrick/xmall 来源： oschina 链接： https://my.oschina.net/u/4274145/blog/3290475

1.异步消息的定义   异步消息的主要目的是为了系统与系统之间的通信，所谓异步消息即消息发送者无需等待消息接收者的处理以及返回，甚至无需关心消息是否发送成功   在异步消息中有两个很重要的概念，即消息代理和目的地，当消息发送者发送消息之后，消息将由消息代理接管，消息代理保证消息传递到指定目的地。   异步消息主要有两种目的地形式，队列（queue）和主题(topic)，队列用于点对点形式的消息通信，主题用于发布订阅式的消息通信。 1.1目的地形式分类 1.1.1点对点式   当消息发送者发送消息，消息代理将消息后将消息放进一个队列里，当有消息接收者来接收消息的时候，消息将从队列中取出传递给消息接收者，这时候队列里就没有了这条消息。点对点式确保每一条消息只有唯一的发送者和接收者，但这并不能说明只有一个接收者能够从队列中接收消息，因为队列中有多个消息，点对点式只保证每一条消息只有唯一的发送者和接收者 1.1.2发布/订阅式   发布订阅式是消息发送者发送消息到主题，而多个消息接收者监听这个主题，此时的消息发送者和接收者分别叫做发布者和订阅者 1.2 企业级消息代理   JMS即JAVA消息服务，是基于JVM的消息代理规范，ActiveMQ是一个JMS的实现 AMQP也是一个消息代理的规范，他不仅兼容JMS，还支持跨语言和平台，AMQP的主要实现是RabbitMQ 1.3

微服务通信机制 系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。 围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的去集中化控制。 将组件定义为可被独立替换和升级的软件单元。 以业务能力为出发点组织服务的策略。 倡导谁开发，谁运营的开发运维一体化方法。 RESTful HTTP协议是微服务架构中最常用的通讯机制。 每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。 允许不同微服务采用不同的数据持久化技术。 微服务非常重视建立架构及业务相关指标的实时监控和日志机制，必须考虑每个服务的失败容错机制。 注重快速更新，因此系统会随时间不断变化及演进。可替代性模块化设计。 微服务通信方式 ： 同步 ： dobbo通过 RPC 远程过程调用、springcloud通过 REST接口json调用等。 异步 ： 消息队列，如：RabbitMq、ActiveMq、Kafka 等。 消息队列中间件如何选型 1.协议：AMQP、STOMP、MQTT、私有协议等。 2.消息是否需要持久化。 3.吞吐量。 4.高可用支持，是否单点。 5.分布式扩展能力。 6.消息堆积能力和重放能力。 7.开发便捷，易于维护。 8.社区成熟度。 来源： oschina 链接： https://my.oschina.net/u/4324904/blog

摘要：消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。 目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka等。 消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。 1.异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种1.串行的方式；2.并行方式。 （1）串行方式：将注册信息持久化后，发送注册邮件，再发送注册短信。三个业务全部完成后，返回给客户端。 （2）并行方式：将注册信息持久化后，发送注册邮件的同时，发送注册短信。三个业务全部完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。 假设三个业务节点每个使用100毫秒钟，不考虑其他开销，则串行方式的时间是300ms，并行的时间可能是200毫秒。则串行的方式1秒内可处理3次请求，并行方式1秒内可处理5次请求，综上所述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？ 引入消息队列，将不是必须的业务逻辑，异步处理。如下图所示 按照上图，用户的响应时间相当于是注册信息写入数据库的时间和将消息插入消息队列，也就是105毫秒。注册邮件，发送短信消息写入队列后，直接返回

摘要：消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。 目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka等。 消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。 1.异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种1.串行的方式；2.并行方式。 （1）串行方式：将注册信息持久化后，发送注册邮件，再发送注册短信。三个业务全部完成后，返回给客户端。 （2）并行方式：将注册信息持久化后，发送注册邮件的同时，发送注册短信。三个业务全部完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。 假设三个业务节点每个使用100毫秒钟，不考虑其他开销，则串行方式的时间是300ms，并行的时间可能是200毫秒。则串行的方式1秒内可处理3次请求，并行方式1秒内可处理5次请求，综上所述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？ 引入消息队列，将不是必须的业务逻辑，异步处理。如下图所示 按照上图，用户的响应时间相当于是注册信息写入数据库的时间和将消息插入消息队列，也就是105毫秒。注册邮件，发送短信消息写入队列后，直接返回

面试题： 为什么使用消息队列？ 消息队列有什么优点和缺点？ Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 面试官心理分析 其实面试官主要是想看看： 第一，你知不知道你们系统里为什么要用消息队列这个东西？ 不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。 其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。 没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好 因为面试官担心你进了团队之后只会木头木脑的干呆活儿，不会自己思考。 第二，你既然用了消息队列这个东西，你知不知道用了有什么好处&坏处？ 你要是没考虑过这个，那你盲目弄个 MQ 进系统里，后面出了问题你是不是就自己溜了给公司留坑？ 你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。 就怕你干 1 年挖一堆坑，自己跳槽了，给公司留下无穷后患。 第三，既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？ 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ，比如 Kafka，甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。 每一个 MQ 没有绝对的好坏，但是就是看用在哪个场景可以扬长避短

[TOC] SpringBoot如何优雅的使用RocketMQ MQ，是一种跨进程的通信机制，用于上下游传递消息。在传统的互联网架构中通常使用MQ来对上下游来做解耦合。 举例：当A系统对B系统进行消息通讯，如A系统发布一条系统公告，B系统可以订阅该频道进行系统公告同步，整个过程中A系统并不关系B系统会不会同步，由订阅该频道的系统自行处理。 什么是RocketMQ？ 官方说明: 随着使用越来越多的队列和虚拟主题，ActiveMQ IO模块遇到了瓶颈。我们尽力通过节流，断路器或降级来解决此问题，但效果不佳。因此，我们那时开始关注流行的消息传递解决方案Kafka。不幸的是，Kafka不能满足我们的要求，特别是在低延迟和高可靠性方面。 看到这里可以很清楚的知道RcoketMQ 是一款低延迟、高可靠、可伸缩、易于使用的消息中间件。 具有以下特性： 支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型 能够保证严格的消息顺序，在一个队列中可靠的先进先出（FIFO）和严格的顺序传递 提供丰富的消息拉取模式，支持拉（pull）和推（push）两种消息模式 单一队列百万消息的堆积能力，亿级消息堆积能力 支持多种消息协议，如 JMS、MQTT 等 分布式高可用的部署架构,满足至少一次消息传递语义 RocketMQ环境安装 下载地址： https://rocketmq.apache.org

在上一篇《 ActiveMQ入门系列二：入门代码实例（点对点模式） 》中提到了ActiveMQ中的两种模式：点对点模式（PTP）和发布/订阅模式（Pub & Sub），详细介绍了点对点模式并用代码实例进行说明，今天就介绍下发布/订阅模式。 一、理论基础 发布/订阅模式的工作示意图： 消息生产者将消息（发布）到topic中，可以同时有多个消息消费者（订阅）消费该消息。 和点对点方式不同，发布到topic的消息会被所有订阅者消费。 当生产者发布消息，不管是否有消费者，都不会保存消息。 一定要先有消息的消费者，后有消息的生产者。 二、代码实现 生产者 package com.sam.topic; import org.apache.activemq.ActiveMQConnectionFactory; import javax.jms.* ; /** * @author JAVA开发老菜鸟 * */ public class TopicProducer { public static final String QUEUE_NAME = "topic-demo"; // 队列名 public void producer(String message) throws JMSException { ConnectionFactory factory = null ; Connection