mq

RocketMq的安装使用 、一.预备环境 1.系统 Windows 2. 环境 JDK1.8、Maven、Git 1.下载 1.1地址： http://rocketmq.apache.org/release_notes/release-notes-4.2.0/ 1.2选择‘Binary’进行下载 1.3解压已下载工程 2. 配置 2.1 系统环境变量配置 变量名：ROCKETMQ_HOME 变量值：MQ解压路径\MQ文件夹名 3. 启动 3.1 启动NAMESERVER Cmd命令框执行进入至‘MQ文件夹\bin’下，然后执行‘start mqnamesrv.cmd’，启动NAMESERVER。成功后会弹出提示框，此框勿关闭。 3.2 启动BROKER Cmd命令框执行进入至‘MQ文件夹\bin’下，然后执行‘start mqbroker.cmd -n 127.0.0.1:9876 autoCreateTopicEnable=true’，启动BROKER。成功后会弹出提示框，此框勿关闭。 假如弹出提示框提示‘错误: 找不到或无法加载主类 xxxxxx’。打开runbroker.cmd，然后将‘%CLASSPATH%’加上英文双引号。保存并重新执行start语句 三. RocketMQ插件部署 1. 下载 地址：https://github.com/apache/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/dowloading/releases/

本文主要介绍什么是消息队列（MQ）,为什么使用消息队列，以及MQ的异步操作。 什么是消息队列？ “消息队列”是在消息的传输过程中保存消息的容器。主要是用来实现应用程序的异步和解耦，同时也能起到消息缓冲，消息分发的作用。消息中间件最主要的作用是解耦，中间件最标准的用法是生产者生产消息传送到队列，消费者从队列中拿取消息并处理，生产者不用关心是谁来消费，消费者不用关心谁在生产消息，从而达到解耦的目的。主要有ActiveMQ，RabbitMQ，Kafka，RocketMQ。 为什么要使用消息队列？ 主要原因是由于在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update之类的请求同时到达 MySQL ，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。 MQ的异步操作 使用消息队列将调用异步化，可改善网站的扩展性，使用消息队列将调用异步化，可改善网站的扩展性，还可改善网站系统的性能。 不使用消息队列： 使用消息队列： 在不使用消息队列的情况下，用户的请求数据直接写入数据库，在高并发的情况下，会对数据库造成巨大的压力， 同时也使得响应延迟加剧。在使用消息队列后，用户请求的数据发送给消息队列后立即返回，再由消息队列的消费者进程(通常情况下，

消息队列 消息队列内部实现原理： （1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除） 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息， 而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者 接收处理，即使有多个消息监听者也是如此。 （2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者） 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅 者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即 使当前订阅者不可用，处于离线状态。 为什么需要消息队列？ （1）解耦： 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 （2）冗余： 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风 险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需 要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你 使用完毕。 （3）扩展性： 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要 另外增加处理过程即可。 (4）灵活性 & 峰值处理能力： 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。

1. 分布式事务原理解析 1.1. TCC分布式事务 了解过TCC分布式事务的都知道它有三个阶段：try，confirm，cancel，但很多文章就只有原理图，和对原理图的解释，看一遍也留不下印象，这里用实际场景举个例子，说明TCC分布式事务原理 try阶段：假设我们又订单系统，它需要调用库存和积分系统，try阶段我们进行的是 预处理 ，比如下单1个商品，在try操作中，我们在库存表设置个冻结字段，表示冻结1个商品，商品的存量先不扣除，而积分表同样添加个预增加积分字段，添加个预积分比如10 confirm阶段： 我们为什么要经历try阶段？ ，为了尽可能的保证各个系统都是正常工作的，数据库，服务都没有挂掉，资源没有不足，则可以最大程度上保证confirm阶段能正确执行， confirm阶段也就是正式的扣除库存和增加积分 cancel阶段： 若try阶段执行错误 ，则会对前面已经执行的try阶段的系统执行cancel操作，也就是反向SQL回滚，冻结的商品-1，预积分-10。到这里有没有疑问？我首先想到的是 若confirm或cancel操作再执行失败怎么办 ？这里就要由TCC分布式事务框架保证了，它会 记录事务活动日志 ，再confirm或cancel失败后不断尝试调用confirm和cancel的逻辑，所以这里需要开发者自己保证，你的SQL是正确的 TCC分布式框架推荐